Web service composition

Transkriptio

1 Web service composition 128

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

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

4 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 I.e., towards software integration not just point-to-point type of communication 130 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 viestijonossa alkuviesti ja loppuviesti? voiko viestijono olla osittain suorittamatta? miten viestiketjua kokonaisuudessaan voidaan kuvata? jne.

5 Web service conversations Web service composition can be seen as a way to master complexity programming in the large : (Web) services are the basic building blocks and composition techniques provide the means to build programs from them Requirements have been published and proposals exist Different viewpoints to Web service conversations. 131 Palveluiden yhdistäminen pitkäkestoisimmiksi ja monimutkaisemmiksi prosesseiksi voidaan nähdä myös yhtenä tapana hallita kompleksisuutta. Termi programming in the large onkin otettu uudelleen käyttöön myös tässä kontekstissa: palvelut edustavat peruspalikoita, joita yhdistelemällä eri tavoin voidaan rakentaa varsinaista haluttua toiminnallisuuutta. Tämä on toki aika idealistinen näkemys. Käytännössä se edellyttäisi ohjelmointikieliin verrattavia ominaisuuksia palveluiden koordinointikieliltä, riittävän laajaa ja kattavaa palveluiden joukkoa sekä palveluiden oikeaa abstraktiotasoa joustavuuden aikaansaamiseksi. Useita kieliä ja näkökulmia tällaiseen palveluiden yhdistämiseen onkin jo ehdotettu. Aihe on ehkä yksi tällä hetkellä kaikkein aktiivisimmin tutkittuja aiheita SOA:n ja sen hyödyntämiseen liittyen.

6 Service composition 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 132 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 Web service orchestration The business process is characterized from a central view and all interactions and actions are relative to this central view Invoked services do not know they are a part of a orchestration Recursive composition of services Refers to an executable business process that may interact with both internal and external Web services BPEL is the most commonly used language to define service orchestrations 133 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, tapahtumat ja osallistujat 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. Huomattavaa on myös se, että orkestraatiossa siihen kuuluvat palvelut (siis kutsuttavat palvelut) eivät itse tiedä olevansa osa orkestraatiota; ne saavat kutsun ja tyypillisesti vastaavat siihen, aivan normaaliin tapaan. 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.

8 Web service choreographies Characterized by the coexistence of multiple views, which all are active and equal Does not have a central viewpoint 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 Each Web service is aware of the choreography and knows exactly when to execute its operations e.g. WS-CDL is used to define service choreographies 134 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. Vastoin kuin orkestraatioissa, koreografiaan kuuluvat palvelut tietävät kuuluvansa koreografiaan sekä sen, milloin niiden tulee suorittaa tarjoamansa palvelu. 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.

9 Business processes and services systems Viewpoints/ people: Business/ process designer Business activity Business activity Business activity Notations/ artefacts used: Business process models/ e.g. BPMN, UML IT/ process designer, integration developer IT/ service developers, software maintainers assign invoke receive assign WS1 WS2 WS3 WSn Databases Legacy systems Java Service composition/ e.g. BPEL Web services Existing systems 135 Kalvon kuvassa on esitetty palvelupohjaisten järjestelmien toteuttamiseen tarvittavat ja käytettävät käsitteet, notaatiot ja näkökulmat. Ideaalitapauksessa suunnittelu alkaa liiketoimintaprosessien suunnittelusta. Tämä vaihe ei vielä välttämättä edes huomioi olemassa olevaa teknologiaa tai olemassa olevia järjestelmiä. Seuraavaksi alkaa näiden liiketoimintaprosessien ja aktivitieettien teknisen toteuttamisen suunnittelu. Ne voidaan toteuttaa esimerkiksi ajettavina palveluorkestraatioina, kuten BPEL-prosesseina. Huomaa, että liiketoimintatason prosessi ja toisaalta toteutustekninen prosessi ovat eri asioita eikä niillä välttämättä ole yksi-yhteen -vastaavuutta. Liiketoimintaprosessit ovat esimerkiksi tyypillisesti abstraktimpia kuin tekniset prosessit. Kalvon kuvassa prosessisuunnittelu ja toteutus on kuvattuna kahtena erillisenä tasona. Käytännössä kuitenkin eri abstraktiotasoja voi olla useita. Palveluorkestraatiot puolestaan hyödyntävät joukkoa palveluita. Mikäli kyseessä on BPEL-prosessi, tulee kutsuttavilla palveluilla olla WSDL-rajapinta. Oleellisesti kyse on siis Web-palveluista. Nämä palvelut voivat puolestaan olla tai hyödyntää olemassa olevia legacy-järjestelmiä, tietokantoja jne.

10 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 136 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 1.1 -kieltä OASISstandardointiorganisaatiolle. 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.

11 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 137 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.

12 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 138 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

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

14 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 139 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:n abstrakteihin viesteihin) sen sijaan että ne tarvitsisi liittää kommunikaatioprotokollan header-informaatioon. 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. Prosessi-instanssi puolestaan tuhotaan, kun kontrollivuo saavuttaa prosessin viimeisen aktiviteetin tai jos kontrollivuo saavuttaa sellaisen aktiviteetin, joka eksplisiittisesti osana omaa aktiviteettiaan tuhoaa prosessi-instanssin.

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

16 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. 140 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). Abstraktilla prosessilla voidaan esimerkiksi kuvata prosessi jollekin toiselle osapuolelle, jonka tehtävänä on toteuttaa se. 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.

17 BPEL and other standards WS-BPEL utilizes several XML specifications: WSDL 1.1, XML Schema 1.0, provide the data model used by WS-BPEL processes All external resources and partners are represented as WSDL services A WS-BPEL process can be associated with a WSDL definition -> the process can be treated as a Web service itself XPath 1.0 and XSLT 1.0. provide support for data manipulation 141 WS-BPEL standardi hyödyntää useita muista XML-pohjaisia tai XML:n käsittelyyn tarkoitettuja standardeja. Tietotyyppien kuvaamiseen se käyttää WSDL- ja XML Schema standardeja. Esimerkiksi kaikki ulkopuoliset resurssit ja partnerit eli esim. prosessista kutsuttavat palvelut kuvataan WSDL:n avulla. Itse asiassa itse orkestraatioon (WS-BPEL instanssi) voidaan liittää WSDL-kuvaus. Tämä mahdollistaa orkestraation itsensä käyttämisen Web-palveluna. Se tarkoittaa sitä, että prosessia voi kutsua esim. asiakassovellus, joka sekin voi tietenkin olla prosessi. Tällainen orkestraatiota kuvaavava WSDLdokumentti saattaa sisältää myös WS-BPEL spesifejä elementtejä (kuten partnerlinktype, jota käsittelemenne seuraavaksi), jotka siis ovat laajennoksia puhtaaseen WSDL-kuvaukseen. Datan manipuloimiseen WS-BPEL standardi puolestaan hyödyntää XPath- ja XSLT-standardeja.

18 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 142 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 (partners) 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.

19 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). Basic activities cannot contain other activities. Structured activities, in turn, can (basic or structured). They offer a way to structure a BPEL process 143 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 rakenteen kuvaamiseen (vrt. ohjelmointikielet). Tällainen rakenteinen aktiviteetti puolestaan tyypillisesti sisältää muita aktivteetteja, joko perusaktiviteetteja, jotka ovat kuvaavat varsinaisia operaatioita, tai rakenteisia aktiviteetteja. 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).

20 Other BPEL constructs Partner links, modelled as partnerlink elements represent entry and exit points of a BPEL process Web services involved (called) in the process links to clients that invoke the BPEL process Each partner plays a role in the process, and each role is linked to a WSDL porttype.this is defined using partnerlinktype elements that are often given in the WSDL document of the process characterize the conversational relationship between two services by defining the roles played by the services and specifying the porttypes (interfaces) provided by the service called Each <role> specifies exactly one WSDL porttype. Example: <partnerlinktype name= RequestorSellerLink xmlns=" <role name= Requestor"> <porttype name="buy:requestorporttype"/> </role> <role name="seller"> <porttype name="sell:sellerporttype"/></role> </partnerlinktype> 144 WS-BPEL 2.0 spesifikaatio löytyy OASIS-organisaation sivuilta, kts. Esim. (WS-BPEL 2.0 spec.): Seuraavaksi BPEL-käsitteitä havainnollistetaan esimerkin avulla. Tämä esimerkki löytyy WS-BPEL 2.0 spesifikaatiosta. Esimerkkiprosessi kuvaa tilauksen hallintaa. WSDL-kuvauksen osa on esitetty alla. Sen lopussa on <partnerlinktype>-elementit (alla olevassa esimerkissä vain osin), jotka kuvaavat tialuspalvelun (purchase order service) ja muiden osapuolien välistä kommunikointia. <wsdl:definitions targetnamespace=" xmlns:sns=" xmlns:pos=" xmlns:wsdl=" xmlns:plnk=" xmlns:xsd="

21 ... <!-- porttypes supported by the purchase order process --> <wsdl:porttype name="purchaseorderpt"> <wsdl:operation name="sendpurchaseorder"> <wsdl:input message="pos:pomessage" /> <wsdl:output message="pos:invmessage" /> <wsdl:fault name="cannotcompleteorder" message="pos:orderfaulttype" /> </wsdl:operation> </wsdl:porttype> <plnk:partnerlinktype name="purchasinglt"> <plnk:role name="purchaseservice" porttype="pos:purchaseorderpt" /> </plnk:partnerlinktype> </wsdl:definitions>

22 Other BPEL constructs partnerlink elements Contain the following attributes partnerlinktype: characterizes the conversational relationship between two services name: used for all service interactions via that partnerlink myrole: the role of the BPEL process instance itself partnerrole: the role of the partner initializepartnerrole specifies whether the WS-BPEL processor is required to initialize a <partnerlink>'s partnerrole value. initializepartnerrole attribute must not be used on a partner link that does not have a partner role. 145 Seuraavaksi käydään läpi itse WS-BPEL -prosessi. Sen <partnerlinks>-osio määrittelee ne osapuolet, jotka kommunikoivat prosessin kanssa. Määritellyt neljä <partnerlink> elementtiä vastaavat Tilauksen lähettäjää (customer), Hinnan tarjoajia (invoicing provider), Tilauksen lähettäjää (shipping provider) sekä Tuotannon aikataulusta vastaavaa palvelua (scheduing provider). Jokainen <partnerlink> on kuvattu <partnerlinktype>-elementillä (annettu WSDL-kuvauksessa edellä) sekä yhdellä tai kahdella roolilla. Tällä informaatiolla identifioidaan prosessin toiminnallisuus sekä ne rajapinnat (porttype), jotka tulee toteuttaa. <process name="purchaseorderprocess" targetnamespace=" xmlns=" xmlns:lns="

23 <documentation xml:lang="en"> A simple example of a WS-BPEL process for handling a purchase order. </documentation> <partnerlinks> <partnerlink name="purchasing" partnerlinktype="lns:purchasinglt" myrole="purchaseservice" /> <partnerlink name="invoicing" partnerlinktype="lns:invoicinglt" myrole="invoicerequester" partnerrole="invoiceservice" /> <partnerlink name="shipping" partnerlinktype="lns:shippinglt" myrole="shippingrequester" partnerrole="shippingservice" /> <partnerlink name="scheduling" partnerlinktype="lns:schedulinglt" partnerrole="schedulingservice" /> </partnerlinks>

24 Other WS-BPEL constructs Variables Variables are used to hold the state of the process by storing messages that constitute a part of the state of the process holding data -> variables can either contain a WSDL message or an XSD value The messages stored are often those that have been received from partners or are to be sent to partners The variables can be defined in the terms of WSDL message types, XML Schema types, or XML Schema elements 146 Muuttujia voidaan käyttää WS-BPEL kuvauksessa tallettamaan prosessin tila. Niiden käyttö vastaa muuttujien käyttöä ohjelmointikielissä. WS-BPEL:ssä muuttujaan vaoidaan tallettaa joko data (XSDmuodossa) tai viestejä (WSDL:n message-muodossa). Usein saattaa olla esimerkiksi tarve tallettaa partnereilta saadut tai niille lähetettävät viestit muuttujiin. Esimerkki jatkuu: Seuraavaksi määritellään käytettävät muuttujat: <variables> <variable name="po" messagetype="lns:pomessage" /> <variable name="invoice" messagetype="lns:invmessage" /> <variable name="shippingrequest" messagetype="lns:shippingrequestmessage" /> <variable name="shippinginfo" messagetype="lns:shippinginfomessage" /> <variable name="shippingschedule" messagetype="lns:schedulemessage" /> </variables>

25 Other WS-BPEL constructs Scopes, given as scope elements provides the context that influences the execution behavior of its enclosed activities This behavioral context includes variables, partner links, message exchanges, correlation sets, event handlers, fault handlers, a compensation handler, and a termination handler. 147 WS-BPELin yksi oleellinen käsite on konteksti, joka määritellään scope-elementtien avulla. Kontekstit ovat tarpeellisia esimerkiksi virheiden käsittelyn (käsitellään seuraavaksi) kannalta. Virheitä saattaa esiintyä milloin tahansa prosessin ajon aikana. Niitä voi aiheutua esimerkiksi siitä, että kutsuttu palvelu ei ole saatavilla. WS_BPELin virheiden käsittelijät liitetään aina tiettyyn kontekstiin (scope). Oleellisesti virheen käsittely liittyy tiettyyn aktiviteettiin. Mikäli virhettä ei siepata lokaalisti, se välitetään seuraavalle, kyseistä kontekstia ympäröivälle kontekstille. Kontekstit liitetään myös esimerkiksi kompensaation käsittelijöihin (käsitellään seuraavaksi), muuttujiin jne.

26 Other WS-BPEL constructs Compensation handlers Compensation: undoing steps in the business process that has already completed successfully The goal: for a part of a business process that is being abandoned, to reverse the effects of previous activities that have been carried out Compensation handlers are used to specify that part of the behavior is meant to be reversible, in certain scope, in an application-defined way. Fault handlers The completion of the activity of a fault handler is not considered successful completion of the attached scope. If a fault handler is associated to a scope and that fault handler has been invoked, then a compensation is not enabled for that scope. 148 Kompensaatioita käytetään tietyssä mielessä peruuttamiseen. Jos esimerkiksi jokin prosessi-instanssi päätyy virheeseen ja kyseinen instanssi tulee näin ollen hylätä, tulee jo suoritetut toimenpiteet voida peruuttaa. WS-BPEL tarjoaa tähän kompensaatiomekanismin. Virhetilanteessa normaali prosessointi lopetetaan ja kontrolli siirtyy virheiden käsittelijälle. WS-BPEL tukee sekä sovellusspesifien (business faults) että ajonaikaisten virheiden (runtime faults) käsittelyä. Edelliset esiintyvät joko kun prosessimoottori ajaa eksplisiittisesti määritellyn <throw>-aktiviteetin tai kun <invoke>-aktiviteetti vastaanottaa virheilmoituksen vastauksena. Ajonaikaiset virheet voivat aiheutua mm. siitä, että kutsuttu palvelu ei ole saatavilla. Ajonaikaisien virheiden käsitteleminen ei edellytä sitä, että käyttäjä määrittelee ne eksplisiittisesti. WS-BPEL määrittelee 10 standardivirhettä: selectionfailure, conflictingreceive, conflictingrequest, mismatchedassignmentfailure, joinfailure, forcedtermination, correlationviolation, uninitializedvariable, repeatedcompensation, and invalidreply.

27 Esimerkki jatkuu: Seuraavaksi määritellään virheiden käsittelijät. Ne määrittelevät ne toimenpiteet, jotka täytyy suorittaa mikäli kutsut epäonnistuvat. <faulthandlers> <catch faultname="lns:cannotcompleteorder" faultvariable="pofault" faultmessagetype="lns:orderfaulttype"> <reply partnerlink="purchasing" porttype="lns:purchaseorderpt" operation="sendpurchaseorder" variable="pofault" faultname="cannotcompleteorder" /> </catch> </faulthandlers>

28 Other WS-BPEL constructs Correlations During its lifetime, a business process instance typically holds one or more conversations with partners involved in its work Correlations are used for ensuring that the right service or process instance is used/referred to Event handlers A process can react to message events or alarm events <onalarm> marks a time-driven event. there MUST be at least one <for>, <until>, or <repeatevery> expression. <onevents> indicates that the specified event waits for a message to arrive. 149 Prosessi-instassi tyypillisesti keskustelee tyypillisesti usean partnerin kanssa elinaikanaan eli aikana, joka kuluu kyseisen prosessin määrittelemän toiminnallisuuden suorittamiseen. Lisäksi saman prosessin useaa instanssia voidaan ajaa samanaikaisesti. Näin ollen tarvitaan mekanismi, jonka avulla voidaan varmistua siitä, että kulloinkin keskustellaan oikean partnerin kanssa. Tämä toteutetaan korrelaatioiden (correlations) avulla. WS-BPEL spesifikaatio kuvaa korrelaation käytön tarkemmin. Virheiden- ja kompensaatiokäsittelijöiden lisäksi WS-BPEL tarjoaa tapahtumien käsittelijöitä. Jokaisella kontekstilla (scope), sekä globaalilla prosessikontekstilla että lokaaleilla konteksteilla, voi olla tapahtumien käsittelijöitä. Tapahtumien käsittelijöitä voidaan ajaa samanaikaisesti ja niitä kutsutaan kun tietyn tapahtuman esiintyessä. Tapahtumien käsittelijöitä on kahta eri tyyppiä: viestin odotusta indikoivia (onmessage) ja aikaan sidottuja (onalarm).

29 Structured activities sequence: for defining a set of activities to be invoked in an ordered sequence flow: for defining a set of activities to be invoked in parallel while: for defining loops repeatuntil: repeated execution of a contained activity. The contained activity is executed until the given boolean condition becomes true if: provides conditional behavior pick: used to wait for one of several possible messages to arrive or for a time-out to occur. When one of these triggers occurs, the associated child activity is performed. 150 WB-BPEL tarjoaa joukon rakenteisia aktiviteetteja. Niiden avulla prosesseihin voidaan luoda erilaisia rakenteita. Monet niistä vastaavat ohjelmointikielistä tuttuja käsitteitä, kuten toistoa ja ehdollisuutta määrittelevät rakenteiset aktiivitettit. Kuten ohjelmointikielissäkin, myös WS-BPELin rakenteiset aktiviteetit voivat olla sisäkkäisiä. Esimerkki jatkuu: WB-BPEL esimerkin loppuosa sisältää käyttäytymiskuvauksen tilauspyynnön käsittelystä. <sequence> <receive partnerlink="purchasing" porttype="lns:purchaseorderpt" operation="sendpurchaseorder" variable="po" createinstance="yes"> <documentation>receive Purchase Order</documentation> </receive>

30 <flow> <documentation> A parallel flow to handle shipping, invoicing and scheduling </documentation> <links> <link name="ship-to-invoice" /> <link name="ship-to-scheduling" /> </links> <sequence> <assign> <copy> <from>$po.customerinfo</from> <to>$shippingrequest.customerinfo</to> </copy> </assign> <invoke partnerlink="shipping" porttype="lns:shippingpt" operation="requestshipping" inputvariable="shippingrequest" outputvariable="shippinginfo"> <documentation>decide On Shipper</documentation> <sources> <source linkname="ship-to-invoice" /> </sources> </invoke> <receive partnerlink="shipping" porttype="lns:shippingcallbackpt" operation="sendschedule" variable="shippingschedule"> <documentation>arrange Logistics</documentation> <sources> <source linkname="ship-to-scheduling" /> </sources> </receive>

31 </sequence> <sequence> <invoke partnerlink="invoicing" porttype="lns:computepricept" operation="initiatepricecalculation" inputvariable="po"> <documentation> Initial Price Calculation </documentation> </invoke> <invoke partnerlink="invoicing" porttype="lns:computepricept" operation="sendshippingprice" inputvariable="shippinginfo"> <documentation> Complete Price Calculation </documentation> <targets> <target linkname="ship-to-invoice" /> </targets> </invoke> <receive partnerlink="invoicing" porttype="lns:invoicecallbackpt" operation="sendinvoice" variable="invoice" /> </sequence> <sequence> <invoke partnerlink="scheduling" porttype="lns:schedulingpt" operation="requestproductionscheduling" inputvariable="po"> <documentation> Initiate Production Scheduling </documentation>

32 </invoke> <invoke partnerlink="scheduling" porttype="lns:schedulingpt" operation="sendshippingschedule" inputvariable="shippingschedule"> <documentation> Complete Production Scheduling </documentation> <targets> <target linkname="ship-to-scheduling" /> </targets> </invoke> </sequence> </flow> <reply partnerlink="purchasing" porttype="lns:purchaseorderpt" operation="sendpurchaseorder" variable="invoice"> <documentation>invoice Processing</documentation> </reply> </sequence> </process>

33 Simple activities invoke: for invoking another web service receive: to wait for the client to invoke the business process by sending a message, i.e. receiving a request reply: for generating a response for a synchronous operation assign: to manipulate variables throw: to indicate faults and exceptions wait: to wait for a given time period or until a certain point of time terminate: to terminate the whole process 151 WS-BPEL tarjoaa rakenteisten aktiviteettien lisäksin yksinkertaisia aktiviteetteja. Ne ovat pienimpiä mahdollisia WS-BPEL-prosessien osia eivätkä siten voi sisältää muita aktiviteetteja.

34 WS-BPEL specification models the behavior of the example process (at an abstract level) in a following way. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. : 152 WS-BPEL spesifikaatio kuvaa edellä käsitelly prosessin käyttäytymisen (abstraktilla) tasolla kalvon esittämällä tavalla. Spesifikaatiossa sanotaan eksplisiittisesti, että se ei ehdota kyseistä kuvaustapaa käytettäväksi WS-BPEL määritysten kuvaukseen yleisemmin, vaan kyseistä kuvaustapaa käytetään vain havainnollistamaan prosessin kuvaamaa käyttäytymistä. Parempia ja eksaktimpeja kuvaustapoja löytyykin. Esimerkiksi useat työkalut käyttävät omia notaatioitaan. Nykyisin eniten käytettyjä yleisiä mallinnustapoja ovat BPMN ja UML notaatiot. Seuraavaksi tutustummekin BPMN-notaatioon.

35 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 153 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.

36 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. 154 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 ).

37 BPMN elements, Flow objects Flow objects events (circles) Start, Intermediate, or End event Event effect the process flow, and they are usually have an cause (trigger) or impact (result). activities (rounded rectangles) A piece of work performed, either atomic or nonatomic Task Sub-Process» Distinguished by a small plus sign in the bottom center of the rounded rectangle gateways (diamonds) determine traditional decisions, forking, merging, and joining of paths Internal markers will indicate the type of behavior control Start event Intermediate event Prepare Purchase Order + Sub-Process End event 155 BPMN notaatio sisältää vuoelementtejä (vapaasti suom.) vuoelementtejä yhdistäviä objekteja eri aliprosesseille omia osioita ja muita artifakteja Vuoelementit 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.

38 Prosessimalleissa voi esiintyviä seuraavia tapahtumia: Start, Intermediate ja End. Start-tapahtuma nimensä mukaisesti kertoo mistä prosessi alkaa ja End-tapahtuma mihin se päättyy. Start-tapahtuman käyttö ei ole pakollista. Jos kuitenkin prosessilla on End-tapahtuma, täytyy sillä olla myös Starttapahtuma. Intermediate-tapahtuma puolestaan indikoi sitä, että prosessin alun (Start) ja lopun (End) välillä tapahtuu jotain. Intermediate-tapahtuma vaikuttaa prosessiin, mutta se ei aloita tai suoraan lopeta prosessia. Intermediate-tapahtumia voidaan käyttää esimerkiksi Kuvaamaan missä viestejä odotetaan tai lähetetään prosessin aikana, Kuvaamaan missä kohtaa prosessia odotetaan (viive), Keskeyttämään normaali suoritus esimerkiksi virheiden käsittelyä varten tai Kuvaamaan lisätyön tai kompensaation tarvetta. Aktiviteetit puolestaan voivat olla yksittäisiä, atomisia tehtäviä (task) tai ei-atomisia aliprosesseja. Aliprosessit merkitään piirtämällä pieni + -merkki aktiviteettia kuvaavan pyöristetyn suorakaiteen alaosaan keskelle. Aliprosessilla on sisäinen rakenne. Tarkkaan ottaen aktiviteetteja on kolmea eri tyyppiä: prosessi (Process), tehtävä (Task) tai aliprosessi (Sub-Process). Prosessilla itsellään ei kuitenkaan ole omaa graafista symbolia. Prosessi voi luonnollisesti myös haarautua (esim. rinnakkaiset vuot) ja yhdistyä (esim. synkronointi). Nämä merkitään Gateway-solmujen avulla. Niihin palataan myöhemmin.

39 Event types: (from BPMN v1.1 Specification) 156 Edellä esitettyihin kolmeen tapahtumatyyppiin voidaan liittää lisäksi erilaisia laukaisijoita (trigger). Tällainen laukaisija voi olla esimerkiksi viesti, aikarajoite, ehto jne. Esimerkiksi vastaanotettu viesti laukaisee prosessin käynnistymisen. Näillä laukaisijoilla on omat symbolinsa ja ne piirretään tapahtumatyyppiä kuvaavien ympyröiden (Start, Intermediate, End) sisään.

40 Collapsed Sub-Process Markers (from BPMN v1.1 spec.) Task Markers (from BPMN v1.1 spec.) 157 Kuten tapahtumienkin tapauksessa, myös aktiviteeteilla on alityyppejä : ts., tiettyjen symbolien avulla voidaan identifioida millaisesta tehtävästä (Task) tai aliprosessista (Sub-Process) on kyse.

41 BPMN elements, Gateways Gateway types Exclusive gateways A fork in the road for a process, i.e. only one path can be taken when exiting the gateway Data-Based Exclusive Gateways most commonly used type of gateway decisions are made based on boolean expressions attached with the outgoing Sequence Flow may include a marker X inside Event-Based Exclusive Gateways was derived from the BPEL4WS pick. represents a branching point in the process where the alternatives are based on events that occur at that point in the Process, rather than the evaluation of expressions using process data Inclusive Gateway represents a branching point where alternatives are based on conditional expressions contained within outgoing Sequence Flow. all those outgoing Sequence Flows taken, for which the evaluation of the condition expression results True The above picture is from BPMN v.1.1 specification 158 Prosessi voi haarautua kahdella eri tavalla: joko siten, että vaihtoehdoista valitaan yksi (Exclusive), tai siten, että haarautuminen johtaa rinnakkaisesti suoritettaviin osiin (Inclusive). Eksklusiivivista haarautumista verrataan usein teiden risteykseen: saavuttaessa risteykseen, valitaan vaihtoehdoista yksi. Yleisimmin eksklusiivinen haarautuminen esiintyy tapauksissa, joissa päätös tehdään päätöskohdasta lähtevään siirtymään liitetyn boolean-arvoisen lausekkeen arvon perusteella (Data-Based Exclusive Gateway). Tällaisessessa tapauksessa voidaan (mutta ei ole pakko) piirtää iso X päätöskohtaa kuvaavan kärjellään seisovan neliön sisään. X piirretään joskus erottamaan kyseinen päätöskohta muista päätöskohdista ja korostamaan, että kyseessä on eksklusiivinen haarautuminen. Päätös voidaan tehdä myös tapahtumaperustaisesti, siis vastaanotettujen tapahtumien perusteella (Event-Based Exclusive Gateway). Inklusiivisessa haarautumisessa puolestaan voidaan prosessia jatkaa useampaa reittiä pitkin. Tällöin vaihtoehdot perustuvat päätöskohdasta lähteviin siirtymiin liitettyihin ehtolausekkeisiin. Tässä tapauksessa tietyn lausekkeen ehdon evaluoinnin tulos True ei kuitenkaan sulje pois muiden vaihtoehtojen ehtojen evaluointeja, jotka myös voivat antaa arvon True.