Heterogén rendszerek együttműködése SOAP segítségével
Csúcs Gergely (wizard@avalon.aut.bme.hu)
Marossy Kálmán (coloman@avalon.aut.bme.hu)
Dr. Charaf Hassan (hassan@avalon.aut.bme.hu)
BME, Automatizálási és Alk. Informatikai Tanszék
Napjainkban a komponensalapú szoftverfejlesztés képviseli a szoftverfejlesztés fő irányvonalát. A szoftverösszeszerelés (assembly) során használt komponensek sokféle forrásból származhatnak, közös bennük viszont, hogy a semmiből nem képződnek: valakinek meg kell írnia őket.
A mindenhol használatos komponensek (pl. GUI elemek) többnyire együtt érkeznek a választott fejlesztőeszközzel. Egyéb, tipikus magasszintű szolgáltatásokhoz (pl. biztonsági szolgáltatások: autentikáció vagy akár tranzakciókezelés) szintén hozzájuthatunk.
A komponensalapú szoftverfejlesztés kulcsszava az újrafelhasználás (és persze az újrafelhasználhatóság). Bármely kurrens komponensrendszer segítségével létrehozott szoftver-darab újrafelhasználható lesz. Viszont igazából nem csak újonnan létrehozott szoftvereket kéne újrahasznosítani, hiszen meglévő rendszerünk már valószínűleg rendelkezik valamilyen informatikai támogatással, és ennek használatáról esetleg kár volna végleg lemondani.
Egy olyan felületre van tehát szükség, amely illeszkedik a komponens- és/vagy szolgáltatásorientált szemléletmódhoz, ugyanakkor meglehetősen egyszerű. Az egyszerűség egyrészt a mi munkánkat könnyíti (az illesztést a nagy közös platform felé mindenképpen meg kell írni), másrészt nem ró túl nagy terheket egy elavulóban lévő hardware-re sem.
Az összes komponensrendszer egyik ki nem küszöbölhető hátránya a viszonylagos bonyolultságuk: RPC szabványokból fejlesztették ki őket, és ez többnyire jelentős adminisztrációt ró a kiszolgálókra. Jó lenne egyszerűbb adatreprezentációt alkalmazni, és erre az itt bemutatott eszköz kiválóan alkalmas.
A komponens-alapú programozás paradigmájától függetlenül, pontosan a régi rendszerekkel való adatcsere igénye miatt kezdődött egy eszköz fejlesztése, amely az XML (eXtensible Markup Language) nevet kapta.
XML
Egy XML dokumentum a széles körben használt <tagnév> </tagnév> markup szerkezetet használja, de nem formátumozásra. Ha azt mondjuk, a HTML az információ megjelenítéséről szól, akkor az XML a leírásukról, az XML egy adatreprezentáció.
<?xml verison=1.0?>
<NEVJEGY>
<NEV>Csúcs Gergely</NEV>
<FOGLALKOZAS>Egyetemi hallgató</FOGLALKOZAS>
<LAKCIM>Budapest</LAKCIM>
<TELEFON>1234-inkább ne hívj</TELEFON>
<EMAIL>wizard@avalon.aut.bme.hu</EMAIL>
</NEVJEGY>
A kód nem tartalmaz információkat arról, mindennek hogyan is kéne festenie akár a képernyőn, akár egy valódi névjegykártyán, ellenben a dokumentum önmagyarázó: ha egy ember ránéz, könnyen rájön, miről szól a dokumentum, és mi a struktúrája (ez utóbbiban persze némileg segíti, hogy pont így lettek a behúzások és sortörések elhelyezve). Persze egy program ránézésre csak a struktúrát látja ebből a kódból, vagyis egy fát.
Célszerű tehát nekünk tetsző adatformátumnak az XML-t választani.
SOAP
Az XML önmagában még csak egy adatreprezentáció, használatához azt is specifikálni kell, hogy mit, és hogyan csomagoljunk bele. Erre való a SOAP (Simple Object Access Protocol).
A SOAP hívások XML-dokumentumok, néhány megkötéssel:
Nem tartalmazhat feldolgozási utasításokat (így XML fejlécet sem)
Nem tartalmazhat dokumentumtípus-deklarációt
Gyökéreleme az Envelope, amely kötelezően tartalmaz egy Body elemet
Envelope
Az Envelope (kötelezően minősített elem, névtere a jelenlegi specifikáció szerint: http://schemas.xmlsoap.org/soap/envelope/) tartalmazza az egész SOAP hívást. Tartalmazhat egy Header, és tartalmaz egy Body elemet, amelyek vele egy névtérben kell, hogy legyenek.
A sorrend is kötött: az Envelope tag és a Body elem közé csak a Header kerülhet (ha van, akkor kötelezően odakerül), egyéb tartalom kizárólag a Body elem után következhet.
Az Envelope-nak lehet még egy encodingStyle attribútuma is, amelynél az adatok tárolásával kapcsolatos szabályok rögzítésével foglalkozó sémát adhatjuk meg, ez rendszerint http://schemas.xmlsoap.org/soap/encoding/, vagy nincs jelen.
Body
A Body elem használható egy eljárás hívás paramétereinek, vagy egy eljárás visszatérési értékének csomagolásához, illetve hiba visszajelzéséhez is. Az elem vagy közvetlenül a Header elem után következik, vagy ha az nem létezik, akkor az Envelope tag után.
A Body elemben lévő bejegyzésekre nincs megkötés, a SOAP specifikáció kizárólag a hibajelzésre szolgáló Fault elemet írja le. A bejegyzésekhez szintén megadható az encodingStyle attribútum, és névtérhez is tartozhatnak.
Header
A Header rész egy eljárás hívásának kibővítéséhez használható egyéb, előre nem meghatározott funkciókkal. Ilyen tipikus funkciók például a tranzakciókezelés, felhasználó azonosítás.
A Header elemben lévő bejegyzéseknek minősített névvel kell rendelkezniük. A Header-ben szereplő elemek tetszőleges attribútumokkal rendelkezhetnek, de létezik néhány előredefiniált is.
Az egyik ilyen attribútum a mustUnderstand, melynek szerepeltetése 1 értékkel azt jelenti, hogy ha a szerver oldalon az adott fejlécelem nem ismert, nem értelmezhető, akkor a hívást kötelező visszautasítani. Elhagyása esetén a szerver általa nem ismert elemeket egyszerűen figyelmen kívül hagyja.
A másik, szintén fontos attribútum az actor. Egy SOAP hívás feldolgozása alatt keresztülhaladhat több objektumon is, míg eljut a végcélhoz. Az actor adja meg annak az objektumnak az URI-jét, ami az adott fejlécelemet feldolgozza. Ilyen lehet például a tranzakciókezelő, hogyha a header elem egy tranzakció azonosító. Az actor elhagyása esetén a feldolgozás a végcél feladata.
Adattípusok
Az alap adattípusok a W3C XML Schema specifikációjának második részében találhatók meg. Bizonyos adattípusokat a http://schemas.xmlsoap.org/soap/encoding/ névtér alatt találunk meg.
Az XML sémákból adódóan a SOAP az adatok típusának és struktúrájának leírására olyan széles lehetőséget biztosít, hogy annak részletes ismertetése meghaladja ezen dolgozat kereteit. A függelékben azonban röviden olvashatunk az XML sémák adattípusairól.
Hibakezelés
Ha a szervernek nem sikerült valami miatt végrehajtani egy hívást, hibával kell visszatérnie. Ilyenkor a Body pontosan egy Fault elemet kötelezően tartalmaz, aminek a következő részei lehetnek:
faultcode
A
hiba rövid kódja
faultstring
A
hiba szöveges leírása, emberek számára
faultactor
A
hibát okozó objektum azonosítója
detail
Alkalmazásfüggő
hiba jelzésére használt
HTTP fejléc
SOAP hívások HTTP-n keresztüli lebonyolításához semmilyen különleges módszerre nincs szükség. Leggyakoribb a POST metódus használata, de a SOAP ezt nem teszi kötelezővé. A SOAP támogatja a HTTP Extension Framework-öt is.
SOAP kérésnél meg kell adni egy SOAPAction mezőt is a HTTP fejlécben, ami a kért metódus nevét, vagy egyéb objektum-azonosítót tartalmazhat, de akár üresen is maradhat. Az így átadott azonosítót például tűzfalak használhatják hívások szűrésére.
Hiba esetén, tehát amikor a Body elem egy Fault elemet tartalmaz a válasz fejlécében az 500 Internal Server Error hibaüzenetnek kell megjelennie.
RPC és SOAP
Egy távoli eljáráshíváshoz szükséges információk a következő helyen jelennek meg egy HTTP-n keresztüli SOAP hívásban.
A szerver objektum azonosítója megjelenhet a HTTP fejléc SOAPAction mezőjében, de máshol is. A metódushívás egy struktúra, melynek neve a metódus neve. Elemei a hívott metódus bemenő paraméterei (in ill. inout), melyeknek típusa megegyezik a hívott függvény paramétereinek típusával.
A válasz szintén egy struktúra, melynek neve (nem kötelezően, bár ajánlottan) a hívott függvény neve összekapcsolva a Response sztringgel. Ez az elem tartalmazza a metódushívás eredményét (visszatérési érték, valamint out ill. inout paraméterek).
A hiba egy, az előzőekben megadott Fault struktúrában helyezendő el. Szintén megkötés van a HTTP visszaadott hibakódjára (lásd az előző részt).
A hívások kibővítését a Header elemmel írhatjuk le. Itt lehet például megtalálni egy tranzakció azonosítót, amit majd valószínűleg a szerver oldalon lévő tranzakciókezelő dolgoz fel.
A SOAP használata legacy rendszerekkel való együttműködéshez
A legtöbb, amit tehetünk, hogy a SOAP komponenssé alakítandó rendszer különféle futtatási lehetőségeit felkínáljuk SOAP hívásra, tipikusan egy wrapper applikáción keresztül.
Ha az eredeti rendszer képes hálózatos működésre, a köztes alkalmazásra csak bridge-jellegű feladatok hárulnak:
Ez megvalósítható rendszerspecifikus módon (amikor az egyes elérhetővé tett szolgáltatásokhoz explicit kezelőrutinokat írunk; ezekből esetenként sokat kell elkészítenünk, de meglehetősen egyszerű szerkezettel bírnak)
Illetve protokollspecifikus módon: a bridge kínai-szobát valósít meg, azaz nem tudja, mit továbbít, csak azt tudja, milyen átalakításokra van szükség
Ha az eredeti rendszer egygépes használatra lett megalkotva, akkor még mindig sok múlik az alkalmazott operációs rendszeren
Amennyiben ez egyszálú működést tesz csak lehetővé, akkor könnyedén csak az adott szoftver parancssori futtatása által elérhető lehetőségek tehetők közzé
Ha a szoftver többszálú környezetben fut, és nagyon erős rá az igény, akkor a wrapper alkalmazás akár felhasználói interakció szimulálására is képessé tehető
A vázolt lehetőségek közül az első kettőt sikeresen meg is valósítottuk:
Alkalmazásspecifikus wrapper COM komponensek felé
CORBA illetve COM felé működő dinamikus híd, ami futásidőben szerzi be a rendszerek által biztosított repository-kból (registry ill. Interface Repository) a hívások/válaszok átalakításához szükséges információkat paraméterek nevei, típusai, stb.
Irodalomjegyzék
William J. Pardi: XML in Action, Microsoft Press, 1999
www.w3.org/TR/soap