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:

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:

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.

A vázolt lehetőségek közül az első kettőt sikeresen meg is valósítottuk:

Irodalomjegyzék

William J. Pardi: XML in Action, Microsoft Press, 1999

www.w3.org/TR/soap