Ohjelmointi

BPEL: SOA: n palvelukoostumus

BPEL: stä (Business Process Execution Language) on tullut yksi SOA: n (palvelukeskeinen arkkitehtuuri) tärkeimmistä tekniikoista, ja se mahdollistaa palvelujen helpon ja joustavan yhdistämisen liiketoimintaprosesseihin. BPEL on erityisen tärkeä, koska se tuo sovelluskehitykseen uuden käsitteen - ohjelmointi suuressa. Tämän konseptin avulla voimme kehittää prosesseja nopeasti määrittelemällä järjestyksen, jossa palveluihin käytetään. Tällä tavalla sovelluksista (ja tietojärjestelmistä) tulee joustavampia ja ne voivat paremmin sopeutua liiketoimintaprosessien muutoksiin.

Liiketoimintaprosessit ovat yleensä luonteeltaan dynaamisia. Yritysten on parannettava ja muunneltava, toimittava ketterästi, optimoitava ja mukautettava prosesseja koko yrityksen reagointikyvyn parantamiseksi. Jokaisen muutoksen ja parannuksen liiketoimintaprosessissa on otettava huomioon sovelluksissa, jotka tarjoavat heille tukea. Vaikka tämä vaatimus ei ehkä kuulosta kovin vaikealta, todellinen tilanne osoittaa meille toisen kuvan. Sovellusten muuttaminen ja muokkaaminen on usein vaikea työ, joka vaatii aikaa. Siksi sovellukset eivät voi reagoida välittömästi liiketoimintaprosessien muutoksiin, vaan ne tarvitsevat jonkin aikaa muutosten toteuttamiseen, testaamiseen ja käyttöönottoon.

Tietojärjestelmien tekeminen joustavammiksi ja muutoksiin sopeutuvammiksi sekä paremmin liiketoimintaprosessien mukaisiksi on SOA: n tärkein lupaus. Tässä artikkelissa näytän, miksi BPEL on niin tärkeä, ja osoitan, kuinka kehittää BPEL-prosessi.

Palvelukeskeinen lähestymistapa

SOA-lähestymistapa liiketoimintaprosessien tehokkaaseen automatisointiin edellyttää:

  • Vakioitu tapa paljastaa ja käyttää sovellusten toimintoja palveluina
  • Yritysväyläinfrastruktuuri viestintään ja palvelujen hallintaan, mukaan lukien viestien sieppaus, reititys, muunnos jne.
  • Erikoiskieli sovellusten altistuvien toimintojen koostumiseen liiketoimintaprosesseihin

Ensimmäisen vaatimuksen täyttää uusin hajautettu arkkitehtuuri - verkkopalvelut. Toisen vaatimuksen täyttää ESB (Enterprise Service Bus), joka tukee keskitettyä, selittävää ja hyvin koordinoitua palvelujen ja niiden viestinnän hallintaa. Kolmannen vaatimuksen, palvelujen kokoonpanon prosesseiksi, täyttää BPEL, yleisesti hyväksytty erikoistunut kieli liiketoimintaprosessien määrittelyyn ja toteuttamiseen.

BPEL: n mukaan liiketoimintaprosessi on kokoelma koordinoituja palveluhakemuksia ja niihin liittyviä toimintoja, jotka tuottavat tuloksen joko yhdessä organisaatiossa tai useissa organisaatioissa. Esimerkiksi liikematkojen suunnitteluun liittyvä liiketoimintaprosessi käyttää useita palveluja. Yli yksinkertaistetussa tilanteessa liiketoimintaprosessi vaatii meitä määrittämään työntekijän nimen, määränpään, päivämäärät ja muut matkatiedot. Sitten prosessi kutsuu verkkopalvelua työntekijän tilan tarkistamiseksi. Työntekijän aseman perusteella se valitsee sopivan matkaluokan. Sitten se vetoaa useiden lentoyhtiöiden (kuten American Airlines, Delta Airlines jne.) Verkkopalveluihin tarkistaakseen lentolipun hinnan ja ostamalla halvimman hinnan.

Asiakkaille BPEL-prosessi paljastaa toimintansa samalla tavalla kuin mikä tahansa muu verkkopalvelu. Asiakkaan näkökulmasta se näyttää täsmälleen samalta kuin mikä tahansa muu verkkopalvelu. Tämä on tärkeää ja hyödyllistä, koska sen avulla voimme koota palvelut yksinkertaisiksi prosesseiksi, yksinkertaiset prosessit monimutkaisemmiksi prosesseiksi ja niin edelleen. Tämä tarkoittaa myös sitä, että jokainen BPEL-prosessi kuvataan WSDL (Web Services Description Language) -kuvauksella.

Peruskäsitteet

BPEL on XML-pohjainen kieli. BPEL-prosessi koostuu vaiheista. Jokaista vaihetta kutsutaan toiminnaksi. BPEL tukee primitiivisiä ja rakennetoimintoja. Primitiiviset toiminnot edustavat perusrakenteita ja niitä käytetään yhteisiin tehtäviin, kuten alla lueteltuihin:

  • Web-palveluiden kutsuminen, käyttö
  • Odotetaan pyyntöä
  • Tietomuuttujien manipulointi käyttäen
  • Osoittaa viat ja poikkeukset käyttäen , jne.

Voimme sitten yhdistää nämä toiminnot monimutkaisemmiksi algoritmeiksi, jotka määrittelevät liiketoimintaprosessin vaiheet. Primitiivisten toimintojen yhdistämiseksi BPEL tukee useita rakennetoimintoja. Tärkeimmät ovat:

  • Järjestys () määritellä joukko aktiviteetteja, joita käytetään järjestetyssä järjestyksessä
  • Virtaus () määrittelemään toimintoja, joihin vedotaan samanaikaisesti
  • Tapauskytkinrakenne () sivuliikkeiden toteuttamiseksi
  • Sillä aikaa () silmukoiden jne. määrittelemiseksi

Kuten näemme, BPEL ei ole niin erilainen kuin ohjelmointikielet, kuten Java. Mutta näemme, että BPEL eroaa Javasta ja tukee liiketoimintaprosessien ominaisuuksia. BPEL tarjoaa myös vika- ja korvauskäsittelijöitä, tapahtumankäsittelijöitä ja korrelaatiojoukkoja. Se tarjoaa keinot ilmaista monimutkaisia ​​rinnakkaisia ​​virtauksia. Sen avulla asynkronisiin operaatioihin soittaminen ja soittojen odottaminen on myös suhteellisen helppoa.

BPEL-prosessit vaativat ajonaikaisen ympäristön - BPEL-palvelimen, joka antaa meille hyvän hallinnan niiden suorituksessa. Tyypillisesti BPEL-palvelimet hallitsevat suoritettavia ja valmiita prosessin ilmentymiä. Ne tukevat pitkään jatkuneita prosesseja ja voivat dehydratoida prosessitilan resurssien säästämiseksi. Jotkut palvelimet hallitsevat prosessitoimintoja ja sallivat niiden valvonnan. Lopuksi BPEL-palvelinta käyttämällä kaikki prosessimme otetaan käyttöön keskitetysti, mikä yksinkertaistaa ylläpitoa. Kaikki tämä tekee BPEL-palvelimesta ensisijaisen ympäristön prosessien suorittamiseen ja hallintaan.

Oikean BPEL-palvelimen valitseminen voi kuitenkin olla melko vaikeaa, koska valintoja on useita. Jotkut suosituimmista Java EE: hen (Sunin uusi nimi J2EE) perustuvista BPEL-palvelimista ovat Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration ja AquaLogic. Saatavilla on myös vähintään neljä avoimen lähdekoodin BPEL-palvelinta: ActiveBPEL Engine, FiveSight PXE, bexee ja Apache Agila.

Esimerkki prosessista

Tarkastellaan nyt edellä kuvattua esimerkkiä BPEL-prosessista liikematkoille. Kehitämme asynkronisen prosessin, joka käyttää synkronoitua puhelua työntekijän matkatilan tarkistamiseen ja kahta asynkronista puhelua lentolippujen hintojen selvittämiseen. Alla olevassa kuvassa näkyy prosessin kokonaisrakenne. Vasemmalla näet prosessin kutsuvan asiakkaan. Prosessi kutsuu ensin työntekijän matkatilan verkkopalvelua. Sitten se käyttää molempien lentoyhtiöiden verkkopalveluja samanaikaisesti ja asynkronisesti. Tämä tarkoittaa, että prosessin on toteutettava soittopyyntö (ja porttityyppi), jonka kautta lentoyhtiöt palauttavat lentolipuvahvistuksen. Lopuksi prosessi palauttaa asiakkaalle parhaan lentolipputarjouksen. Tässä esimerkissä yksinkertaisuuden säilyttämiseksi emme toteuta vikakäsittelyä, mikä on ratkaisevan tärkeää todellisissa tilanteissa.

Kirjoita nyt BPEL-koodi. Aloitamme prosessideklaraatiosta - juurielementistä, jossa määritämme prosessin nimen ja nimitilat:

Seuraavaksi meidän on määriteltävä kumppanilinkit. Kumppanilinkit määrittelevät eri osapuolet, jotka ovat vuorovaikutuksessa BPEL-prosessin kanssa. Tämä sisältää kaikki Web-palvelut, joihin vedotaan, ja prosessin asiakas. Jokainen kumppanilinkki määrittää enintään kaksi määritettä: minun roolini mikä osoittaa itse liiketoimintaprosessin roolin ja partnerRole mikä osoittaa kumppanin roolin. Esimerkissämme määritämme neljä kumppanilinkkiä:

Tarvitsemme muuttujia, jotta voimme tallentaa viestejä ja muotoilla ne uudelleen. Yleensä käytämme muuttujaa jokaiselle verkkopalveluille lähetetylle ja niistä vastaanotetulle viestille. Esimerkissämme tarvitsemme muutamia muuttujia. Jokaiselle muuttujalle on määritettävä tyyppi. Voimme käyttää WSDL-sanomatyyppiä, yksinkertaista XML-skeema-tyyppiä tai XML-skeema-elementtiä. Esimerkissämme käytämme WSDL-sanomatyyppejä kaikille muuttujille:

Nyt olemme valmiita kirjoittamaan pääprosessirungon. Se sisältää vain yhden ylätason toiminnan. Yleensä tämä on jonka avulla voimme määritellä useita toimintoja, jotka suoritetaan peräkkäin. Järjestyksessä määritetään ensin tulosviesti, joka aloittaa liiketoimintaprosessin. Teemme tämän konstrukti, joka odottaa vastaavaa viestiä. Meidän tapauksessamme tämä on TravelRequest viesti. Sisällä rakentaa, emme määritä viestiä suoraan. Sen sijaan määritämme kumppanilinkin, porttityypin, operaation nimen ja valinnaisesti muuttujan, joka pitää vastaanotetun sanoman seuraavalle toiminnalle. Yhdistämme viestin vastaanoton asiakaskumppaniin ja odotamme TravelApproval toiminto, johon porttityyppiä vedotaan TravelApprovalPT. Tallennamme vastaanotetun viestin TravelRequest muuttuja:

Seuraavaksi meidän on käytettävä Employee Travel Status -verkkopalvelua. Ennen tätä meidän on valmisteltava tulo tälle verkkopalvelulle. Voimme luoda tällaisen viestin kopioimalla asiakkaan lähettämän viestin työntekijän osan. Nyt voimme käyttää Employee Travel Status Web -palvelua. Teemme synkronisen kutsun, johon käytämme toiminta. Käytämme workerTravelStatus kumppanilinkki ja vedota EmployeeTravelStatus käyttö EmployeeTravelStatusPT porttityyppi. Olemme valmistelleet syötesanoman EmployeeTravelStatusRequest muuttuja. Koska kyseessä on synkroninen kutsu, puhelu odottaa vastausta ja tallentaa sen EmployeeTravelStatusResponse muuttuja:

Seuraava vaihe on vedota molempien lentoyhtiöiden verkkopalveluihin. Jälleen valmistellaan ensin vaadittu syöttösanoma (joka on yhtä suuri molemmille verkkopalveluille). Teemme samanaikaisia ​​asynkronisia kutsuja. Samanaikaisuuden ilmaisemiseksi BPEL tarjoaa toiminta. Kutsu jokaiseen verkkopalveluun koostuu kahdesta vaiheesta:

  1. toimintaa käytetään asynkroniseen kutsumiseen
  2. toimintoa käytetään odottamaan soittopyyntöä

Käytämme ryhmitellä molemmat toiminnot. Nämä kaksi kutsua eroavat vain kumppanilinkin nimestä. Käytämme Amerikkalaiset lentoyhtiöt yhdelle ja DeltaAirlines toiselle:

...