Web service composition

Transkriptio

1 Web service composition 175

2 Workflows and Business Process Management (BPM) Workflows application-specific sequencing of various activities originally focused on content that required human processing typically distributed among a relatively large number of automated processes and/or people long duration processes that could be interrupted for managing the processes, which typically contain uncertain components and may be delayed (due to humans) BPM focuses on defining, executing, and managing of business processes not application-specific originally forcused on computer transactions 176 Liiketoiminnan monimutkaistuessa yhä useammat liiketoimintaprosessit ulottuvat osin myös yrityksen ulkopuolelle. Esimerkiksi osa liiketoimintaprosessin askeleista on saatettu ulkoistaa. Työkaluja on kehitetty sekä toisaalta liiketoimintaprosessien analysoinnin ja suunnittelun avuksi että näiden prosessien ajamiseksi. Workflow (suom. esim. työnkulku ) -hallintatyökaluja on perinteisesti käytetty eri sovellusspesifisten töiden priorisointiin ja järjestämiseen sekä työmäärän (tasaiseen) hajauttamiseen usean resurssin tai oikeamminkin ihmisen kesken. BPM-työkaluja on puolestaan kehitetty tukemaan yleisesti eri osapuolia (esim. yritys, sen partnerit, asiakkaat jne.) koskevien transaktioiden ajamista ja seurantaa. Työkulun hallintaan kuuluu kaksi oleellista käsitettä: prosessi ja aktiviteetti. Näistä prosessi on usein ainakin osittain automatisoitu tapahtumaketju organisaatiossa. Tässä tapahtumaketjussa työtehtävien koordinointi, viestintä ja hallinta on toteutettu peräkkäisinä tapahtumina. Itse työtehtävä on puolestaan aktiviteetti. Nämä aktiviteetit voidaan tehdä manuaalisesti tai ne voivat olla automatisoituja. Eroa työnkulun (workflow) järjestämisen ja liiketoimintaprosessin hallinnan (BPM) välillä voidaan tarkastella kahdesta näkökulmasta. Toisaalta erona on sovellusspesifisyys: työnkulun hallinta on tyypillisesti sovellusspesifistä, kun taas liiketoimintaprosessin hallinnassa keskitytään yleisiin, eisovellusspesifeihin menetelmiin määritellä, ajaa ja hallitta liiketoimintaprosesseja. Toisaalta eroa voidaan tarkastella automaatioasteen kannalta. Alunperin workflow-prosessien katsottiin aina sisältävän ihmisiä (usein paljonkin) eri työtehtävissä. Tämä puolestaan implikoi pitkäkestoisia toimintaprosesseja, jotka ovat alttiita keskeytyksille ja jotka sisältävät epävarmuustekijöitä. Liiketoimintaprosessin hallinta puolestaan on fokusoitunut tietokonetransaktioihin. Lisäksi BPM ja sitä tukevat työkalut, kuten edellä todettiin, tähtäävät näiden liiketoimintaprosessien ajamiseen ja seuraamiseen.

3 Web service conversations There is a need for describing complex interactions and transactions, since Web services may participate in longer conversations than just a single operation whether a certain operation can be performed may depend on the previous exchange of messages the way how the content of a message is to be interpreted may be influenced by the previous exchange provide compound services rather than atomic actions e.g. Web services that interact with complex back-end business processes or use some other Web services W3C Web Service Choreography Working Group focuses on developing mechanisms to co-ordinate the interactions among Web services in an interoperable way Requirements have been published and proposals exist Different viewpoints to Web service conversations. 177 Web-palvelukonsepti on suunniteltu käytettäväksi laajemmin kuin vain RPC-tyyppiseen interaktioon. Palvelut voivat olla ja monet ovatkin mukana monimutkaisemmissa kuin vain atomisissa interaktioissa. Web-palvelu voi esimerkiksi itse yhdistellä muiden Web-palveluiden tarjoamia palveluita. Näin ollen tuki transaktioille on tärkeää. Tällä hetkellä Web-palvelustandardit eivät sellaisenaan tue transaktioita. W3C:n Web service choreography työryhmä (working group) pyrkii kehittämään tapaa juuri näiden monimutkaisempien interaktioiden kuvaamiseen. Vaatimukset on kirjattu W3C:n sivuille ja ehdotuksia kuvauskieleksi on jo tehty. Viestiketjujen toteuttamisen yhtenä haasteena on se, että viestin tulkinta voi riippua viestiketjun aiemmista viesteistä. Lisäksi viestin koordinoinnin kannalta oleellisia kysymyksiä ovat: voidaanko viestit lähettää ja vastaanottaa mielivaltaisessa järjestyksessä? mitä sääntöjä liittyy viestijonon muodostamiseen? millaisia relaatioita on vastaanotettujen ja lähetettävien viestien välillä? onko viesti jonossa alkuviesti ja loppuviesti? voiko viestijono olla osittain suorittamatta? miten viestiketjua kokonaisuudessaan voidaan kuvata? jne.

4 Web service orchestration The business process is characterized from a central view and all interactions and actions are relative to this central view recursive composition of services refers to an executable business process that may interact with both internal and external Web services describes Web service interactions at message level, including business logic and execution order of the interactions interactions may involve many applications and/or organizations and may result in a long-lived transactional process model E.g. BPEL is used to define service orchestrations 178 Kuten jo aiemmin Web-palveluiden teknologiakerroksista puhuttaessa todettiin, palveluita ja niiden välistä interaktiota voidaan yhdistellä orkestroinnin ja palvelukoreografioiden avulla. Palveluiden orkestroinnissa liiketoimintaprosessiin on aina jokin tietty yksi prosessia suorittavan osapuolen näkökulma. Tällöin prosessiin kuuluvat interaktiot ja tapahtumat ovat aina suhteessa tähän keskeiseen näkökulmaan. Itse prosessi voi sisältää interaktioita eri palveluiden sisäisten tai ulkoisten kesken. Näin ollen kyseessä voi olla pitkäkestoinen useita sovelluksia ja/tai yrityksiä koskeva prosessi. Palveluiden orkestrointiin käytettävistä kielistä ehkä tunnetuin ja jo lähes käytännön standardin aseman saavuttanut kieli on BPEL. Tähän kieleen tutustumme myöhemmin.

5 Web service choreographies Characterized by the coexistence of a multiple views, which all are active and equal More collaborative than orchestration in nature: each party involved in the process describes the part they play in the interaction describes public message exchanges that occur between multiple Web services, rather than a specific business process that is executed by a single party e.g. WS-CDL is used to define service choreographies 179 Web-palvelukoreografia puolestaan tarjoaa tietyssä mielessä tasapuolisemman näkökulman kuin orkestrointi. Se ei oleta yhtä tiettyä keskeistä prosessia suorittavaa näkökulmaa. Sen sijaan se määritellään joukkona aktiivisia ja keskenään tasavertaisia näkökulmia. Jokainen prosessiin osallistuva osapuoli kuvaa suhteensa kyseiseen prosessiin. Koreografia noudattaakin prosessin kuvauksessa tietyssä mielessä puhtaammin alkuperäistä Web-palveluideologiaa; joukko keskenään tasa-arvoisia palveluita muodostaa yhteyksiä, tekee mahdollisesti sopimuksia ja kommunikoi keskenään. Palvelukoreografioita voidaan määritellä esimerkiksi W3C:n WS-CDL kielellä. Tällä kurssilla perehdytään tarkemmin palveluiden orkestrointiin kuin koreografioihin. Tämä siksi, että orkestroinnista (erityisesti BPEL-kielen avulla) on olemassa runsaammin käytännön esimerkkejä ja myös työkalutukea on paremmin saatavilla.

6 Service composition I.e., towards software integration not just point-to-point type of communication Various ways and languages while there is an agreement on Web services languages ( SOAP + WSDL), there is no as clear agreement on the orchestration or choreograhy language to be used WS-BPEL (OASIS) for orchestration WS-CDL (W3C) for choreograhies BPMN (OMG) for modeling business processes and a bunch of workflow languages connections and converters are being developed among different workflow and orchestration languages methods and tools for X2Y transformations 180 SOA tai Web-palvelukonsepti ei vielä varsinaisesti ota kantaa yksinkertaista kahdenvälistä kommunikaatiota (ns. point-to-point kommunikaatio) monimutkaisempaan ohjelmistojen tai järjestelmien integraatioon. SOA toki kuitenkin mahdollistaa myös monimutkaisempien transaktioiden toteutuksen ja ko. transaktioiden edellyttämä kommunikointi voidaan toteuttaa Web-palvelukonseptia sekä palveluiden orkestrointitapoja hyödyntäen. Vaikka varsinaisista Web-palvelutekniikoista ollaankin enemmän tai vähemmän päästy yksimielisyyteen (WSDL ja SOAP), sama ei vielä valitettavasti päde palveluiden orkestrointi- tai koreografiatekniikoille. Tällä hetkellä ehkä vahvimmalta ehdokkaalta vaikuttaa WS-BPEL, joka perustuu suhteellisen paljon käytettyyn BPEL-kieleen. BPEL-spesifikaatio käyttää UML aktiviteettikaaviota ns. workflow-määritysten mallintamiseen. OMG on puolestaan hiljattain ottanut BPMN-kielen osaksi standardiperhettään (aiemmin BPMI:n kehittämä) ja pyrkii saamaan sen lähitulevaisuudessa MOF-pohjaiseksi. BPMN ja UML aktiviteettikaaviot ovat itse asiassa hyvin lähellä toisiaan. Onkin mielenkiintoista nähdä miten nämä kaksi visuaalista mallinnuskieltä tulevaisuudessa suhtautuvat toisiinsa. Erona näillä kuitenkin on se, että BPMN on tarkoitettu nimenomaan liiketoimintaprosessien kuvaamiseen, kun taas UML aktiviteettikaavio on huomattavasti yleiskäyttöisempi. Edellä mainittujen lisäksi W3C tarjoaa oman WS-CDL kielensä. Näiden palveluiden orkestrointiin tähtäävien kielten lisäksi on tarjolla joukko workflow-kieliä (esim. XPDL), joita voidaan myös soveltaa tähän tarkoitukseen. Tämä kirjava joukko eri orkestrointi- ja workflowkieliä on johtanut siihen, että näiden kielten välisten suhteiden tutkimus ja esimerkiksi X2Y-tyyppisten muuntimien kehitys on ollut varsin vilkasta viime aikoina.

7 Business Process Execution Language (BPEL) A business process language, developed from WSFL and XLANG WSFL: Web Services Flow Language (by IBM), XML-based format to describe Web service compositions XLANG: extension of WSDL (by W3C), includes an additional element to desribe the behavior of the service as a part of a business process BPEL history: IBM and Microsoft proposed PBEL4WS (versions 1.0 and 1.1) OASIS took over the specifiction and named the new version into WS-BPEL 2.0 (not necessarily compatible to PBEL4WS) if specific version is not referred, BPEL is sufficient 181 BPEL-kieli on saavuttanut lähes de facto standardin aseman Web-palvelupohjaisten liiketoimintaprosessien kuvauskielenä. BPEL on kehitetty WSFL and XLANG kielten pohjalta ja näitä yhdistäen. WSFL on IBM:n kehittämä XML-pohjainen formaatti Web-palvelujen yhdistämisen kuvaamiseksi. XLANG on puolestaan WSDL-kielen laajennos, sisältäen elementin palvelun käyttäytymisen kuvaamiseksi osana liiketoimintaprosessia. XLANG-kieli kehitettiin, koska WSDL ei tarjoa tapaa määrittää viestinvälitykseen liittyvää käyttäytymistä liiketoimintaprosessiin osallistuvien Web-palveluiden kesken. BPEL-kielestä on useita versioita ja niistä käytetään myös hieman eri nimiä. Kielen kehitys alkoi IBM:n ja Microsoftin yhteistyöstä. Tuloksena syntyi BPEL4WS-kieli (version 1.0) (BPEL for Web Services) Web-palvelupohjaisten liiketoimintaprosessien kuvaamiseksi ja määrittämiseksi. Huhtikuussa 2003 BEA Systems, IBM, Microsoft, SAP ja Siebel Systems ehdottivat BPEL4WS kieltä OASIS-standardointiorganisaatiolle. Vaikka BPEL4WS-kielestä oli ilmestynytkin versiot 1.0 ja 1.1, OASIS WS-BPEL tekninen komitea päätti syyskuussa 2004 nimetä spesifikaation uudelleen, jolloin nimeksi tuli WS-BPEL 2.0. Nimen ja versionumeron vaihdos heijastelee myös huomattavia spesifikaatioon tehtyjä muutoksia. WS-BPEL 2.0 ja BPEL4WS eivät välttämättä ole edes kaikin osin (takaisinpäin) yhteensopivia. Käytännössä silloin, kun ei haluta viitata tiettyyn kielen versioon, käytetään kielestä lyhyesti nimeä BPEL.

8 BPEL Aims to support programming in the large focus from coding Web services and their functionalities ( programming in the small ) to orchestrating existing Web services into executable business processes business processes are automatically mapped to an execution langueage (BPEL) and executed by a process engine (BPEL engine) BPEL refers to high-level state transition interactions with an Abstract Process that represents a set of publicly observable behaviors: when to wait for messages, when to compensate for failed transactions etc. BPEL is an orchestration language, not a choreography language 182 BPEL pyrkii tukemaan ohjelmointia korkean abstraktiotason käsittein periaatetta. Peruslähtökohtana on se, että itse Web-palveluiden toteuttamisen sijaan ohjelmoijien pääfokus on olemassa olevien palveluiden orkestroinnissa. Tämä tarkoittaa käytännössä sitä, että BPEL on ajettava kieli: ohjelmoidut liiketoimintaprosessit voidaan automaattisesti ajaa nk. prosessimoottorilla (BPEL engine). Esimerkkejä BPEL-prosessimoottoreista ovat Active-BPEL (ActiveEndpoints), Oracle BPEL Process Manager (Oracle), WebSphere Process Server (IBM), BizTalk Server (Microsoft) sekä Cape Clear Orchestrator (Cape Clear). Usein tämä programming in the large -periaate viittaa prosessin korkean tason tilakäyttäytymiseen. Tätä tukemaan BPEL sisältää Abstract Process käsitteen, joka kuvaa ulospäin havaittavaa käyttäytymistä liittyen esimerkiksi viestien odottamiseen, viestien lähettämiseen ja virhetilanteisiin reagoimiseen.

9 BPEL design goals 1) Define business processes that interact with external entities through Web Service operations that are defined using WSDL 2) Define business processes using an XML based language 3) Define a set of Web service orchestration concepts that are meant to be used by both external (abstract) and internal (executable) views of a business process 4) Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible 5) Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow 183 BPEL-kieltä kehitettäessä sille asetettiin alun perin kymmenen suunnitteluperiaatetta ja tavoitetta. 1) BPEL-kielen tulee tukea sellaisten liiketoimintaprosessien kuvaamista, jotka kommunikoivat ulkopuolisten osapuolten kanssa WSDL-kielellä kuvattujen Web-palveluoperaatioden avulla. Tarkemmin sanottuna palveluiden operaatioiden kuvaus tulisi tukea WSDL 1.1 versiota. Tämä implikoi sen, että interaktioiden tulisi olla siinä mielessä abstrakteja, että riippuvuuksien tulisi olla porttype-elementtien välillä, ei port-elementtien välillä. 2) Liiketoimintaprosessit tulisi kuvata XML-pohjaisella kielellä. 3) BPEL-kielen tulee määritellä joukko Web-palveluiden orkestrointiin tarkoitettuja käsitteitä, joiden avulla voidaan kuvata sekä ulkoinen (abstrakti) että sisäinen (ajettava) näkymä liiketoimintaprosessiin. Orkestrointikielissä ulkoisen näkymän arvo on siinä, että se tietyssä mielessä laajentaa Web-palvelun kuvauksia käyttäytymisen kuvauksella ja näin ollen edesauttaa ennustettavuutta ja lopulta yhteentoimivuutta. Sisäisen näkymän arvo on puolestaan siinä, että se jossain määrin yksikäsitteistää ja selkeyttää prosessin mallintamisen käsitteet. 4) BPEL-kielen tulisi tukea sekä hierarkista että verkkopohjaista kontrollinhallintaa, sekä mahdollistaa näiden yhteiskäyttö mahdollisimman vaivattomasti. Tämän tavoitteen tarkoituksena on vähentää prosessin kuvauksen fragmentoitumista. Tämä tavoite juontaa juurensa siitä, että BPEL-kielen pohjana on WSFL- ja XLANG-kielet: XLANG-kieli esitti hierarkisen rakenteen kontrollirakenteille, kun taas WSFL esitti verkkorakenteen kontrollipatterneineen. Nämä kaksi näkökulmaa toisaalta heijastuvat BPEL-kielessä siten, että se toisaalta nähdään ajettavana kielenä ja toisaalta prosessinmäärittelykielenä.

10 BPEL design goals 6) Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level 7) Support the implicit creation and termination of process instances as the basic lifecycle mechanism 8) Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes 9) Use Web Services as the model for process decomposition and assembly 10)Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner 184 5) BPEL-kielen tulisi tarjota yksinkertaisia prosessidatan ja kontrollivuon määrittelemisessä tarvittavia funktioita datan käsittelemiseksi. Data-riippuvaisen käyttäytymisen määrittäminen on oleellista palveluiden orkestroinnissa. Sekä lähetetyissä ja vastaanotetuissa viesteissä että prosessia ohjaavissa ehdoissa käsitellään dataa. Prosessiin assosioitua dataa ei ole tarkoitettu käytettäväksi yleisemmin eikä prosessia varsinaisena datavarastona. Näin ollen myöskään BPEL-kielen datan manipulointiin tarkoitetuilta funktioilta ei edellytä yleisiä datan käsittelyyn tarvittavia ominaisuuksia; datan käsittely oletetaan suoritettavaksi itse Web-palveluissa, joita prosessi käyttää ja joita prosessista kutsutaan. BPEL-kielen datankäsittelyfunktioilta edellytetään ainoastaan sellaisia yksinkertaisia ominaisuuksia, joita tarvitaan prosessimallin määrittämisessä, kuten yksinkertainen viestin muodostaminen ja kontrollivuohon assosioitu datan kuvaus. 6) BPEL-kielen tulee tukea prosessi-instanssien identifiointia siten, että instanssitunnukset voidaan määritellä viestitasolla. Jokainen ajettava prosessi on tietyn prosessimallin instanssi. Näin ollen jokainen ajettava prosessi vaatii vähintään yhden yksikäsitteisen tunnisteen kyetäkseen välittämään tulevan viestin oikealle prosessimallin instanssille. BPEL ja WS-BPEL itse asiassa tukevat useiden käyttäjän määräämien tunnisteiden asettamisen prosessi-instanssille. Tämä tapahtuu viestitasolla: ko. tunnistetieto liitetään viesteihin (ts. WSDL abstrakteihin viesteihin) sen sijaan että ne tarvitsisi liittää kommunikaatioprotokollan header-informaatioon.

11 7) BPEL-kielen tulee tukea implisiittistä prosessi-instanssin luontia ja tuhoamista osana ko. instanssin elinkaarta. BPEL olettaa Web-palveluiden olevan tilallisia, koska liiketoimintaprosessi voi olla varsin pitkäkestoinenkin. WSDL sen sijaan olettaa palveluiden olevan tilattomia. BPEL pyrkii siihen, että asiakassovelluksen ei tarvitsisi erikseen huomioida näitä kahta eri palvelutyyppiä (tilalliset ja tilattomat) ja näin ollen asiakassovelluksen kannalta niiden rajapinnan tulee olla samanlainen (prosessin näkökulmasta). Tästä johtuen BPEL suosii prosessin elinkaaren implisiittistä hallintaa. Prosessimallin uusi instanssi luodaan automaattisesti, kun viesti osoitetaan asianmukaisesti annotoidulle prosessimallin ulkoistaman Web-palvelun operaatiolle. Prosessiinstanssi puolestaan tuhotaan, kun kontrollivuo saavuttaa prosessin viimeisen aktiviteetin tai jos kontrollivuo saavuttaa sellaisen aktiviteetin, joka eksplisiittisesti osana omaa aktiviteettiaan tuhoaa prosessi-instanssin. 8) BPEL-kielen tulee tarjota tuki pitkäkestoiselle transaktiomallille, joka tukee virheistä toipumista. Koska liiketoimintaprosessit voivat olla pitkäkestoisia, on virheistä toipuminen oleellista: virhetilanne tietyssä prosessin osassa ei saa johtaa siihen, että koko prosessi peruuntuu tai invalidoituu. Näin ollen virheen vaikutuksien tulee olla mahdollisimman paikallisia. Tämän vuoksi BPEL-kieleen (ja jo BPLE4WS-kieleen) on sisällytetty työyksikkö-käsite ( unit of work ), joka sallii peruutuksen (virhetilanteessa) pienissä yksiköissä. 9) Web-palveluja tulee käyttää prosessin jakamisessa ja koostamisessa. BPEL tukee prosessin jakamista ja koostamista aliprosessien avulla: liiketoimintaprosessi on Web-palvelu, jota voidaan käyttää myös muissa liiketoimintaprosesseissa, jotka niin ikään ovat Web-palveluita. BPEL siis käyttää tietynlaista rekursiivista aggregaatiomallia. 10) BPEL tulee rakentaa käyttäen tunnettuja ja hyväksyttyjä Web-palvelustandardeja ja se tulee tehdä mahdollisimman joustavasti ja modulaarisesti.

12 Abstract and Executable processes The basic concepts of WS-BPEL can be applied in one of two ways, Abstract or Executable. A WS-BPEL Abstract Process is a partially specified process that is not intended to be executed and that must be explicitly declared as abstract. Whereas Executable Processes are fully specified and thus can be executed, an Abstract Process may hide some of the required concrete operational details expressed by an Executable artifact. An abstract process specifies the external message interactions between Web services. It does not contain internal business process details. An executable process defines both the external message exchange and the complete internal details of the business logic. 185 BPEL sisältää sekä abstraktin että ajettavan prosessin käsitteet. Abstrakti prosessi kuten nimikin implikoi - on osittain määritelty prosessi, jota ei ole tarkoitettu ajettavaksi. Tällainen prosessi tulee eksplisiittisesti määritellä abstraktiksi. Jo aiemmin todettiin, että abstrakti prosessi kuvaa julkisesti havaittavaa käyttäytymistä liittyen esimerkiksi viestien odottamiseen, viestien lähettämiseen ja virhetilanteisiin reagoimiseen. Abstrakti prosessi toisin sanoen spesifioi (ulkopuolisesti havaittavaa) palveluiden välistä viestinvälitystä mutta ei sisällä yksityiskohtia liiketoimintaprosessista (vrt. abstraktit luokat). Ajettava prosessi sen sijaan on täysin määritelty prosessi ja siten myös ajettavissa oleva. Se määrittelee sekä ulkopuolisesti havaittavan viestinvälityksen että täydellisen liiketoimintalogiikan.

13 BPEL process The core element in a BPEL process is an activity. It contains instructions and control structures (c.f. a very simple programming language) BPEL process also includes variables, correlation sets, fault handlers, compensation handlers, and event handlers 186 BPEL-prosessin peruselementti on aktiviteetti. Aktiviteettia voidaan jopa verrata yksinkertaiseen ohjelmointikieleen käskyineen ja kontrollirakenteineen. Aktiviteettien lisäksi BPEL-prosessi voi sisältää mm. muuttujia ja tapahtumankäsittelijöitä. Ajettaessa (erityisesti pitkäkestoista) BPELprosessia, virhetilanteet eivät ole välttämättä harvinaisia. Näin ollen BPEL sisältää myös virheiden käsittelijöitä. Lisäksi jo suoritetut aktiviteetit saatetaan joutua peruuttamaan (undo), koska ne ovat osa pidempää transaktiota, josta on jostain syystä tyypillisesti virhetilanteesta johtuen jouduttu poistumaan. Ns. kompensaation käsittelijät sallivat sellaisten tapahtumien määrittämisen, jotka tulee suorittaa tietyn työyksikön peruuttamiseksi ja datan palauttamiseksi siksi mitä se oli ennen ko. työyksikön suorittamista. Tällaiset tapahtumat määritellään prosessi-instanssia luotaessa. Eri prosessin osapuolet (partner) kuvataan WSDL-kielellä tuttuun tapaan: WSDL-kuvaus kertoo tarjottavat palvelut ja miten palveluun saadaan yhteys. Näihin kuvauksiin (PortType) viitataan BPELkuvauksesta (invoke). BPEL-prosessi linkitetään loogisesti olemassa olevaan palveluun PartnerLinkelementin avulla.

14 BPEL activities Activities are modeled as composite patterns. Therefore, the top level activity is typically a structured activity (used for control flows) containing other activities, e.g. basic activities (operations). 187 Kalvolla on esitetty luokkakaaviona eri tyyppiset BPEL-aktiviteetit. Aktiviteetit mallinnetaan yleensä kompositioina. Tällöin ylimmän tason aktiviteetti on tyypillisesti rakenteinen aktiviteetti. Rakenteisia aktiviteetteja käytetään kontrollivuon kuvaamiseen (vrt. ohjelmointikielet). Tällainen rakenteinen aktiviteetti puolestaan tyypillisesti sisältää muita aktivteetteja, kuten perusaktiviteetteja, jotka ovat kuvaavat varsinaisia operaatioita. Esimerkiksi jo aiemmin mainittua invoke-aktiviteettia käytetään palvelun kutsumiseen. Tällä kurssilla ei käydä BPEL-kieltä yksityiskohtaisesti läpi. Esimerkkikuvauksiin voi tutustua vaikkapa tarkastelemalla BPEL-spesifikaatiota (kts. OASIS-konsortion sivuilta).

15 Modeling workflows and business processes As in software development in general, support for workflow design and modeling is important and needed Example modeling notations UML activity diagrams Business Process Modeling Notation (BPMN) originally proposed by BPMI Version 1.0 in March 2004 taken over by OMG in 2006 Version 1.0 adopted by OMG in February 2006 Version 2.0 is currently being developed 188 Palveluiden orkestrointiin on kehitetty ja ehdotettu useita eri kieliä, BPEL ja sen eri versiot esimerkkeinä sellaisista. Mutta kuten ohjelmistokehityksessä yleensäkin, tulee suunnittelu edeltää varsinaista toteutusta. Tämä tarkoittaa myös mallintamistarvetta. Työnkulkua voidaan mallintaa ja käytännössä myös mallinnetaan esimerkiksi UML aktiviteettikaavion avulla. Aktiviteettikaavio on kuitenkin yleinen notaatio eikä sitä ole tarkoitettu ainoastaan työnkulun tai palveluiden orkestroinnin mallintamiseen, vaikka se melko hyvin siihen sopiikin. BPMI (Business Process Management Initiative) Notation Working Group kehitti liiketoiminnan mallintamiseen BPMN-kielen, joka onkin otettu melko laajasti käyttöön. Vuosien 2005 ja 2006 aikana BPMI ja OMG yhdistivät voimansa ja BPMN-mallinnuskielestä tuli OMG:n ylläpitämä. BPMN:n virallinen versio tällä hetkellä on 1.0. Versio 2.0 on kuitenkin kehitteillä. Tarkoituksena on, että BPMN-kielestä tulee MOF-pohjainen (tästä lisää myöhemmin) UML-kielten tapaan. Tämä tarkoittaa käytännössä esimerkiksi sitä, että XMI-formaattia, jota käytetään esimerkiksi UML-mallien XMLpohjaisena tiedonsiirtoformaattina, voidaan käyttää myös BPMN-mallien tallettamiseen ja siirtämiseen eri työkalujen välillä. Tämä on tosin tällä hetkellä vasta suunnitteilla ja sen mahdollinen toteutuminen ja toteutumisajankohta jää nähtäväksi.

16 BPMN BPMN was to create a bridge from the businessoriented process modeling notation to IT-oriented execution languages that will implement the processes within a business process management system. 189 BPMN-spesifikaation mukaan BPMN pyrkii luomaan sillan liiketoimintaorientoituneen prosessimallintamisen ja IT-orientoituneiden ajettavien kielien välille. Tämä puolestaan implikoi, että BPMN-mallin muuttaminen esimerkiksi BPEL-määritykseksi tulisi olla melko suoraviivaista. Tällaisia konversiotyökaluja onkin jo itse asiassa kehitetty. BPMN-kielen tarkempaan opiskeluun löytyy materiaalia OMG:n sivuilta ja osoitteesta (kts. esim. Introduction to BPMN ).

17 BPMN elements Flow objects events (circles) activities (rounded rectangles) gateways (diamonds) Connecting objects sequence flow (solid line with a solid arrowhead) message flow (dashed line with an open arrowhead) association (dotted line with a line arrowhead) 190 BPMN notaatio sisältää tapahtumaelementtejä (vapaasti suom.) tapahtumaelementtejä yhdistäviä objekteja eri aliprosesseille omia osioita ja muita artifakteja Tapahtumaelementit puolestaan voivat olla tapahtumia, aktiviteettejä tai vuon yhdistämiseen tai jakamiseen tarkoitettuja päätössolmuja. Tapahtumat nimensä mukaisesti kuvaavat yksinkertaisia (osallistujasta riippumattomia) tapahtumia, kun taas aktiviteetit kuvaavat tietyn osallistujan tekemän työn. Tapahtumat visualisoidaan erilaisina ympyröinä, aktiviteetit pyöristettyinä suorakaiteina ja päätössolmut kärjellään seisovina neliöinä. Nämä elementit löytyvät myös mm. UML aktiviteettikaaviosta. Tapahtumaelementtejä yhdistävät objektit kuvaavat itse vuota ja ne voivat olla aktiviteettien suoritusjärjestystä kuvaavia (sequence flow), kahden osallistujan välisiä viestivoita (message flow) tai dataa tekstiä tai muita artifakteja yhdistäviä assosiaatioita (association). Sekvenssivuo kuvataan kiinteinä nuolina. Viestivuo kuvataan katkoviivoitettuna nuolena, jolla on eitäytetty nuolen pää. Assosiaatio puolestaan visualisoidaan pisteellisenä nuolena, jolla on avoin nuolenpää.

18 BPMN elements Swimlanes for organizing activities into separate visual categories in order to illustrate different functional capabilities or responsibilities pool for representing a participant in a process lane for representing subpartions of a pool Artifacts data object (notes) to show how data is required or produced by activities connected to activities with assosiations groups (rounded rectangle with dashed line) grouping can be used for documentation or analysis purposes, but does not affect the sequence flow annotations a mechanism for a modeler to provide additional text information for the reader of a BPMN diagram 191 Ns. swimlane -osioita käytetään aktiviteettien organisointiin erillisiin visuaalisiin osioihin. Nämä osiot tyypillisesti kuvaavat eri osallistujia kuvattavassa prosessissa. Tällaiset osallistujia kuvaavat osiot voidaan edelleen jakaa eri osiin. Muita artifakteja voivat puolestaan olla dataobjektit, ryhmät ja annotaatiot. Dataobjektit tarjoavat mekanismin esittää miten aktiviteetit tuottavat tai vaativat dataa. Dataobjektit yhdistetään aktiviteetteihin assosiaatioiden avulla. Ryhmiä puolestaan voidaan käyttää dokumentaation kuvaamiseen tai mallin (tai sen osien) analysointiin. Ryhmät eivät sinällään vaikuta sekvenssivuohon vaan edustavat lisäinformaatiota. Ryhmät kuvataan katkoviivoitettuina pyöristettyinä suorakulmioina. Annotaatioiden avulla taas voidaan lisätä malliin tekstuaalista informaatiota diagrammin lukijaa varten. Annotaatiot erotetaan muusta mallista kulmasulun kaltaisella notaatiolla.

19 BPMN BPMN model can contain two types of submodels: Private (internal) business processes internal to a specific organization and are the types of processes that have been generally called workflow or BPM processes Collaboration (global) Processes depict the interactions between two or more business entities interactions are defined as a sequence of activities that represent the message exchange patterns between the entities involved Abstract (public) processes the activities for the collaboration participants can be considered the touch-points between the participants; thus, the process defines the interactions visible to the public for each participant. 192 BPMN malli voi sisältää kahdentyyppisiä malleja aliprosesseista: Sisäiset liiketoimintaprosessit. Nämä ovat organisaatiospesifejä ja näin ollen organisaation sisäisiä. Näitä kutsutaan yleisesti työnkulku- tai BPM-prosesseiksi Kollaboraatioprosessit. Nämä kuvaavat kahden tai useamman liiketoimintaosapuolen välistä interaktiota. Kyseinen interaktio määritellään aktiviteettijonona, joka puolestaan edustaa viestinvälitysmalleja osapuolten välillä. Yksi kollaboraatioprosessityyppi on nk. abstraktit prosessit. Kollaboraatioprosessin aktiviteetit voidaan ajatella tietynlaisina osallistujien rajapintoina, jolloin kyseiset aktiviteetit edustavat osallistujan julkisesti näkyvää toimintaa. Tällöin kollaboraatioprosessi määrittelee jokaiselle osallistujalle näkyvän julkisen interaktion.

20 Example BPMN diagram (BPMN 1.0 spec.): 193

21 Some research topics on SOA and Web services (Web) service composition modeling support many workflow and service composition languages transformations (methods and tools) Web services and Semantic Web Semantic Web techniques can make Web service systems more efficient Especially Internet-based messaging is always slow Transferring only essential information Semantic Web techniqes can be used for finding the essential information metainformation descriptions Not many real applications available 194 Yksi ehkä tällä vilkkaimmin tutkituista palvelujen käyttöön liittyvistä ongelma-alueista on palveluiden yhdistämisen ja workflow-kuvausten mallintaminen. Vaikka BPEL-kieli onkin saavuttanut tietyssä mielessä käytännön standardin aseman palveluperustaisten järjestelmien liiketoimintaprosessien kuvauskielenä, muitakin kieliä on toki ehdotettu ja niitä käytetään. Eri kielet on kehitetty hieman eri tarkoituksiin ja hieman erilaisia vaatimuksia silmällä pitäen. Tämän vuoksi tällä hetkellä kehitetään runsaasti sekä työkaluja ja menetelmiä varsinaisten palveluiden koordinointikuvausten tuottamiseksi korkean tason workflow-malleista. Myös muuntimia eri workflow-kielten välille on kehitetty. Tällä kurssilla ei käsitellä tarkemmin Semanttista Webiä. Siihen voi kuitenkin tutustua esimerkiksi W3C:n Suomen toimiston sivuilla, jonka esitelmäarkistosta löytyy useita esityksiä aiheesta. Perusideana Semanttisessa Webissä on kuvata (Webissä esitettävälle) tiedolle annettava metatieto tavalla, joka on ohjelmallisesti käsiteltävissä ja hyödynnettävissä esimerkiksi tiedon hakua varten. Koska tiedonsiirto erityisesti Internetissä on aina hidasta, on tarkoituksen mukaista siirtää vain oleellinen tieto. Tämä puolestaan edellyttää sen, että tämä oleellinen tieto voidaan helposti löytää. Tiedon tehokasta löytämistä taas tukee metatiedon mahdollisimman hyvä ja kattava esittäminen, jota erilaiset hakukriteerit voivat hyödyntää. Semanttisen Webin tekniikoiden hyödyntäminen Webpalvelujärjestelmissä tarjoaakin näin ollen mahdollisuuden ko. järjestelmien tehostamiseksi. Rekisterit (kuten UDDI) tavallaan hyödyntävätkin metatiedon käyttöä eri kategorisointimekanismeillaan. Käytännössä ei vieläkään ole useita Web-palveluiden ja Semanttisen Webin yhdistämistä tukevia sovelluksia olemassa.

22 Some research topics on SOA and Web services Migrating old legacy systems to SOA/Web services identification of the services decision on the communication mechanism wrapping techniques Support for modeling and software development processes Mobile Web services 195 Yksi tärkeä tutkimus- ja sovelluskohde on vanhojen legacy-järjestelmien toiminnallisuuden tarjoaminen Web-palveluina. Käytännön tarve sille on tällä hetkellä suuri. Tämä edellyttää ensinnäkin sen, että päätetään mikä toiminnallisuus tarjotaan palveluna. Se puolestaan edellyttää palveluiden identifioinnin. Tämän jälkeen tulee päättää kommunikointitavasta ja kommunikoinnin abstraktiotasosta sekä valita sopiva käärimistapa. Yksi ohjelmistotuotannon näkökulmasta kiinnostava ja oleellinen haaste on myös ohjelmistosuunnitteluprosessin eri vaiheiden huomion ottaminen Web-palveluja toteutettaessa. Tämä edellyttää myös mm. tukea palveluiden ja palveluiden koordinoinnin mallintamiselle. Myös palveluiden tarjoaminen mobiililaitteissa on kiinnostava ja tällä hetkellä akuutti tutkimus- ja kehityskohde. Mobiililaitteita käytetään tällä hetkellä pääasiassa asiakassovellusten ajamiseen. Mobiilius tuo mukanaan myös muita kiinnostavia ja Web-palvelukonseptissa hyödynnettäviä näkökulmia, kuten kontekstisensitiivisyyden.

23 Web services challenges Many standards, techniques, and tools and their many versions Variety of tools a lot of support for RPC-style communication less support for document-oriented communication, which is the intended use of Web services Secure messaging: message encryption, digital signatures, access rights etc. support available to choose from techniques to be used need to be agreed on important/curcial for business critical applications Support for (business) transactions Support for agreement-based communication e.g. ebxml 196 Web-palvelukonseptin käyttöön ottoon liittyy vielä paljon ongelmia. Yksi niistä on standardien jatkuva kehitys ja toisaalta myös työkalutuen kehittyminen ja sen monimuotoisuus. Tällä hetkellä saatava työkalutuki keskittyy pääasiassa RPC-tyyppiseen kommunikointiin, kun taas tuli dokumenttipohjaiselle kommunikoinnille on puutteellisempaa. Se on luonnollisesti myös haasteellisempaa ja vaatii enemmän käsityötä erityisesti palvelua toteutettaessa. Turvallisuus on Internet-pohjaisen Web-palveluiden käytön kannalta ehkä suurin haaste. Vaikkakin menetelmiä tietoturvan lisäämiseksi on kehitetty (digitaaliset allekirjoitukset ja kryptausmenetelmät), niin yleistä käytäntöä näiden menetelmien käytöstä Web-palveluinteraktioissa standardista puhumattakaan ei vielä ole. Yksi käytännön kannalta ongelmallinen asia on myös transaktioiden ja palveluiden koordinoinnin tuen vajavaisuus, tosin W3C:n Web Service Choreography -työryhmän ja OASIS-konsortion kehittämät menetelmät ja standardit tähtäävät näiden ongelmien ratkaisemiseen. Liiketoimintatransaktioita tuetaan kuitenkin paremmin esimerkiksi ebxml-konseptissa, jossa on lisäksi tuki sopimuspohjaisuudelle. Koska liiketoimintatransaktioita on vaikea koostaa yksittäisistä viesteistä, aiheuttaa se mahdollisesti enemmän liikennettä asiakassovelluksen ja palvelun välillä. Lisäksi se joissain tapauksissa edellyttää joko asiakaspäähän tai palvelupäähän lisää tarvetta prosessoida viestejä ja yhdistellä tietoja. Sillä on myös vaikutus tehokkuuteen. Tehokkuusongelmat toki koostuvat monista asioista: XML-pohjaisen tiedon prosessointi on tyypillisesti hidasta, asiakassovelluksen mahdollisesti käyttämä dynaaminen proxy tai dynaaminen kutsurajapinta saattavat aiheuttaa hitautta jne.

24 Web service challenges Efficiency XML processing is slow possible use of encryption methods and digital signatures is slow decryption, signature validation etc. Reliability,accessibility, and availability Error recovery dynamically Maintenance is Web service maintainance essentially more difficult, less difficult, or different from software maintenance problems in general? QoS requirement e.g. response times 197 Tehokkuus on usein ongelma XML-pohjaista tietoa käsiteltäessä. Lisäksi Web-palvelujärjestelmissä saatetaan käyttää kryptausmenetelmiä ja digitaalisia allekirjoituksia, joita koskevaa tietoa kuljetetaan SOAP-viestissä. Tämä hidastaa huomattavasti viestien käsittelyä: prosessoitavaa XML-pohjaista tietoa on usein huomattavastikin enemmän ja ennen kaikkea allekirjoitusten validointi, kryptauksten purkaminen jne. vaatii huomattavasti prosessointia. Turvallisuus Web-palvelujärjestelmissä ei rajoitus turvalliseen viestinvälitykseen, vaan sen lisäksi tulisi huolehtia siitä. että palvelut ovat saatavilla, ne toimivat luotettavasti ja ongelmatilanteissa voidaan virhetilanteista toipua dynaamisesti. Virheestä toipuminen voi tarkoittaa esimerkiksi sitä, että ei saatavilla oleva palvelu voidaan tarvittaessa korvata toisella saman toiminnallisuuden tarjoavalla palvelulla. Palvelujärjestelmien ylläpidettävyys onkin mielenkiintoinen ja haasteellinen kysymys, koska palvelujärjestelmillä ei ehkä ole yhtä instanssia, jolla olisi jonkinlainen keskitetty vastuu kaikista käytetyistä palveluista. Edellä mainittujen lisäksi myös laatuattribuuttien (Quality of Service, QoS) käyttö ja hallinta (esimerkiksi koskien vasteaikoja tms.) saattaa vaatia järjestelyitä, joihin ei ole olemassa mitään standardiratkaisuja. Edellä on lueteltu vain muutama Web-palveluiden tämän hetken haasteista. Tuleeko mieleesi muita haasteita?