B2B ja SOA

Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa, TJTSE54 kevät 2007

Ville Seppänen<rissepp@jyu.fi>

SOAP-verkkopalvelu

WSDL

Clientapp

Serverapp

A. PublishB. Search/subscribe

A

B

”Definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.”

WSDL-rajapinta

WSDL-rajapinta

jatkuu

Palvelu

SOAP pyyntö ja vastaus

Overheadista● 'Human-readable'

● SOAP/XML-RPC -viestit n. 14 kertaa suurempia kuin CORBAn binääriviestit

● 5 000 kokonaisluvun siirron kesto SOAP:lla 882 kertainen verrattuna CORBA:an

*

* python socket(IBM: The Python Web services developer: Messaging technologies compared)

SOA ja WS-tekniikatUDDI

WSDL

SOAP

SOAP

SOAP

Ei mitään uutta, mutta...● Avoin, alusta- ja kieliriippumaton

– Toimii käytännössä kaikilla laitealustoilla– WS/SOAP-toteutus löytyy lähes jokaiselle

ohjelmointikielelle– Siirrettävissä (tosin valmistajakohtaisia laajennuksia

standardeihin on alkanut näkyä...)– Pienentää vendor lock-inin vaaraa

● Tekniikka ei määrää palvelun granulariteettia– Yksinkertaisesta sovellustoiminnallisuudesta, SQL-

kyselystä tmv. pitkäkestoisiin ja hajautettuihin liiketoimintaprosesseihin

– Vrt. XML-RPC (procedure), RMI (method), CORBA/ORB (object), MS DCOM (component)

B2B-integrointi● Datan, sovellusten, prosessien saattaminen

liiketoimintakumppanien saataville (halutussa määrin)● Tavoitteena kustannustehokkaampi, tehokkaampi ja

joustavampi toiminta

Stadco.co.uk approach to supply chain management

Edellyttää yhteentoimivuutta● Levels of heterogeneity

– Syntactic: machine-readable aspects of data representation

– Structural: representational differences involving data modeling constructs and schemas

– System/Platform: differences in system-level aspects (e.g., OS, communications)

– Semantic: different meanings, propositions, signification etc. of the terms used in exchange

Internet, Intranet, ExtranetHTTP, FTP, SMTPXML, XML SchemaSOAP, XML-RPC

WSDL, UDDI

Security,Routing

Workflow,Transaction Management

BusinessSemantics

HorizontalStandard

HorizontalNon-Standard

VerticalNon-Standard

Kaye 2003

Businesssemantics

ebXML, Rosettanet, BPEL, Semantic Web (services), ...?

Tekniikat – Ne on horisontaaleja; Toteutukset – Ne on vertikaaleja

SOA:n keskeisen ajatuksen – löyhäkytkentäisyyden (loose coupling) – ja liiketoiminnan semanttisten vaatimusten yhdistäminen – Se on hankalaa

Pyramidin alemmat tasot – Ne eivät juurikaan tuota ongelmia

Joskaan esim. verkkopalvelujen tietoturva ja transaktiotuen taso – Se ei välttämättä vielä

tyydytä kaikkien vaativimpia ja kriittisimpiä tarpeita

Työllä tai sopivilla välineillä (ja työllä) WS-tekniikat piilottavat heterogeenisuuden tasoistasyntaksi-, rakenne- ja järjestelmätasot ovat melko hyvin

Coupling &Dependency

● Level of common knowledge necessary between provider and consumer

● W3C glossary: Coupling is the dependency between interacting systems. This dependency can be decomposed into real dependency and artificial dependency– Real dependency is the set of features or services that a system

consumes from other systems. The real dependency always exists and cannot be reduced.

– Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Typical artificial dependency factors are language dependency, platform dependency, API dependency, etc. Artificial dependency always exists, but it or its cost can be reduced.

Tight coupling● ”The programmer of one participant (say, the

consumer, or client) must have detailed knowledge about the behavior, such as the method calls, messaging protocol, synchronous behavior, or message semantics, of the other participant (in this case, the provider, or server) in order to successfully complete the required interaction between the two pieces of software”J. Bloomberg

● Ei ainoastaan huono asia: semanttiseen heterogeenisuuteen liittyvät asiat tulevat suuremmalla todennäköisyydellä noteeratuiksi

Loose coupling● Loosely coupled

– the two participants may have specific, but more limited knowledge about each other. Such information appears in a Service contract, which is a document external to each participant that provides the information each participant needs to interact with the other

● Tavoitteena vähentää artificial dependency minimiin

Loose coupling● Loosely coupled services, even if they use

incompatible system technologies, can be joined together on demand to create composite services, or disassembled just as easily into their functional components. Participants must establish a shared semantic framework to ensure messages retain a consistent meaning across participating services.(looselycoupled.com)

– Helpommin sanottu kuin tehty?

Integroinnin tasoja: dataintegraatio● Useissa eri lähteissä sijaitsevan ja usein

heterogeenisen datan yhdistämistä– Heterogeenisuus: erilaiset skeemat, erilaiset

koodaukset, merkitykset jne.● ETL: extract, transform, load

– Usein eräajoluontoista; soveltuu heikosti käytettäväksi usein muuttuvan datan kanssa

● Yleinen skeema– Transform kohdistetaan kyselyihin

Dataintegrointi

Kuvat: wikipedia.org/wiki/Data_integration

Dataintegrointi ja SOA● Rajapinnat kuten ODBC ja JDBC tarjoavat pääsyn

dataan esim. asiakas-palvelin -ympäristöissä● SOA-tekniikoita voidaan käyttää samaan tapaan ja

tarjota datalähde ulospäin palveluna, SOAP-API joka vastaanottaa SQL-lauseita– Dataan pääsyä saatetaan haluta rajoittaa– Tiukkakytkentäinen ratkaisu: skeeman muuttuminen

vaikuttaa asiakassovelluksiin● Vaihtoehtoisesti palveluna julkaistaan tarvittavat

kyselyt eikä suoraa datayhteyttä– Skeemamuutokset haijastuvat ainoastaan kyselyn

suorittamisesta vastaaviin palveluihin

Sovellusintegraatio● Tavoitteena erillisten sovellusten välinen

kommunikointi tai yhteentoimiminen● Pääasiassa datan ja komentojen muuntamista

epäyhteensopivien sovellusten välillä

EAI esim.

Sovellusintegraatio● Implementing application integration has

traditionally been done by tedious programming, or occasionally one package might support the interfaces of one or two other packages. However, the trend today is to use message brokers, applications servers and other specialized integration products that provide a common connecting point.

Shrinking common technology subset

Two Windows DCOM apps J2EE & DCOM apps

J2EE, DCOM &Yet Another Application

Traditional 'subtractive' approach to integrating systems: finding the common subset oftechnologies between the systems, starting with a physical connection between thesystems. That subset is the basis for the integration, and additional layers of technologyare built on top of it. (Kaye 2003)

Application A Application B

Application C

Standardized Web-servicesinterface

”It would be a violation of loose-coupling principles to base the interface on any common-subset assumption.” (Kaye 2003)

”...key to loosely coupling heterogeneous technologies is to standardize the interfaces and not the source code. (ibid)”

Sovellusintegraatio ja SOA?

Sovellusintegraatio ja SOA?”No one should confuse the ease of using Web services interfaces with the difficulty

of making Web services a reality.”

www.iwaysoftware.com

Sovellusintegraatio ja SOA?● Standardi API ei siis ole ihmeratkaisu tai

hopealuoti● Middleware uudella tekniikalla?

Prosessi-integraatio

Datataso

Sovellustaso

2. Palvelutaso

Prosessitaso

1. Palvelutaso

3. Palvelutaso

IT- ja liiketoimintastrategiat● Palveluja – ei sovelluksia● Palveluja määriteltäessä tavoitteena muodostaa

kokonaisuuksia jotka vastaavat liiketoiminnalle luontevia käsitteitä esim.– 1. taso: Hae asiakkaan tiedot– 2. taso: Laskuta asiakasta– 3. taso: Käsittele tilaus

● Hyvä palvelu abstrahoi järjestelmätason toiminnan liiketoiminnan kannalta tarpeellisiksi kokonaisuuksiksi tai mustiksi laatikoiksi– Riittää, että tiedetään mitä laatikko tekee; ei ole tarpeen

tietää, miten se sen tekee

IT- ja liiketoimintastrategiat● SOA lupaa tuoda IT- ja liiketoimintastrategioita

lähemmäksi toisiaan tai jopa yhdistää ne● Perinteinen alignment-malli:● Kritisoitu siitä, että ei huo-

mioi nopeasti muuttuvanympäristön asettamiapaineita

● Ihannetilassa SOA mahdol-listaa liiketoimintaprosessi-en muodostamisen, purkami-sen ja muokkaamisen nope-alla ja kustannustehokkaalla tavalla

BPEL4WS● Orchestration: describes how web services

can interact with each other at the message level, including business logic and execution order of the transactions– These interactions may span applications and/or

organizations, and– Result in long-lived, transactional, multi-step

processes● Refers to an executable business process that

may interact with both internal and external web services

● The process is always controlled from the perspective of one of the business parties

BPEL4WS● Business Process Execution Language for Web

Services on mm. IBM:n, Microsoftin ja BEA:n tukema ehdotus, joka määrittelee verkkopalvelujen toiminnan liiketoimintaprosessien integroinnissa– BPEL-prosessi on verkkopalvelu, joka koostuu

verkkopalveluista (composite service/appl)● XML-sanasto, joka kuvaa prosessikulun

kontrollointilogiikan● Prosessikuvaukset tulkitsee ja suorittaa

prosessimoottori

BPEL4WS● Inside-Out

– Prosessi kuvataan yhden osapuolen (omistajan) näkökulmasta

● Prosessit kytkeytyvät verkkopalveluihin WSDL-rajapintojen kautta– WSDL määrittelee prosessin operaatiot (esim.

CheckCreditCard)– BPEL määrittelee kuin operaatioiden suorittaminen

jaksotetaan (esim. IF maksutapa = luottokortti THEN CheckCreditCard ELSE ...)

BPEL4WS● Prosessit julkaistaan verkkopalveluina niiden

omien WSDL-rajapintojen kautta– WSDL kuvaa prosessin julkiset aloitus- ja

päätepisteet (entry ja exit points)● Prosessit käyttävät WSDL:ssä määriteltyjä

tietotyyppejä prosessiin kuuluvien kutsujen sisällä

BPEL4WS● Määrittely erottaa perus- ja rakenteiset

toiminnallisuudet (basic ja structured activities)– Perustoiminnallisuudet mahdollistavat

vuorovaikutuksen prosessin osapuolten välillä (mm. receive, reply, invoke)

– Rakenteelliset toiminnallisuudet määrittelevät prosessin kokonaiskulun; ts. Mitä perustoiminnallisuuksia suoritetaan, miten ja missä järjestyksessä

● Poikkeustenhallinta ja transaktio-ominaisuudet rakennettu WS-Coordination and WS-Transaction -määritysten päälle

BPEL4WS● Saman voi tietysti toteuttaa millä tahansa

ohjelmointikielellä, joka tarjoaa tarvittavat kontrollirakenteet, poikkeusten käsittelyn, tuen asynkroniselle kommunikoinnille jne. ja jolla voidaan tehdä HTTP:n yli kutsuttavia sovelluksia

● Mutta BPEL, kuten muutkin nykyisistä SOA-tekniikoista, on alusta- ja kieliriippumaton

● BPEL-prosessi on XML-dokumentti, joka on suoritettavissa minkä tahansa valmistajan BPEL-moottorilla (=> BPEL v.2)

BPEL4WS● Eli jos epästandardien sovellusten

toiminnallisuus tarjotataan palveluina avoimen ja standardin rajapinnan kautta (WSDL/SOAP), täytyy myös orkesterointimekanismin olla sellainen

● Edellinen ei tarkoita sitä, että mekanismin pitäisi olla BPEL; riittää että on se avoin ja standardi