STORITVENA ARHITEKTURA ZGOLJ KOMPOZICIJA SPLETNIH STORITEV? Matjaž B. Jurič Fakulteta za elektrotehniko, računalništvo in informatiko Center odličnosti za sodobne informacijske tehnologije in storitve e-pošta: matjaz.juric@uni-mb.si, URL: http://lisa.uni-mb.si/~juric/ Povzetek V prispevku bomo poskušali odgovoriti na vprašanje, kaj storitvena arhitektura je, kako se razlikuje od obstoječih arhitektur informacijskih sistemov, katere koncepte uporablja in osvetlili pomen storitvenih vodil (ESB Enterprise Service Bus). Proučili bomo dva pristopa k razvoju SOA: pristop od spodaj navzgor, ki temelji na spletnih storitvah in pristop od zgoraj navzdol, ki temelji na definiciji poslovnih procesov na osnovi kompozicije storitev z uporabo WS-BPEL (Business Process Execution Language) in koreografije procesov z uporabo WS-CDL (Choreography Description Language). 1. UVOD Razvoj informacijske infrastrukture, ki bo organizacijam nudila celovito podporo poslovnim procesom, je že sam zase zapleten in dolgotrajen postopek. Če k temu dodamo še dejstvo, da so današnji poslovni procesi v večini organizacij agilni, da se hitro spreminjajo in da se organizacije trudijo poslovne procese prilagoditi strankam ter jih optimizirati in s tem izboljšati odzivnost same organizacije, tedaj postane težavnost razvoja ustrezne informacijske podpore še večja. Izvirni greh se skriva v dejstvu, da IT strokovnjaki potrebujemo določen čas, da informacijski sistem prilagodimo spremembam novim potrebam, ki so se pojavile v poslovnih procesih. Ta tako imenovani»it gap«je z vidika agilnosti same organizacije smiselno skrčiti, kolikor se le da. Le organizacije, v katerih je informacijska podpora zasnovana tako, da se lahko hitro in učinkovito prilagaja poslovnim spremembam, lahko delujejo konkurenčno v globalni ekonomiji. Storitvene arhitekture (SOA Service Oriented Architecture) so zadnji, najnovejši arhitekturni pristop, ki obljublja rešitve znanih težav, s katerimi se soočamo informatiki pri razvoju in vzdrževanju kompleksnih informacijskih sistemov. V prispevku se bomo posvetili dvem pristopom k realizaciji SOA: pristopu od spodaj navzgor in pristopu od zgoraj navzdol. Za slednjega bomo ugotovili, da predstavlja procesni pristop k realizaciji SOA in s tem učinkovit način za kompozicijo storitev v smislu podpore poslovnih procesov.
2. STORITVENE ARHITEKTURE Poslovni informacijski sistemi so bili v preteklosti največkrat načrtovani funkcionalno. Takšni sistemi, včasih imenovani tudi silosi, vsebujejo velike količine podatkov in množico funkcionalnosti. Njihov osnovni problem je v tem, da naslavljajo podporo določeni funkciji oz. aktivnosti, ne pa celotnemu poslovnemu procesu. Celoviti poslovni procesi morajo torej delovati nad več takšnimi aplikacijami silosi. S tehničnega vidika to pomeni integracijski problem, kjer je potrebno ustrezno povezati različne aplikacije, izdelane v različnih tehnologijah in poskrbeti za ustrezno zaporedje izvajanja. Pri tem ne gre pozabiti, da je tudi funkcionalnost takega poslovnega procesa razpršena med več obstoječih sistemov z drugimi besedami, funkcionalnost je fragmentirana in tesno sklopljena. Izhajajoč iz tega spoznanja je očitno, da je že razvoj poslovnih procesov, ki morajo povezati množico obstoječih sistemov, zamuden in kompleksen. Enako velja za dopolnjevanje in spreminjanje. Več kot očitno je, da na tak način informatiki ne moremo zadostiti potrebam po fleksibilnih in hitro spreminjajočih se poslovnih procesih. Storitvene arhitekture ponujajo odgovor na ta problem in ponujajo načine razvoja in integracije poslovnih aplikacij na osnovi modularnih, šibko sklopljenih storitev. Ključni poudarek storitvenih arhitektur je torej na definiciji načina integracije avtonomnih obstoječih ali novo razvitih aplikacij imenovanih storitev - v celovit sistem s posebnim poudarkom na modelu komunikacije, podpori različnih transportnih mehanizmov, zagotavljanju varnosti in transakcijske identitete, zanesljivosti sporočanja ter koordinaciji in kompoziciji. S tehnološkega vidika storitvene arhitekture niso nič posebnega. So le posebna vrsta porazdeljenih sistemov, pri katerih so komponente sistema storitve. Svojo pravo vrednost pa storitvene arhitekture razkrijejo, ko pogledamo na njih s vsebinskega vidika, kot bomo videli v nadaljevanju. 3. STORITVE Storitev opravlja neko natančno določeno operacijo, ki jo lahko uporabimo tudi izven konteksta aplikacije, v kateri je ponujena z drugimi besedami, storitev je avtonomna. Pomembno je, da ima storitev natančno definiran vmesnik, do katerega lahko dostopimo preko omrežja z uporabo standardnih protokolov in podatkovnih tipov. Vmesnik storitve je pravzaprav le natančen opis sporočil, ki si jih lahko izmenjamo [2]. To pogojuje uporabo povezav brez stanja. Storitve v SOA naj bi imele naslednje lastnosti: Storitve so avtonomne Meje storitev so eksplicitne Storitve se delijo na atomarne in sestavljene (kompozitne) storitve Storitve izpostavljajo operacije, ki izmenjujejo sporočila Nabor operacij je pogodba med storitvami in določa zaporedje sporočil Sporočila so definirana s shemami, ki določajo tipe sporočil Storitve med seboj izmenjujejo samo sporočila (podatke), ne pa tudi obnašanja (razredov oz. metod)
Pri komunikaciji med storitvami je potrebno zagotoviti podporo sinhroni in asinhroni, enosmerni in dvosmerni komunikaciji, varnosti, zanesljivosti, korelaciji in transakcijski semantiki. Sporočila, ki jih izmenjujejo storitve, morajo biti tipizirana. Storitve morajo razumeti vsebino posameznih sporočil in jih obdelovati po načelih šibke sklopljenosti. Med sporočili lahko obstaja korelacija, to je odvisnost med sporočili, ki lahko temelji na identifikatorjih, ki so del vsebine, ali na umetno generiranih identifikatorjih. Korelacijo lahko torej opravimo na osnovi vsebine ali identifikacije. Izmenjava sporočil lahko poteka dolgo časa. Storitve morajo biti sposobne obdelave takih sporočil. Vmesnik je pogodba med storitvijo in njenim odjemalcem in je neodvisen od uporabljene implementacijske tehnologije. Vmesnik vsebuje operacije. Storitve lahko uporabimo statično (vezava se opravi v času prevajanja) ali dinamično (vezava med odjemalcem in storitvijo se opravi v času izvajanja). Storitve same vzdržujejo svoje stanje, če ga potrebujejo. Operacije definirajo zaporedje sporočil. Ta zaporedja so lahko [3]: Zahteva/odgovor Enosmerna Obvestilo Spodbujen odgovor Operacije so lahko sinhrone ali asinhrone. Vrstni red proženja operacij je lahko pomemben. Ker komunikacijska infrastruktura, predvsem protokol HTTP, vedno ne zagotavlja vrstnega reda, je pri načrtovanju operacij smiselno upoštevati idempotenco operacij. Idempotentne operacije so tiste, ki ne spreminjajo stanja storitve. Zato ni pomembno, koliko krat in v kakem zaporedju jih kličemo. Nekatere operacije so naravno idempotentne, na primer čiščenje ekrana ali branje datoteke. Druge so po naravi ne-idempotentne, na primer: dvig 1000 SIT iz računa. Velja pa pravilo, da lahko po naravi ne-idempotentne operacije preoblikujemo v idempotentne, na primer: če dvig ID4667 še ni bil narejen opravi dvig 1000 SIT iz računa in ga označi kot ID4667. Storitvene arhitekture nadalje temeljijo na naslednjih konceptih: Različnih tipih storitev: podatkovnih, komponentnih, konverzacijskih, sporočilnih Posrednikih storitev oz. tako imenovanem storitvenem vodilu (ESB Enterprise Service Bus) Zmožnosti deklarativne kompozicije storitev z uporabo orkestracije ali koreografije Obravnavi izjem in kompenzaciji delnih učinkov procesov Prestrezanju zahtev in razširljivosti Povezljivosti Pri tem pa je smiselno opozoriti, da je koncepte SOA potrebno aplicirati premišljeno, saj razvoj storitvenih arhitektur skriva tudi precej pasti [4, 5]. Najpogostejše med njimi so: Storitve, ki uporabljajo preveč fino granulacijo vmesnikov Uporaba tehnologij za oddaljen dostop do storitev, ki so nameščene lokalno
Pretirana uporaba jezika XML in neustrezna struktura sporočil Uporaba šibke sklopljenosti tam, kjer je potrebna tesna sklopljenost Realizacija storitvene arhitekture je povezana z uporabo ustreznih tehnologij. Spletne storitve so v tem trenutku najprimernejša tehnologija za realizacijo storitvenih arhitektur. Za realizacijo opisanih konceptov pa uporaba zgolj treh osnovnih tehnologij, SOAP, WSDL in UDDI, ne zadošča in potrebno je uporabiti sklad tehnologij, ki smo ga opisali v lanskem prispevku [6]. 4. KOMPOZICIJA STORITEV Izpostavljanje funkcionalnosti v obliki ustrezno načrtovanih storitev je eden od dveh pomembnih vidikov realizacije SOA in ga imenujemo tudi pristop od spodaj navzgor. Predstavlja pogoj, da lahko nadaljujemo z drugim korakom kompozicijo storitev ali procesnim vidikom realizacije SOA, ki ga imenujemo tudi pristop od zgoraj navzdol. Cilj SOA, integrirati funkcionalnosti storitve v nove kontekste izvajanja v poslovne procese, uresničimo šele z drugim korakom, torej s kompozicijo storitev. V okviru slednje realiziramo enoten nivo (procesni nivo), na katerem definiramo poslovne procese. Na tem nivoju dosežemo ključne prednosti SOA, to so: Izboljšana odzivnost na poslovne spremembe Vpogled»v realnem času«v poslovne procese Enostavnost definicije in sprememb poslovnih procesov Omenjene prednosti dosežemo seveda le, če uspemo SOA tudi učinkovito implementirati. Le tedaj v popolnosti izkoristimo možnost modularizacije obstoječih aplikacij in izpostavljanja njihovih funkcionalnosti v obliki storitev ter kompozicije storitev v prilagodljive procese. Procesni vidik realizacije SOA predstavlja torej neke vrste lepilo med storitvami na eni in poslovnimi procesi na drugi strani. Procesni vidik namreč upošteva poslovne procese kot ključni sestavni del, podobno kot objektni jeziki upoštevajo objekte. Poslovne procese in pripadajoče sodelovanje, izmenjavo informacij in aktivnosti izrazimo z uporabo ustreznih tehnologij, predvsem ESB (Enterprise Service Bus), WS-BPEL (Business Process Execution Language) in prihajajočega WS-CDL (Choreography Description Language). 4.1. ESB storitveno vodilo Preden lahko začnemo govoriti o»lepljenju«storitev v procese, moramo odgovoriti na vprašanje, kako lahko dostopamo do storitev. Enostaven odgovor je z uporabo tehnologije spletnih storitev. Vendar ta enostavni odgovor v kompleksnih poslovnih okoljih ne zadošča. Tam je poleg komunikacije potrebno odgovoriti še vsaj na dve vprašanji: Kako upravljati varnost, zanesljivost, korelacije, transakcije in koordinacijo spletnih storitev na enoten način? Kaj narediti z obstoječo vmesno programsko opremo (middleware) in kako zagotoviti povezljivost s spletnimi storitvami? Na ti dve vprašanji odgovarja storitveno vodilo ESB (Enterprise Service Bus). ESB je infrastruktura na osnovi katere gradimo SOA in deluje kot vmesni sloj, preko katere naredimo
dostopno množico storitev. ESB zagotavlja povezljivost in nadzor ter upravljanje nad storitvami. Bolj natančno je ESB centralizirano, skalabilno, zanesljivo storitveno ogrodje, ki: Ponuja transparentnost komunikacije med storitvami z uporabo različnih protokolov Ponuja dodano vrednost v obliki podpore varnosti, transakcij, dostave sporočil, usmerjanja, transformacije, in podobnih storitev. 4.2. BPEL avtomatizacija poslovnih procesov BPEL je namenjen avtomatizaciji poslovnih procesov [1]. Ponuja osnovo za orkestracijo poslovnih procesov znotraj in med organizacijami z kombinacijo obstoječih in novo razvitih aplikacij, izpostavljenih v obliki storitev, komercialnih aplikacij in komercialnih storitev. Bolj natančno, z uporabo BPEL sestavimo orkestriramo storitve v poslovne procese. BPEL je namenjen definiciji procesnega toka in koordinaciji. Poslovni proces, definiran z uporabo BPEL, določa procesno logiko vpletenih storitev in načine sodelovanja. Procese, definirane v BPEL, lahko direktno izvajamo in v ta namen potrebujemo ustrezno izvajalno okolje orkestracijski strežnik. Izbiramo lahko vsaj med: Oracle BPEL Process Manager Microsoft BizTalk 2004 IBM WebSphere Business Integration Server Foundation IBM alphaworks BPWS4J OpenStorm Service Orchestrator Vergil VCAB Server Active Endpoints ActiveWebflow Server ActiveBPEL Engine Fivesight Process execution Engine BPEL procesi pa poleg procesnega toka in koordinacije definirajo še semantiko, kar vključuje zaporedje izvajanja (tudi paralelno), obravnavo napak, transformacije podatkov, kompenzacijsko logiko, korelacijo, ipd. 4.3. CDL sodelovanje med poslovnimi procesi Pri kompleksnih scenarijih integracije pa se poleg potrebe po definiciji poslovnih procesov pojavi tudi potreba po opisu sodelovanja med poslovnimi procesi. Tako sodelovanje vključuje opis poslovnih transakcij, mej zaupanja, semantike operacij in informacije, ki sodelujejo pri izmenjavi. Temu služi CDL, ki omogoča formalno modeliranje skupnega opazovanega obnašanja vseh vpletenih strani. CDL omogoča opis izmenjave sporočil med sodelovanjem, splošnih pravil za deklarativno določanje napredka procesov, skupna pravila odločanja o rezultatih procesov in rekurzivni kompozicijski model, ki omogoča izgradnjo koreografij inkrementalno na osnovi obstoječih koreografij.
Koreografije, kot jih podpira CDL, so nadaljevanje koncepta, ki ga je vpeljal BPEL kot abstraktne poslovne protokole. V tem smislu CDL dopolnjuje možnosti za orkestracijo, ki jih ponuja BPEL. CDL šele nastaja in spada pod okrilje W3C. V končni obliki bo omogočal modeliranje poslovnih protokolov, kot npr. RosetaNet PIP, finančnih protokolov FIX ali TWIST in podobnih [7]. 5. ZAKLJUČEK Svojo pravo vrednost pokažejo storitvene arhitekture (SOA) šele pri uporabi procesno usmerjenega pristopa, ki eksplicitno definira povezave in sodelovanje storitev v poslovnih procesih ter sodelovanje procesov v poslovnih protokolih. Večina gradnikov za realizacijo procesno usmerjenih arhitektur SOA že obstaja. Sem štejemo tehnologije spletnih storitev, sklad dopolnilnih specifikacij spletnih storitev, storitvena vodila (ESB) in predvsem BPEL jezik za kompozicijo spletnih storitev. Novi nastajajoči standardi, predvsem WS-CDL, pa obljubljajo podporo koreografiji, s ciljem zagotavljanja podpore celotnemu življenjskemu ciklu sodelujočih, prilagodljivih poslovnih procesov. Organizacije, ki želijo avtomatizirati svoje poslovne procese z uporabo odprtih standardov in tehnologij in želijo doseči v začetku prispevka postavljene cilje o agilnosti, prilagodljivosti in odzivnosti, so z uporabo SOA, ESB in BPEL na pravi poti. Ob tem velja poudariti, da gre za arhitekture in tehnologije, ki so na voljo danes. V prihodnosti pričakujemo še dodatno podporo opisu sodelovanj med organizacijami. Že danes pa je jasno, da vpeljava SOA, razvoj storitev in njihova orkestracija v procesnem smislu, organizaciji prinese bolj učinkovito in bolj prilagodljivo informacijsko infrastrukturo in s tem prispeva k lažji in hitrejši realizaciji poslovnih ciljev. LITERATURA 1. Matjaž B. Jurič with Benny Mathew, P. Sarang, Business Process Execution Language for Web Services, Packt Publishing, October 2004 2. World Wide Web Consortium, Service Oriented Architecture, Web Services Architecture Group, 2003 3. Matjaž B. Jurič with Ramesh Nagappan, Rick Leander, S. Jeelani Basha, Professional J2EE EAI, Wrox Press Inc; ISBN: 186100544X; 1st edition, december 2001 4. Matjaž B. Jurič, J2EE for Enterprise Application Integration and e-business Integration, ACM OOPSLA 2002, Seattle, Washington, november 2002 5. Matjaž B. Jurič, Marjan Heričko, J2EE, EAI & Web Services, Web Services Journal, May 2002, Vol 2, Issue 5 6. Matjaž B. Jurič, Maja Pušnik, Sklad tehnologij za spletne storitve, Objektna tehnologija v Sloveniji, 2004, zbornik konference 7. Pušnik Maja, Jurič Matjaž B.: Electronic Business Framework Evaluation, Informacijska družba 2003, Ljubljana, oktober 2003, str. 178-181.