Orkestration

organisaatiot, jotka ovat jo käyttäneet enterprise application integration (EAI) – väliohjelmatuotteita liiketoimintaprosessien automatisointiin tai erilaisten vanhojen ympäristöjen integrointiin, tuntevat todennäköisesti jo orkestraation käsitteen. Näissä järjestelmissä keskitetysti ohjattu työnkulun logiikka helpottaa kahden tai useamman eri sovelluksen yhteentoimivuutta. Yleinen orkestraation toteutus on hub-and-speak-malli, jonka avulla useat ulkopuoliset osallistujat voivat kytkeytyä keskitettyyn orkestraatiomoottoriin.

yksi näiden ratkaisujen luomisen keskeisistä vaatimuksista oli suurten liiketoimintaprosessien sulauttaminen. Orkestraation avulla voidaan yhdistää eri prosesseja ilman, että joudutaan uudistamaan niitä ratkaisuja, jotka alun perin automatisoivat prosessit yksilöllisesti. Orkestraatio kuroo umpeen tämän aukon ottamalla käyttöön uuden työnkulun logiikan. Lisäksi orkestraation käyttö voi vähentää ratkaisuympäristöjen monimutkaisuutta merkittävästi. Työnkulun logiikka on abstraktia ja helpommin ylläpidettävää kuin yksittäisiin ratkaisukomponentteihin upotettuna.

orkestraation rooli laajenee palvelukeskeisissä ympäristöissä. Käyttämällä laajennuksia, jotka mahdollistavat liiketoimintaprosessilogiikan ilmaisemisen palveluiden kautta, orkestraatio voi edustaa ja ilmaista liiketoimintalogiikkaa standardoidussa, palvelupohjaisessa paikassa. Talotekniikkalähtöisissä ratkaisuissa tämä tarjoaa erittäin houkuttelevan asumisen ja automatisoitavaa prosessia edustavan logiikan hallinnan.

orkestrointi lisää palvelumallien tavoiteltua luontaista yhteentoimivuutta tarjoamalla mahdollisia integroitavia päätepisteitä prosesseihin. Keskeinen seikka orkestraation sijoittumisessa SOA: han on se, että orkestraatiot itse ovat olemassa palveluina. Siksi orkestrointilogiikan pohjalta standardisoidaan prosessiedustus koko organisaatiossa, samalla kun käsitellään yritysliiton tavoitetta ja edistetään palvelulähtöisyyttä.

Kuva 6.32. Orkestrointi hallitsee lähes kaikkia monimutkaisen toiminnan osa-alueita.

ensisijainen toimialan määrittely, joka standardoi orkestroinnin, on Web services Business Process Execution Language (WS-BPEL). Tässä kirjassa ws-BPEL tunnustetaan keskeiseksi toisen sukupolven laajennukseksi ja siksi sen käsitteitä ja terminologiaa käytetään perustana useille keskusteluille, jotka liittyvät liiketoimintaprosessien mallintamiseen.

Huomautus

WS-BPEL on viimeisin tälle spesifikaatiolle annettu nimi, joka tunnetaan myös nimillä BPEL4WS ja just BPEL. Yleiskatsaus ws-BPEL-kielen pääosiin ja keskustelu siitä, miten nimenmuutos syntyi, KS.Luku 16.

selkokielellä

pestyämme onnistuneesti useita autoja yhdessä Chuck, Bob, Jim ja minä päätämme perustaa oman yrityksen. Virallistamme autonpesuprosessimme vaiheet niin, että pystymme käsittelemään erityyppisiä autoja, joilla on erilaiset puhdistusvaatimukset.

prosessiimme vaikuttavat siis seuraavat uudet vaatimukset:

• päätämme palkata lisäapua ruuhka-aikoina. Tämä esittelee jopa kaksi muuta jäsentä, jotka liittyvät tiimiimme.
• koska meillä ei ole riskipääomaa tähän liiketoimintaan, teemme järjestelyn paikallisen huoltoaseman kanssa. Vastineeksi siitä, että käytämme osan heidän tontistaan autonpesutoimintaamme, suostumme auttamaan kaasunpumppaustehtävissä heidän ruuhka-aikanaan.

yksinkertainen autonpesuprosessimme on nyt huomattavasti mutkistunut. Prosessi ei ole enää kiinteä, koska se voi muuttua milloin tahansa erilaisten olosuhteiden ja tapahtumien seurauksena.

• kun ylimääräiset työntekijämme saapuvat, koko tiimin tehtäväjako muuttuu.
• kun huoltoaseman henkilökunta tarvitsee lisäapua, olemme velvollisia lähettämään yhden tai useamman autonpesuryhmämme jäsenen auttamaan heitä.

nämä esimerkit liittyvät ennustettaviin olosuhteisiin, joita esiintyy päivittäin. Toimintaamme vaikuttavat edelleen tietyt rajoitteet:

• jos kassavirtamme laskee alle tietyn summan, meillä ei ole varaa osa-aikaisiin työntekijöihin.
• jos sataa, kaikki työt keskeytetään (mikä myös vähentää kassavirtaa).

nämä rajoitteet tuovat mukanaan ehtoja, jotka ovat harvinaisempia, mutta jotka meidän on aina otettava huomioon. Näitä mahdollisia tilanteita varten laadimme suunnitelman, joka kartoittaa laajennetun prosessimme ja tarjoaa vaihtoehtoisia prosesseja sekä yleisten että epätavallisten olosuhteiden käsittelemiseksi.

tämä suunnitelma on pohjimmiltaan työnkulku, joka yhdistää yksittäiset vaiheet päätöksentekokohtien erottamiin prosesseihin ja alaprosesseihin. Tämä monimutkainen työnkulku sisältää alkuperäisen prosessin huoltoaseman prosessin ja laajennetun prosessin, joka johtuu osa-aikaisten työntekijöidemme saapumisesta. Tämä työnkulku on olennaisesti orkestraatio, joka hallinnoi yksittäisten prosessien vaatimuksia ja niihin liittyviä resursseja, osallistujia, tapahtumia, liiketoiminnan sääntöjä ja toimintoja.

6.6.1. Liiketoimintaprotokollat ja prosessin määrittely

orkestraation käsittävä työnkulun logiikka voi koostua lukuisista liiketoiminnan säännöistä, ehdoista ja tapahtumista. Yhdessä nämä orkestraation osat muodostavat liiketoimintaprotokollan, joka määrittelee, miten osallistujat voivat toimia yhdessä saavuttaakseen liiketoiminnallisen tehtävän. Työnkulun logiikan yksityiskohdat, jotka on kapseloitu ja ilmaistu orkestraatiolla, sisältyvät prosessin määritelmään.

6.6.2. Prosessipalvelut ja kumppanipalvelut

Prosessimääritelmässä yksilöidyt ja kuvatut ovat sallittuja prosessin osallistujia. Ensinnäkin itse prosessi esitetään palveluna, mikä johtaa prosessipalveluun (joka sattuu olemaan toinen palvelumalleistamme, kuten kuvassa 6.33 esitetään).

Kuva 6.33. Prosessipalvelun koordinointi ja toimintojen paljastaminen kolmesta kumppanipalvelusta.

muut palvelut, joilla on lupa olla vuorovaikutuksessa prosessipalvelun kanssa, tunnistetaan kumppanipalveluiksi tai kumppanilinkkeiksi. Työnkulun logiikasta riippuen prosessipalveluun voi vedota ulkopuolinen kumppanipalvelu tai se voi vedota muihin kumppanipalveluihin (Kuva 6.34).

kuva 6.34. Prosessipalvelu vetoaa ensin kumppanipalveluun ja sitten toiseen kumppanipalveluun.

6.6.3. Perustoiminnot ja strukturoitu toiminta

WS-BPEL jakaa työnkulun logiikan sarjaksi ennalta määriteltyjä alkeellisia toimintoja. Perustoiminnot (vastaanottaa, vedota, vastata, heittää, odottaa) edustavat perustavanlaatuisia työnkulkutoimintoja, jotka voidaan koota käyttäen logiikkaa, jota jäsennellyt toiminnot (sekvenssi, kytkin, kun taas, virtaus, pick). Miten näitä toimintoja voidaan käyttää ilmaisemaan todellista liiketoimintaprosessien logiikkaa tutkitaan luvussa 16.

6.6.4. Sekvenssit, virrat ja linkit

perus-ja strukturoidut toiminnot voidaan järjestää siten, että niiden suoritusjärjestys on ennalta määritelty. Sekvenssi kohdistaa toisiinsa liittyvien toimintojen ryhmät luetteloon, joka määrittää peräkkäisen suoritusjärjestyksen. Sekvenssit ovat erityisen hyödyllisiä silloin, kun yksi sovelluslogiikan osa on riippuvainen toisen lopputuloksesta.

Virrat sisältävät myös toisiinsa liittyvien toimintojen ryhmiä, mutta niissä asetetaan erilaisia toteutusvaatimuksia. Kappaletta sovelluksen logiikka voi suorittaa samanaikaisesti sisällä virtaus, mikä tarkoittaa, että ei ole välttämättä vaatimus yhden joukon toimintoja odottaa ennen kuin toinen päättyy. Itse virtaus ei kuitenkaan lopu ennen kuin kaikki kapseloidut toiminnot ovat suorittaneet käsittelyn. Tämä takaa eräänlaisen synkronoinnin yksittäisten virtojen sovelluslogiikan välillä.

linkkejä käytetään virallisten riippuvuuksien muodostamiseen virtoihin kuuluvien toimintojen välillä. Ennen kuin toiminta voi täysin päättyä, sen on varmistettava, että lähtevien linkkien mahdolliset vaatimukset täyttyvät. Samoin, ennen kuin linkitetty toiminta voi alkaa, vaatimukset sisältyvät tahansa saapuvien linkkien ensin on täytettävä. Linkkien tarjoamia sääntöjä kutsutaan myös synkronointiriippuvuuksiksi.

6.6.5. Orkestraatiot ja toiminta

kuten aiemmin määrittelimme, toiminta on yleisnimitys, jota voidaan soveltaa mihin tahansa loogiseen työyksikköön, joka on toteutettu palvelukeskeisellä ratkaisulla. Yksittäisen orkestraation laajuus voidaan siis luokitella monimutkaiseksi ja mitä todennäköisimmin pitkäjänteiseksi toiminnaksi.

6.6.6. Orkestraatio ja koordinointi

orkestraatio, jota edustaa WS-BPEL, voi täysin hyödyntää WS-Coordination context management framework sisällyttämällä ws-Business Activity coordination type. Tässä eritelmässä määritellään koordinointiprotokollat, jotka on suunniteltu tukemaan monimutkaisia, pitkäkestoisia toimintoja.

6.6.7. Orkestraatio ja soa

Liiketoimintaprosessilogiikka on automaatioratkaisujen ytimessä. Orkestraatio tarjoaa automaatiomallin, jossa prosessilogiikka on keskitettyä mutta silti laajennettavissa ja kompositioitavissa (Kuva 6.35). Orkestraatioiden avulla palvelukeskeisistä ratkaisuympäristöistä tulee luonnostaan laajennettavia ja mukautuvia. Orkestraatiot itse luovat tyypillisesti yhteisen integrointipisteen muille sovelluksille, mikä tekee toteutetusta orkestraatiosta keskeisen integraation mahdollistajan.

Kuva 6.35. SOA: n muihin osiin liittyvä orkestrointi.

nämä ominaisuudet lisäävät organisaation ketteryyttä, koska:

• orkestraation kapseloimaa työnkulun logiikkaa voidaan muokata tai laajentaa keskeisessä paikassa.
• orkestraation sijoittaminen keskitetysti voi merkittävästi helpottaa liiketoimintaprosessien sulautumista tiivistämällä liima, joka sitoo vastaavat automaatioratkaisut yhteen.
• perustamalla mahdollisesti laajamittaisia palvelukeskeisiä integraatioarkkitehtuureja orkestraatio voi perustasolla tukea moninaisen federatiivisen yrityksen kehitystä.

orkestraatio on keskeinen osatekijä liittovaltion saavuttamisessa organisaatiossa, joka sisältää erilaisia sovelluksia, jotka perustuvat erilaisiin laskentaympäristöihin. Edistysaskeleet väliohjelmistossa mahdollistavat orkestraatiomoottoreiden integroitumisen täysin palvelukeskeisiin ympäristöihin.

palvelukeskeisen orkestroinnin käsite hyödyntää täysin kaikkia tässä luvussa tähän mennessä käsiteltyjä käsitteitä. Monissa ympäristöissä orkestroinneista tulee SOA: n sydän.

tapaustutkimus

edellisessä tapaustutkimusesimerkissä yritystoimintaan kietoutuneet vaiheet osoittivat, miten TLS käytti ws-Business-protokollaa lisätäkseen kontekstinhallinnan ja poikkeusten käsittelyn pitkään jatkuneeseen, monimutkaiseen toimintaan. Vaikka liiketoiminnan laajuus voi muodostaa liiketoimintaprosessin, se ei tarjoa TLS: lle vakiomuotoista tapaa ilmaista taustalla olevaa työnkulun logiikkaa. Tätä varten TLS käyttää WS-BPEL-orkestraatiota (Kuva 6.36).

Kuva 6.36. Laajennettu TLS-ostotilausten Jättöprosessi, jota hallinnoi orkestraatio ja johon osallistuu lukuisia mahdollisia kumppaniorganisaatioita.

orkestraatio luo kattavan prosessilogiikan, joka kattaa liiketoiminnan ja laajentaa sitä entisestään ohjaamaan muita vuorovaikutusskenaarioita useiden myyjäpalvelujen kanssa. Esimerkiksi, kun yksi myyjä ei pysty täyttämään tilausta, seuraavalle jonossa olevalle myyjälle lähetetään sama ostotilaus. Tämä sykli toistetaan, kunnes jompikumpi myyjä voi suorittaa tilauksen kokonaisuudessaan (tiettyjen hintarajoitusten puitteissa) tai kunnes kaikki myyjät on tiedusteltu. Jälkimmäisessä tilanteessa järjestelmä yksinkertaisesti arvioi parhaan tarjouksen pöydällä soveltamalla kaavaa, joka ottaa huomioon hinnan, täyttyvän tilauksen prosenttiosuuden ja jälkitilausehdot.

orkestrointilogiikka hallitsee kaikkia prosessin osa-alueita, mukaan lukien useiden myyjäkumppanipalvelujen mukanaolo sekä liiketoiminta, joka käynnistyy, kun tuottajaorganisaatiota käsitellään.

tiivistelmä keskeisistä kohdista

• orkestraatio ilmaisee liiketoimintaprosessilogiikan kokonaisuutta, joka on tyypillisesti yhden organisaation omistuksessa.
• orkestraatio muodostaa liiketoimintaprotokollan, joka määrittelee muodollisesti liiketoimintaprosessin määritelmän.
• orkestraation työnkulkulogiikka jakautuu sarjaan perus-ja jäsenneltyjä toimintoja, jotka voidaan järjestää jaksoiksi ja virtauksiksi.
• orkestraatiota on kutsuttu ”SOA: n sydämeksi”, koska se luo keinon keskittää ja hallita paljon inter-ja intra-application logiikkaa standardoidun palvelumallin avulla.