Szolgáltatás-Orientált Architektúrák (Service-Oriented Architectures, SOA)

Történeti áttekintés, bevezetés
A SOA napjaink üzleti információ technológiájának (IT) fontos architektúrális megközelítése.
Kialakulását üzleti oldalról többek között a nem központi műveletek kiszervezése (outsourcing) és az üzleti folymatok
újratervezése (reengineering) befolyásolta. Technológiai oldalról pedig a middleware szabványok és architektúrák
kialakulása segítette, okulva az osztott objektum rendszerek (distributed object systems) és az üzenet-orientált middleware
(message-oriented middleware) sikereiből és hibáiból.
A SOA egy architektúrális elv. A Web szolgáltatások technológia a SOA szabvány alapú, XML-központú megvalósítása.
Az üzleti folyamatok egyes műveleteit partnerekhez kihelyezve szükségessé válik az együttműködés az adott társasággal.
Így a vállalat valójában egy virtuális vállalat lesz, ami kivűlről egy valódi vállalatnak látszik.
A SOA és a Web szolgáltatás technológia biztonságosan és megbízhatóan teszi lehetővé ezt a kiszervezést.

A munkamegosztásnak három szintje van:
együttműködés: bizonyos tevékenységeket külső cégek végeznek,
egyesülés: egyenrangú félként, együtt oldják meg a feladatot,
megszerzés: ha fontos folyamatot kellene kihelyezni.
A helyzet rendkivűl dinamikusan változhat: kapacitás, határidő, költségek tekintetében.
Erőforrás megosztással is megoldhatók az üzleti folyamatok: alkalmazás szolgáltatás ellátókkal
(Application Service Provider, ASP): Grid computing.
Az esetenként dinamikusan felderített szolgáltatások közötti kommunikációhoz laza kapcsolat (loose coupling) szükséges
az igénylő és a szolgáltató között. A laza kapcsolat kizár bármiféle előzetes ismeretet vagy feltételezést a platformokról,
a formátumokról és az együttműködési protokollokról. A laza  kapcsolat a SOA alapvető ismérve.

A szokásos osztott rendszerek az objektum technológián alapulnak, ekkor a szolgáltatást egy osztály metódusaként kínálják fel.
Ha az osztály (hierarchia) változik, akkor az őt használó alkalmazást is meg kell változtatni: az igénylő és a szolgáltató
szoros kapcsolatban (tight coupling) áll.
A CORBA (Common Object Request Broker Architecture), a J2EE (Java 2 Platform, Enterprise Edition) és a
COM (Component Object Model) osztott rendszer technológiák teljesen különböző és inkompatibilis objektum modellen alapulnak.
Ezért ezen platformok között az együttműködés nehéz, körülményes, ha egyáltalán lehetséges.
Nemcsak az objektum modelljeik különböznek, hanem az őket támogató magasabb szintű keretek
(tranzakció, biztonság, menedzselés és üzenetküldés) sem kompatibilisek. Ezt áthidalni nehéz feladat.
Speciális integrációs middleware-ket hoztak létre az integrálandó alkalmazások közötti üzenetküldésre.
Az adapterek becsomagolják ezeket a meglévő alkalmazásokat. Az adapterek egyik típusa (forrás adapter) jelzi a továbbítandó
esemény megtörténtét, a másik típus (cél adapter) pedig fogadja és továbbítja ezeket az eseményeket.
Az eseményeket üzenetek képviselik, melyeket az úgynevezett csatornákon szállítanak. A csatornák bizonyos szolgáltatási
mínőséget biztosítanak (pontosan egy kézbesítés) és át is alakíthatják az üzenetet, hogy a fogadó megértse azt.
Ebben az üzenet-alapú architektúrában az alkalmazások lazán kapcsoltak.

Az osztott objektum rendszerekben uralkodó szinkron kérés/válasz együttműködési és kommunikációs stílus helyett mások
szükségesek a lazán kapcsolt együttműködéshez, például az asszinkron küldés/fogadás. Ekkor a csatorna tárol és továbbít
módon működik és végül az üzenetet a célhelyre kézbesíti. Egy másik módszer lehet, hogy az üzenet több fogadónak kézbesíti,
de csak egy részük válaszol (pl. árverés). Tehát támogatni kell az üzenetváltás módjának (MEP - Message Exchange Pattern)
meghatározását.

A Web szolgáltatás technológia az üzenetváltás elvére épül, így az igénylők és a szolgáltatók különböző platformokon
futhatnak, melyeket csatornák kapcsolnak össze. A borítékok (wrappers) elrejtik a becsomagolt alkalmazás implementációs
sajátosságait. A csatorna protokollok rejtettek a kommunikációs partnerek elől, a csatornán belül pedig különböző
formátumokra való átalakítás is lehetséges.

A WSDL (Web Services Description Language, Web szolgáltatás leíró nyelv) általánosan elfogadott, szabványos nyelv
a szolgáltatás interfészének leírására, ami géppel is olvasható. Ez lehetővé teszi, hogy az igénylő bármikor egy másik
szolgáltatás implementációt válasszon ugyanahhoz az interfészhez.
A szolgáltatásokat nemcsak a WSDL interfészük írja le, hanem a biztosított szolgáltatás mínősége is. Tehát például azt
állíthatja magáról, hogy az üzeneteket titkosan is tudja kezelni. Ezek képességek a Web szolgáltatási politikával
építhetők be (Web service policy).
A szolgáltatásokhoz üzleti vonatkozású adatok társulhatnak. Az UDDI (Universal Description, Discovery and Integration,
univerzális leírás, felderítés és integráció) katalógusa támogatja ezt a lehetőséget és lehetővé teszi információk
tárolását és lekérdezését a szolgáltatást nyújtó társasággal kapcsolatban, pl. elérhetőségek, földrajzi adatok, stb.
Ez lehetővé teszi a megfelelő szolgáltatás felderítését.

A mindennapi életben sokféle szolgáltatással találkozhatunk: víz, gáz, telefon, villany, hitelkártya, közlekedés,
utazási irodák, Internet, keresők a Weben, stb. A szolgáltatásokat leírásaik alapján derítjük fel (metadata).
Az egyes szolgáltatások össze is rakhatók (utazási iroda: szállás, autókölcsönzés, étkezés, stb.).
A felhasználó általában keveset vagy egyáltalán nem tud arról, hogy a szolgáltatás hogyan van megvalósítva.

Szoftver szolgáltatások
Kialakulásának főbb állomásai: 
Funkcionális dekompozíció (függvények, szubrutinok), ami lehetővé tette a modularizációt. Az összetartozó függvények
csomagja bonyolultabb feladatok megoldását segítette elő, de ez pusztán egy szintaktikus egység.
Objektumok, osztályok. Az osztály az objektum viselkedését a probléma oldaláról is leírva szemantikai jellemzőket is
tartalmaz. A polomorfizmus és az öröklődés a szoftver építés rugalmas eszköze. Az osztály hálók szemantikáját általában
csak a fejlesztők értik.
Ezzel szemben a szolgáltatásokat nemcsak az interfészeik írják le, hanem üzleti leírásuk is van, ami szélesebb közösség
számára is érthető.
A komponensek a felhasználással (bevetéssel) is foglalkoznak, így az alkalmazási logikára koncentrálhat a komponens ellátó.
A szolgáltatás mínőségi paramétereit a futásidejű környezetben a bevetési leírókkal (deployment descriptors, J2EE)
állíthatjuk be (pl. helyi adó mértékek).  Az alkalmazás logikát tartalmazó konténer értelmezi a bevetési leírókat,
ami lehetővé teszi, hogy a komponensek kereskedelmi művek legyenek.
A komponens modell absztrakciója a szolgáltatás, ami a szoftvercsomagok fejlődésének újabb állomása.
A szolgáltatás elrejti a komponens megvalósítási részleteit, hogy az J2EE-alapú vagy .NET alapú komponens-e.
Ezzel jelentősen növeli a különböző platformok közötti együttműködés lehetőségét.
A szolgáltatások modell értékes jellemzője, hogy a meglévő szolgáltatásokból újak hozhatók létre. A koreográfiának
(choreography) nevezett technológia lehetővé teszi a meglévő szolgáltatások összeépítését és végrehajtásának összehangolását
(orchestration). Az üzleti folyamat a szolgáltatások koreográfiája, amely megold egy komplex üzleti feladatot.
A koreográfia meghatározza, hogy mely szolgáltatásokat, milyen sorrendben és milyen feltételekkel használjunk.
A koreográfiák is egymásba ágyazhatók (rekurzió). A koreográfiák szolgáltatásokat használnak és az eredményt szolgáltatásként
adják meg.

A SOA egy speciális architektúrális stílus, melyet a szolgáltatások laza kapcsolata és dinamikus kötése jellemez.
A SOA hatékony működéséhez a következő nagyon fontos tényezők szükségesek:
Kötés/Közzététel/Keresés (Bind/Publish/Find)
Először is szükséges a szolgáltatás absztrakt definíciója. Másodszor a szolgáltatást nyújtóknak közzé kell tenniük a
szolgáltatásaik részleteit. Harmadszor az igénybevevőknek meg kell tudni találniuk a megfelelő szolgáltatást.
Ahhoz, hogy ez kötés/közzététel/keresés megfelelően működjék szabványok szükségesek mindegyik műveletre.
A szolgáltatás leíró információit a WSDL-lel és a politikával adjuk meg. A közzététel és a felderítés egy különálló
regiszterrel (vagy katalógussal), mint amilyen az UDDI valósítható meg.
A szolgáltatás dinamikus felderítéséhez és kötéséhez a következő lépések és eszközök szükségesek. Először az igénylő leírja
a keresett szolgáltatás tulajdonságait. A felderítő eszköz előállítja a feltételeknek megfelelő szolgáltatások listáját,
amiből az igénylő kiválaszt egyet esetleges további kritériumok alapján (pl. költség). A kiválasztás után meghatározza a
cím és kötési adatokat, pl. a használandó protokollt és az üzenetküldés formátumát.
Ezt a körülményesnek tűnő folyamatot a szolgáltatás busznak (service bus) nevezett middleware egyszerűsítheti és
átláthatóbbá teheti. A szolgáltatás busz fogja a szolgáltatás leírást, a felderítő eszközzel megkeresi a lehetséges
szolgáltatásokat, választ közülük egyet, lehívja a kötési információkat, a szolgáltatáshoz automatikusan köt,
megfelelően átalakítja az igénylő input adatait, az ennek megfelelő üzenetet elküldi a szolgáltatásnak, fogadja a választ,
és azt megfelelő formátumban továbbítja az igénylőnek. A service bus jelentősen megkönnyíti a SOA Web szolgáltatás alapú
implementációját. A Grid-nek nevezett osztott számítási környezeteti technológiát is lehetővé teszi a service bus.
Megjegyzendő, hogy a CORBA Trader szolgáltatásában a SOA bizonyos jellemzői megtalálhatóak, de ezek gyakran nem teljesek
és a platform függetlenség tekintetében nem univerzálisak.

A SOA implementálásának alapja a Web szolgáltatás technológia, és ennek központjában a service bus áll. 
A service bus magasszintű architektúrája, ami a SOA képességek stackje, a következő. Az legalsó réteg a szolgáltatás és az
igénylő közötti kommunikáció különböző szállítási protokolljait jelenti. A szállítási réteg feletti üzenetküldő réteg
lehetővé teszi, hogy a busz kezelni tudja az XML és a nem-XML üzeneteket is. A következő réteg lehetővé teszi és kezeli
a szolgáltatás leírásokat a támogatott funkciók, ezen funkciók mínősége és a kötési mechanizmusok tekintetében.
A tényleges szolgáltatási mínőségek, melyeket a szolgáltatási politika alapján a busz végrehajt a következő rétegben
foglal helyet. Ez a réteg foglalkozik a biztonsági kérdésekkel (üzenet integritás, bizalmasság, letagadhatatlanság),
az üzenetek megbízható szállításával és a különféle tranzakció fajtákkal. A legfelső réteg a Web szolgáltatások által
képviselt különféle virtuális komponenseket ábrázolja. Ez a réteg biztosítja az atomi szolgáltatásokat,
az összetett szolgáltatások, mint például a koreográfiák és szolgáltatás együttesek, egy szerződés protokoll alapján
jönnek létre. Egy további réteg pedig a szolgáltatások felderítését és leírásukat biztosítja.

Háttér ismeretek
Rövid összefoglalás az XML (eXtensible Markup Language) fogalmakról:  az XML alapelve, Document Type Definitions (DTD),
XML Schema, XML névterek, XML Infoset és XPath) és a Web fogalmakról: Uniform Resource Identifier (URI),
HyperText Transfer Protocol (HTTP) és Multipurpose Internet Mail Exchange (MIME).

XML
A Web szolgáltatások nagyon erősen épülnek az XML specifikációk központi elemeire. Az XML egy metanyelv, mellyel új nyelvek
defíniálhatók. Az XML defíniciója paltform független és az Unicode-ot használja. Ezek miatt az XML-t gyakorlatilag minden 
szoftver gyártó támogatja, így az adatcsere de facto formátuma lett.

Az XML-nek kisszámú alapfogalma van, amivel új nyelvek defíniálhatók:
elemek: az XML elem egy névvel rendelkező konstrukció, amelynek lehetnek attribútumai és gyerekei.
Egy elem gyerekei lehetnek más elemek, literal szöveg, megjegyzés és néhány további típus. Az elemeket hegyes zárójel
segítségével írjuk le:
<elemnév>  és  </elemnév>
módon.

attribútumok: az attribútumok az elemhez társított név-érték párosok, számuk nem korlátozott, írásmódjuk:
<elemnév attr1="érték1" attr2="érték2"...> 
megjegyzések: a megjegyzést  <!--  és  -->  karaktersorozatok közé kell írni, és ezt a processzor figyelmen kívül hagyja.
literal szöveg: az elemek tartalmazhatnak Unicode karakterekből álló karakter sorozatokat. Az XML dokumentumban minden
karakter Unicode-ban ábrázolódik, ezért defínició szerint az XML nemzetköziesített.
dokumentum: az XML dokumentum egyetlen elemből áll, amit dokumentum elemnek nevezünk és ami kommentárokat és néhány
más elemet tartalmazhat.
Ezen fogalmakkal új nyelveket defíniálhatunk úgy, hogy meghatározzuk az elemek nevét, lehetséges tartalmukat,
az attribútumok elfogadható literál szöveg fajtáit és az elemek tartalmát. Kulcs fontosságú fejlesztés az SGML-hez képest,
hogy bevezették a helyesen formázott (well-formed), de nem szükségszerűen érvényes dokumentum fogalmát.
A dokumentum akkor helyesen formázott, ha az összes XML szintaktikai szabálynak eleget tesz. A helyesen formázott doumentum
érvényes, ha megfelel egy DTD vagy XML Schema, vagy valami egyéb szerkezet defíniáló nyelvnek.

A SOAP üzenet formátumot meghatározó elemek egy XML szótárat példáznak. Egy másik példa a WSDL.
A legtöbb Web szolgáltatási specifikáció egy vagy több XML nyelvet defíniál.
DTD, XML schema
A DTD-t az SGML dokumentumok szerkezetének deklarálására hozták létre. A DTD nyelv nem-XML szintaxisú nyelv az elemek
nevének, előfordulási számának egy másik elemen belüli meghatározását, stb. teszi lehetővé. Az XML megjelenésekor
ez volt az egyetlen szabványos defíniáló nyelv.
Az XML Schema-t a W3C (World Wide Web Consortium) fejlesztette ki dokumentum szerkezet és típus defíniálására.
Az XML Schema XML szintaxist használ az XML szerkezet meghatározására, és lehetővé teszi adattípusok defíniálását is.
Meghatároz egy sor elemi adattípust, amivel kijelölhetjük az attribútum és elem értékeket. A rekurzív típus konstruktorral
pedig tetszőlegesen összetett adatszerkezetet hozhatunk létre. Az XML Schema széleskörű ipari támogatottságot élvez.
Az XML névterek lehetővé teszik, hogy több XML nyelv összefésülésekor elkerüljük a névütközést. Az XML névterek az elem
és attribútum neveket kiterjesztik egy névtérrel, ezáltal azok mindíg egyediek lesznek. A mínősített nevek
(qualified names, Qnames) egy névtér név és egy lokális név együttesei.
Az XML Infoset az XML alapjait, információs modelljét határozza meg, azaz elvonatkoztat a hegyes zárójelektől.
Az Infoset meghatározza az XML szintaktikai szerkezétének megfelelő információs tételeket. A következő fontos információs
tételek léteznek:
Elem információs tétel (Element Information Item, EII): az EII az elem absztrakciója. Az EII tulajdonságai közé tartozik
a gyerekek listája, az attribútumok listája, a név és a névtér név, és így tovább.
Attribútum információs tétel (Attribute Information Item, AII): Az AII az attribútum absztrakciója.
Az AII tulajdonságai a neve, a névtér neve, az értéke, stb.
Karakter információs tétel (Character Information Item, CII): a CII az elem tartalmaként talált literál szöveget jelenti.
Ha az XML Schema-t használjuk a dokumentum ellenőrzésére, akkor az Infoset kiegészíthető, ami a
Post Schema Validation Infoset-et alkotja (PSVI). A PSVI alapjában véve további tulajdonságokat tartalmaz az elemekre
vonatkozóan: típus információ és ellenőrzöttségi állapot. 

Az XML tényleges hatása az Infoset szinten nyugszik. A hegyes zárójeles megjelenítés válójában az Infoset szerializációja,
melynek két példája az XML 1.0 és az XML 1.1.
A jövőben az XML Infoset valószínűleg nem a Unicode karaktereket fogja használni, hanem a bináris szerializációt,
ami rendkivűl helytakarékos és gyorsan lehet feldolgozni. Ezt az absztrakt elvet viszi tovább a SOAP 1.2 és a WSDL 2.0.
Az Infoset kezelésének programozási API-jai a Document Object Model (DOM), a Streaming API for XML (SAX), stb.
Az XML Path Language (XPath) az XSL része az XML dokumentumok elemei, attribútumai, stb. azonosítására.
Az XPath az elemek kiválasztására, kiemelésére is használható, az XQuery alapja, ami egy teljes XML lekérdező nyelv.
A World Wide Web (WWW) általánosan elfogadott, szabványos elemeit az URI-t, a HTTP-t és a MIME-t az előző órákon tárgyaltuk.

Web szolgáltatások
Mint azt a bevezetőben már említettük a SOA absztrakt architektúrális elv egyik jelentős megvalósítása a Web szolgáltatások.
A Web szolgáltatások néhány defíniciója:
A W3C (ami irányította a SOAP és a WSDL specifikációk kifejlesztését) szerint:
A Web szolgáltatás olyan szoftver rendszer, melyet arra terveztek, hogy támogassa az együttműködőképes gép-gép közötti
egymásrahatást egy hálózaton. Rendelkezik egy géppel feldolgozható formátumban (WSDL) leírt interfésszel.
Más rendszerek a Web szolgáltatással SOAP üzenetekkel működnek együtt oly módon, ahogy azt a leírása megszabja,
az üzeneteket szokásosan a HTTP felhasználásával, XML szerializációval és egyéb Web-bel kapcsolatos szabványok alapján
továbbítja.
A Web szolgáltatások megközelítés és a hagyományos megközelítés (pl. Object Management Group - Common Object Request
Broker Architecture, OMG CORBA, vagy Microsoft Distributed Component Object Model, DCOM) közötti alapvető különbséget
a laza kötés jelenti. A másik fontos különbség abban áll, hogy a technológiákat és specifikációkat nyílt módon
fejlesztették ki: W3C, OASIS (Organization for the Advancement of Structured Information Standards), ami biztosítja,
hogy mind az ipari, mind a felhasználói igények figyelembe lettek véve.
A Web szolgáltatások kezdete 2000 közepére tehető, az XML üzenetküldés (SOAP, WSDL 1.1) és az UDDI kezdeti verziójának
megjelenésével.

A SOA keretrendszert megalapozó technológiák
Szállítási szolgáltatások
A üzenettovábbítási technológiák a Webszolgáltatások architektúra alapjai. A Webszolgáltatások szállítás semlegesek.
Használhatjuk a mindenütt jelenlévő HTTP-t, vagy a biztonságos HTTP-t, a HTTPS-t, de bármely más komuunikációs protokollt is.
Ezek működését itt nem részletezzük.

Üzenetküldési szolgáltatások
A SOAP (Simple Object Access Protocol) egy egyszerű mechanizmust biztosít a különböző platformokon épült szolgáltatások
közötti struktúrált és típusos információcserére. A W3C jelenleg az 1.2 verziót szabványosította.
A SOAP üzenetnek, ami egy XML dokumentum, három eleme van: a boríték (envelop), a fejrész (header) és a törzs (body).
A SOAP meghatározása független az alatta lévő üzenetküldési mechanizmustól. A konkrét mechanizmus kiválasztása futásidőben
történik és akár az útvonal csomópontjai között is változhat. Használhat szinkron és asszinkron kérés/válasz módszert is.
Az üzenetek útvonalválasztása a fejrész tartalma és az üzenet törzsben lévő adatokon is alapulhat.
Ez az előnyös tulajdonság nem található meg a DCOM, CORBA és Java RMI architektúrákban.

A WS-Addressing lehetővé teszi az üzenetküldők és fogadók szállítás-független azonosítását, amit azzal ér el, hogy a cél,
a forrás és más fontos cím információkat közvetlenül a Web szolgáltatási üzeneten belül helyezi el. Ez a specifikáció
lehetővé teszi az üzenetküldő rendszer számára az üzenetek továbbítását olyan hálózatokon is, melyekben végpont menedzser,
tűzfal és kapu csomópontok is vannak.
A WS-Addressing a végpont hivatkozás és a üzenet információ fej konstrukciók segítségével egységes formátumban tárolja,
melyek a szállítástól vagy az alkalmazástól függetlenül feldolgozhatók. Ezek a konstrukciók bővíthetők és újra
felhasználhatók.

A szolgáltatás leírása
A szolgáltatás leírás olyan metaadat, amely teljesen leírja a szolgáltatás jellemzőit, ez a lehetőség alapvetően fontos
a laza kapcsolat megvalósításához, biztosítja azon információk absztrakt defínicióját, melyek szükségesek a szolgáltatás
bevetéséhez és a vele való együttműködéshez.

WSDL
A WSDL (Web Services Description Language) lehetővé teszi a Web szolgáltatás funkcionális jellemzőinek leírását,
azaz a kapott és küldött üzenetek függvényében végrehajtandó műveleteket. A WSDL egy XML formátum a szolgáltatás
végpont halmazának leírására, melyek az üzenetekre hatnak. A műveletek és az üzenetek leírása absztrakt és később kötődnek
konkrét hálózati protokollhoz és üzenet formátumhoz, hogy meghatározzanak egy végpontot.
A WSDL dokumentumnak két része van: az absztrakt defíniciók és a konkrét leírások. Az absztrakt rész a SOAP üzenetet
nyelv és platform-függetlenül defíniálja. Ezzel szemben a konkrét leírás szerializációként defíniálja a specifikus dolgokat.
A WSDL lehetővé teszi a különféle üzenetminták leírását is.

Politika (policy)
A Web szolgáltatás funkcionális leírásán túl szükséges a használatával kapcsolatos korlátozások és feltételek megadása is.
A WS-Policy specifikáció család bővíthető keretet biztosít ezen szolgáltatás biztonsági mínőségek és előírások leírására
géppel olvasható kifejezések formájában.

Felderítési szolgáltatások
A szolgáltatások leírását hozzáférhetővé kell tenni a felhasználók számára: tárház/regiszter (repository/registry)
szolgáltatás.
UDDI