XML
webszolgáltatások fejlesztése
.NET platformon
Farkas Péter
Konzulens:
Dr. Charaf Hassan
hassan@avalon.aut.bme.hu
BME
– Automatizálási és Alkalmazott
Informatikai Tanszék
1111 Budapest, Goldmann György
tér 3.
Összefoglalás
Az Internet fejlődésével egyidejűleg, a felhasználók igényei is megnőttek. A kezdeti szakaszra jellemző statikus oldalakat felváltották a dinamikus tartalmú oldalak. Napjainkban viszont egyre nagyobb teret hódít az e-business és az e-commerce. Ezek alapja, hogy nem kell hosszú perceket sorbanállással töltenünk, hanem „üzleti” ügyeinket elintézhetjük otthonról is, egy karosszékben ülve. Ehhez, a cégeknek biztosítaniuk kell a szolgáltatásuk elérhetőségét a hálózaton keresztül is, nemcsak személyes megjelenés útján. Egy másik feljődési irányzat szerint: a szofver gyártás a hardver eszközök előállításához kezd hasonlítani abból a szempontból, hogy a programot előregyártott komponensekből építsük fel. A harmadik trend az, hogy a szoftvert, mint szolgáltatások halmazát kell tekintenünk. Ezen irányelvekből egy új fogalom született: az XML webszolgáltatás. Jellemzője, hogy komponens, szolgáltatás, platformfüggetlen és nyitott.
Bevezetés
Az egyszerűen programozható webhozzáférés azt jelentené, hogy a fejlesztők saját programjukat a weben elérhető szolgáltatásokból építik fel komponensről - komponensre. A már megírt kódokat felhasználhatjuk, beépíthetjük programunkba – bizonyos feltételek mellett. Erre most is találhatunk példát: JavaScript-ek felhasználása a saját oldalunkon. Azonban ezek nincsenek központosítva, nem tudjuk, hol találhatók meg, és főleg nem tudjuk, milyen feltételekkel hasznosíthatjuk a már megírt kódrészletet.
„A webszolgáltatás egy szabványos webprotokollon elérhető, programozható logika.”
Ez a rövid, de pontos definíció határozza meg az összes szempontot, ami mérvadó egy ilyen program elkészítésénél:
Platform- és nyelvfüggetlenség: az adatok kezelése gép- és operációsrendszer függő. Szeretnénk, ha a webszolgáltatások nyújtotta lehetőségeket tetszőleges programozási nyelvben felhasználhatnánk.
Szabványosság: olyan felületet kell biztosítani a felhasználók számára, ami támogatja az egységes adatreprezentációt.
Elérhetőség: a kommunikációra használjunk fel egy olyan nyelvet, melyet minden géptípus ismer és elfogad.
Milyen legyen a webszolgáltatások protokollja?
Az üzenetküldés szabványokon keresztül valósuljon meg.
Az adat és a reprezentáció külön kerüljön, így a megjelenés fejlesztése sokkal könnyebb.
A HTTP fölött képes legyen eljáráshívásra különböző platformokon és tűzfalakon keresztül.
Támogassa a web szabványos autentikációs eljárásait.
A webszolgáltatások több különböző protokollra építenek: az alfejezetek elején található kérdés jellemzi leginkább az adott protokoll feladatát.
Alkalmazott protokollok
XML1
MIKÉNT használhatom az adatokat?
Az XML biztosítja az egységes adatreprezentációt a különböző platformokon. Jelölő nyelvként, szövegesen ábrázolja az adatokat, így valóban függetleníti magát az adott géptől, illetve operációs rendszertől. Mellesleg szöveges formában mind gép, mind ember számára könnyen olvasható.
Ez a technika nem mondja meg, hogyan használhatóak a „hagyományos” típusok, és azt sem, hogyan lehet őket kiterjeszteni, ezért az XML sémákat használjuk kiegészítésként: ebben szerepelnek az egyszerű típusok, és egy nyelv, mellyel továbbiakat definiálhatunk. Webszolgáltatás készítésekor az általunk létrehozott típusok mindegyike a sémákban meghatározott típusra konvertálódik, hogy a szabványos és egységes kommunikációs felület megmaradjon.
Egy webszolgáltatásban minden XML nyelven történik: a kommunikáció egyes szereplők között, az adatok egységes kezelése, sőt a konfigurációs állományok beállításai is mind – mind az XML dokumentumokat veszik alapul.
SOAP2
MIVEL hívható meg a szolgáltatásunk?
Az ISO OSI modellt alapul véve, mely a mai hálózatok alapvető leíró struktúrája, az egymásra épülő rétegek interfészeken keresztül vehetik igénybe az alattuk lévő réteg szolgáltatásait. Ez igaz, a webszolgáltatásokra is. Azokat csak a külvilág felé mutatott függvényeiken keresztül érhetjük el.
A SOAP egy alkalmazás rétegbeli protokoll, mely felhasználja a HTTP réteg szolgáltatásait. Ez egy ajánlás, mely:
Általános leírást ad az adatok kézbesítésére XML dokumentumként, felhasználva az XML és az XSD nyújtotta lehetőségeket. A protokoll két üzenetből áll: egy kérésből és egy válaszból. Ahhoz, hogy az alkalmazások között nagyobb méretű adatot továbbítsunk, bevezette a boríték fogalmát.
Leírja a webszolgáltatásban szereplő egyszerűbb és összetettebb adattípusainak használatát és az azoknak megfelelő üzeneteket.
Megfogalmazza a HTTP-re történő leképezés szabályait.
A HTTP-t minden számítógép ismeri, ezért használjuk átviteli protokollként. Az adatok kézbesítésére létrehozott SOAP borítékot, beágyazhatjuk a HTTP GET és POST kérésekbe. A webszolgáltatásunknak küldött HTTP POST kérésünk is egy ilyen borítékot tartalmaz a fejléce mögött. A SOAP boríték törzse tartalmazza függvényünk paramétereit, illetve visszatérési értékét, esetleg annak hibaüzeneteit. A boríték kiterjesztéseként, annak fejlécében, lehetőségünk nyílik az autentikációs mechanizmusok végrehajtására is.
WSDL3
HOGYAN érhetjük el a szolgáltatást?
A fejlesztőnek egy leírást kell adnia arról, hogy mit csinál a webszolgáltatása, és hogyan kell azt utasítani a kívánt művelet elvégzésére. A kliens alkalmazásnak viszont ismernie kell a szolgáltatás által nyújtott metódusokat, szükséges paramétereiket és az általuk támogatott protokollokat.
A WSDL egy jólformált XML dokumentum, melyben szerepel a szolgáltatás által elvégezhető műveletek listája és elvégzésük módja. Egy szolgáltatást több különböző protokollon módon vehetünk igénybe (HTTP GET, HTTP POST, SOAP,...), ezekhez egy – egy port-ot rendelünk. A port tartalmazhat hivatkozásokat a dokumentum egyéb elemeire. Ezek az adatok írják le, hogy az egyes protokollok milyen bemenő formátumot várnak el, és hogyan küldik a kimenetre az adatot.
UDDI4
HOL található meg a webszolgáltatás?
Ez nem más, mint egy nyilvántartás, ami adatokat tartalmaz cégekről, és az általuk nyújtott webszolgáltatásokról. Természetesen ez is XML-alapú, ami megkönnyíti a kommunikációt és egységesíti a lekérdezéseket. Ezt a nyilvántartást, megírt programunkból SOAP protokollon keresztül érhetjük el valamelyik nagyobb csomópontnál (Microsoft, IBM, HP, SAP). Az elosztott adatbázis naponta szinkronizálódik. A fenti helyeken a lekérdező és az adminisztratív funkciók vannak megvalósítva, ami kereséshez, illetve publikáláshoz szükséges.
.NET framework
A keretrendszer a webszolgáltatás készítésére és kezelésére automatikus megoldást nyújt. Nekünk tényleg csak az implementálással kell törődnünk, és nem kell foglalkoznunk a SOAP üzenetekkel, a WSDL állománnyal, hogy használhassuk a szolgáltatásunkat. Ezeket az általunk felépített objektumhierarchiából a program legenerálja. Minden webszolgáltatást egy fa hierarchiába szervezett konfigurációs állomány ír le. Ezekben a futási paramétertől kezdve a jogosultságokon át minden információt beállíthatunk. Jelenleg (a .NET beta verziójában) két nyelv alkalmas webszolgáltatások készítésére: a VB.NET és a C#.
A framework ugyancsak megkönnyíti webszolgáltatásunk elhelyezését és megtalálását is az adatbázisban. Beépített keresőjével nemcsak a helyi gép összes szolgáltatását vehetjük igénybe, hanem a Microsoft UDDI adatbázisában is kereshetünk komponenseket programunk kibővítéséhez.
Egy webszolgáltatás vázlata
Tekintsük a következőt: egy meteorológiai szolgáltatást írunk, ahol az ügyfél beírja a város nevét és válaszként megkapja az adott helység várható időjárás jelentését.
A webszolgáltatás egyetlen függvényből áll, amit egy sztringgel hívunk meg. Ennek a visszatérési értéke, egy adathalmaz, mely tartalmazza az adott nap napszakjainak hőmérsékleti értékeit, az aznapi várható csapadékmennyiséget, illetve szélerősséget. A komplex válaszból és a paraméterből is kitűnik, hogy egy adatbázis áll a kiszolgálás hátterében, ami a város nevével megegyező rekordot fogja megmutatni az ügyfélalkalmazás részére.
Az adatbázis szerkezete egyszerű: elsődleges kulcsként a városok nevei szerepelnek. Minden napszakhoz két adat tartozik: egy minimum és egy maximum hőmérsékleti érték. A várható csapadék és szélerősség szintén egy-egy adatot jelentenek a rekordban. Például: Budapest -15 -8 -6 -1 -1 3 0 NE10 jelentése Budapesten éjszaka –15 és –8 °C, nappal -6 és -1 °C, délutánra -1 és 3 °C közötti hőmérséklet várható, csapadék nem valószínű, a szél 10 km/h sebességű észak-keleti.
A szerver oldalon szükségünk van egy adatbázisra, ahhoz kapcsolódnunk kell, és itt adatokat kell lekérdeznünk. A lekérdezés eredményét kell elküldenünk a kliens számára. A szolgáltatásnak létrehozott osztályunk a System.Web.Services névteret használja kiindulásként, és a System.Web.Services.WebService osztályból származtatjuk. Osztályunk tag- függvényei kétfélék lehetnek: belső függvények (ezeket nem hívhatjuk meg a webről), illetve külsők (WebMethod jelzővel deklarált), amiken keresztül programunk a külvilággal kommunikál. A külső függvény visszatérési értéke az adatbázisból lekérdezett sor lesz. Erre a framework egy DataSet változót biztosít számunkra, melyhez létrehozza a megfelelő XML sémát. A feltöltéséhez szükségünk lesz SqlConnection és SqlDataAdapter osztályok egy-egy példányára. Míg az előbbi a kapcsolódásért, az utóbbi a lekérdezésért felelős. Végezetül az SqlDataAdapter.Fill metódusával feltöltjük a DataSet mezőit, és ezt adjuk visszatérési értékként.
[WebMethod]
public WeatherToday GetWeather(string city)
{
WeatherToday wt;
// adatbázishoz kapcsolódunk és lekérdezzük a város időjárását.
return wt;
}
A kliens programot tetszőleges programnyelvben megvalósíthatjuk, mely képes értelmezni a WSDL állományokat. A szolgáltatás leíróját vagy a helyi gépen, vagy a UDDI nyilvántartásban kell keresnünk. Az ügyfélprogram hivatkozik a WeatherReport webszolgáltatásra, amit programból egy referencián keresztül érhetünk el. A referencia példányosítása után már meg tudjuk hívni a webszolgáltatásunk azon függvényét, melynek visszatérési értéke városunk aznapi időjárása. Ez az adat, a szerver oldalon előállított XML sémának megfelelő formátumban tárolódik. A rekord megjelenítésére két lehetőség kínálkozik: Windows Form vagy ASP5 oldal formájában.
Felhasználási területek
A webszolgáltatások használata kisméretű kliens alkalmazásoknál rendkívül hatékony lehet. Képzeljünk el egy mobiltelefont vagy egy PDA-t, amint a cégünk által igénybevehető szolgáltatások közt szemezget az interneten. Mivel ezek korlátozott kapacitással rendelkeznek, olyan felhasználói felületet kell létrehoznunk rajtuk, amely nem terheli le azok szabad erőforrásait. A webszolgáltatások esetében ez azt jelenti, hogy nem a szerver felelős a kliens oldali UI6 kidolgozásáért, hanem a kliens maga. Ezt lépést az indokolja, hogy a különböző kliensek másképpen jelenítik meg az adatokat, dolgozzák fel a típusokat. Ha ezt mind a szerver oldalon végeznénk el, az a válaszidő romlását és a sávszélesség drasztikus csökkenését eredményezné. Tehát az első szempont a hordozhatóság után, a kis méret.
Összegzés
A cikkel egy új technológia bemutatását tűztem ki célul, nem egy konkrét probléma megoldását. A webszolgáltatások megmutatták, hogy a cégek által nyújtott webes szolgáltatások koránt sincsenek kimerítve. És a .NET fejlesztőkörnyezet biztosítja mindazt, amiről egy fejlesztő álmodhat: könnyen és gyorsan írhat olyan kódot, mely az interneten keresztül más programokkal kommunikál.
Irodalomjegyzék
David S. Platt: Bemutatkozik a Microsoft .NET
MSDN help
1 eXtensible Markup Language
2 Simple Object Access Protocol
3 Web Service Descriptor Language
4 Universal Description, Discovery and Integration
5 Active Server Pages
6 User Interface