How Service Orientation Will Change Your Business. Hoboken, NJ: John Wiley & Sons.

Transkriptio

1 1

2 Kalvon kuvassa on esitetty palvelupohjaisten järjestelmien toteuttamiseen tarvittavat ja käytettävät käsitteet, notaatiot ja näkökulmat. Top-down-tavassa 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 BPELprosesseina. 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. 2

3 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 BPMNmallinnuskielestä 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 UMLmallien XML-pohjaisena 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. [1] Thomas Davenport Process Innovation: Reengineering work through information technology. Harvard Business School Press, Boston [2] Bloomberg, Jason and Ronald Schmelzer Service Orient or Be Doomed!: 3

4 How Service Orientation Will Change Your Business. Hoboken, NJ: John Wiley & Sons. 3

5 Havainnollisia BPMN-tutoriaaleja/-referenssejä: 4

6 5

7 BPMN notaatio sisältää 1) vuoelementtejä (vapaasti suom.) 2) vuoelementtejä yhdistäviä objekteja 3) eri aliprosesseille omia osioita ja 4) 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. 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 Start-tapahtuma. 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. 6

8 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. 6

9 7

10 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. 8

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

12 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. 10

13 Complex Gateway symbolia käytetään, kun halutaan kuvata joko tilanteita, joita on vaikea kuvata muilla Gateway-tyypeillä, tai jos halutaan yhdistää yksinkertaisempia Gateway-rakenteita. Complex Gateway symboliin voidaan yhdistää monimutkaisiakin ehtolausekkeita, joiden evaluoinnin perusteella prosessin haarautuminen tai yhdistyminen tehdään. Parallel Gateway puolestaan tarjoaa tavan synkronoida tai luoda rinnakaiset vuot. Seuraavan kalvon kuvassa on havainnollistettu Parallel Gatway elementin käyttöä synkronoinnin mallintamiseen. 11

14 12

15 Vuoelementtejä 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 ei-täytetty nuolen pää. Assosiaatio puolestaan visualisoidaan pisteellisenä nuolena, jolla on avoin nuolenpää. 13

16 14

17 15

18 BPMN malli voi sisältää kahdentyyppisiä malleja aliprosesseista: 1) Sisäiset liiketoimintaprosessit. Nämä ovat organisaatiospesifejä ja näin ollen organisaation sisäisiä. Näitä kutsutaan yleisesti työnkulku- tai BPM-prosesseiksi 2) 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. 16

19 17

20 BPMN-mallien piirtämiseksi on tarjolla paljon työkalutukea. Kurssin verkkosivuilla on nähtävillä kevään 2008 aikana tehty kartoitus tällä hetkellä saatavilla olevista sekä ilmaisista että kaupallisista BPMN-työakaluista. Kyseinen mallitransformaatio ei kuitenkaan ole yksinkertainen toteuttaa. Yksi perussyistä ongelmiin on se, että BPMNmallit ovat graafipohjaiset, toisin kuin XML-pohjainen kieli WS-BPEL. Tämä tarkoittaa käytännössä myös sitä, että tiettyjen BPMN-mallin osien esittämiseksi BPELkuvauksena voi olla useita eri mahdollisuuksia. Toinen suuri haaste BPMN->BPEL transformaatiolle on se, että kaikille BPMN:n käsitteille ei ole suoraa vastinkäsitettä BPELissä, ja päinvastoin. BPMN->BPEL tai UML->BPEL transformaatiot toteutetaan joskus nk. workflow pattern malleihin pohjautuen. Workflow patternit ovat yleisiä minirakenteita (kuten Sequence, Parallel Split, Synchronization, Exclusive Choice jne. ), jotka esiintyvät useissa eri workflow-kielissä. Näitä malleja on käytetty myös eri workflow-kielten ominaisuuksien ja ilmaisuvoiman vertailuun, kts. esim. Tänä päivänä (2014) näyttäisi olevan yleisempää suorittaa BPMN-malleja suoraan ilman muunnosta BPEL-muotoon. Muun muassa Activi-työkalu tekee näin. Tällöin on toki aina jollain tapaa (kuten BPMN-BPEL-muunnoksessakin) määriteltävä, että minkä Web Service kutsun tai muun toiminnon mikin BPMN-aktiviteetti suorittaa. 18