B2B ja SOA. Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa, TJTSE54 kevät Ville Seppänen

Transkriptio

1 B2B ja SOA Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa, TJTSE54 kevät 2007 Ville Seppänen

2 SOAP-verkkopalvelu WSDL 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. A B Client app Server app A. Publish B. Search/subscribe

3 WSDLrajapinta

4 WSDLrajapinta jatkuu

5 Palvelu SOAP pyyntö ja vastaus

6 Overheadista 'Human-readable' * SOAP/XML-RPC -viestit n. 14 kertaa suurempia kuin CORBAn binääriviestit kokonaisluvun siirron kesto SOAP:lla 882 kertainen verrattuna CORBA:an * python socket (IBM: The Python Web services developer: Messaging technologies compared)

7 SOA ja WS-tekniikat UDDI SOAP SOAP WSDL SOAP

8 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, SQLkyselystä tmv. pitkäkestoisiin ja hajautettuihin liiketoimintaprosesseihin Vrt. XML-RPC (procedure), RMI (method), CORBA/ORB (object), MS DCOM (component)

9 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

10 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

11 Vertical Non-Standard Business Semantics Security, Routing Workflow, Transaction Management WSDL, UDDI SOAP, XML-RPC XML, XML Schema HTTP, FTP, SMTP Internet, Intranet, Extranet Kaye 2003 Horizontal Non-Standard Horizontal Standard

12 Työllä tai sopivilla välineillä (ja työllä) WS-tekniikat piilottavat heterogeenisuuden tasoista syntaksi-, rakenne- ja järjestelmätasot ovat melko hyvin Business semantics 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

13 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.

14 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

15 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

16 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?

17 Integroinnin tasoja: dataintegraatio Useissa eri lähteissä sijaitsevan ja usein heterogeenisen datan yhdistämistä ETL: extract, transform, load Heterogeenisuus: erilaiset skeemat, erilaiset koodaukset, merkitykset jne. Usein eräajoluontoista; soveltuu heikosti käytettäväksi usein muuttuvan datan kanssa Yleinen skeema Transform kohdistetaan kyselyihin

18 Dataintegrointi Kuvat: wikipedia.org/wiki/data_integration

19 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

20 Sovellusintegraatio Tavoitteena erillisten sovellusten välinen kommunikointi tai yhteentoimiminen Pääasiassa datan ja komentojen muuntamista epäyhteensopivien sovellusten välillä EAI esim.

21 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.

22 Shrinking common technology subset Traditional 'subtractive' approach to integrating systems: finding the common subset of technologies between the systems, starting with a physical connection between the systems. That subset is the basis for the integration, and additional layers of technology are built on top of it. (Kaye 2003) Two Windows DCOM apps J2EE & DCOM apps J2EE, DCOM & Yet Another Application

23 Sovellusintegraatio ja SOA? 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) Application A Application B Standardized Web-services interface Application C

24 Sovellusintegraatio ja SOA? No one should confuse the ease of using Web services interfaces with the difficulty of making Web services a reality.

25 Sovellusintegraatio ja SOA? Standardi API ei siis ole ihmeratkaisu tai hopealuoti Middleware uudella tekniikalla?

26 Prosessi-integraatio 3. Palvelutaso Prosessitaso 2. Palvelutaso Sovellustaso 1. Palvelutaso Datataso

27 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

28 IT- ja liiketoimintastrategiat SOA lupaa tuoda IT- ja liiketoimintastrategioita lähemmäksi toisiaan tai jopa yhdistää ne Perinteinen alignment-malli: Kritisoitu siitä, että ei huomioi nopeasti muuttuvan ympäristön asettamia paineita Ihannetilassa SOA mahdollistaa liiketoimintaprosessien muodostamisen, purkamisen ja muokkaamisen nopealla ja kustannustehokkaalla tavalla

29 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

30 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

31 BPEL4WS Inside-Out Prosessi kuvataan yhden osapuolen (omistajan) näkökulmasta Prosessit kytkeytyvät verkkopalveluihin WSDLrajapintojen kautta WSDL määrittelee prosessin operaatiot (esim. CheckCreditCard) BPEL määrittelee kuin operaatioiden suorittaminen jaksotetaan (esim. IF maksutapa = luottokortti THEN CheckCreditCard ELSE...)

32 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ä

33 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 WSTransaction -määritysten päälle

34

35

36 BPEL4WS Saman voi tietysti toteuttaa millä tahansa ohjelmointikielellä, joka tarjoaa tarvittavat kontrollirakenteet, poikkeusten käsittelyn, tuen asynkroniselle kommunikoinnille jne. ja jolla voidaan tehdä yli kutsuttavia sovelluksia Mutta BPEL, kuten muutkin nykyisistä SOAtekniikoista, on alusta- ja kieliriippumaton BPEL-prosessi on XML-dokumentti, joka on suoritettavissa minkä tahansa valmistajan BPEL-moottorilla (=> BPEL v.2)

37 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