Adatbányászati algoritmusok integrációja...
Transcript of Adatbányászati algoritmusok integrációja...
Konzulens:
Dr. Takách Géza
egyetemi docens
Edelényi Márton
doktorandusz hallgató
Készítette:
Szalay Dániel
II. évf. MSc gazdaságinformatikus hallgató
Adatbányászati algoritmusok integrációja
szolgáltatásorientált architektúrában
Dokumentáció
2011. május 13.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
i
Tartalom
1. Bevezetés ......................................................................................................................................... 1
2. Irodalomkutatás ................................................................................................................................ 3
3. Szolgáltatásorientált megoldás tervezése ......................................................................................... 4
3.1. Felhasznált technológiák és indoklásaik ................................................................................... 4
3.2. A tervezett rendszer ................................................................................................................... 7
3.2.1. Rendszerinformációs alkalmazás ........................................................................................ 8
3.2.2. Folyamatkövetés ................................................................................................................. 8
3.2.3. Biztonság ............................................................................................................................ 9
3.2.4. Nagy adathalmazok fogadásának képessége ...................................................................... 9
3.2.5. Intelligens adattár .............................................................................................................. 10
3.2.6. Folyamatok létrehozása .................................................................................................... 10
4. Implementációs állapot .................................................................................................................. 11
4.1. A webszolgáltatás implementációja ........................................................................................ 11
4.2. A rendszerinformációs alkalmazás implementációja .............................................................. 13
4.3. A .NET kliens implementációja .............................................................................................. 15
5. Összefoglalás ................................................................................................................................. 17
Irodalomjegyzék................................................................................................................................. 19
Ábrajegyzék ....................................................................................................................................... 22
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
1
1. Bevezetés
Eddigi munkáim során homogén környezetben, Java platformra programoztam robosztus
webalkalmazásokat [1]. Egy ilyen környezetben ritkán, vagy egyáltalán nem fordul elő olyan
probléma, hogy az egyes rendszerkomponensek integrációjával, integrálhatóságával kellene
foglalkozni. De mik a lehetőségeink akkor, ha különböző programozási nyelveken, különböző
platformra, illetve keretrendszerben írt rendszerkomponenseket szeretnénk átlátszó módon
integrálni? Hogyan tudnánk egy elemzési rendszert elkészíteni, úgy hogy annak egyes komponensei
különböző környezetben működnek, illetve különböző nyelveken írták őket. Ezekre a kérdésekre ad
választ ebbe a dokumentációba lefektetett munkám.
Az adatbányászat az új, jelentéstartalommal bíró összefüggések, minták, trendek, felfedezésének
folyamata, amelyet nagyméretű, tárhelyen tárolt adatok elemzésével valósít meg, felhasználva
mintafelismerési technológiákat éppúgy, mint statisztikai és matematikai eszközöket. Napjainkban
már léteznek nyílt forráskódú, ingyenesen elérhető eszközök. Ilyenek például a RapidMiner [2]a, a
KNIME [2]b, a Weka [2]c, vagy az R [2]d.
Az egyes vállalatok döntéseik megalapozása céljából döntéstámogató rendszereket alkalmaznak,
így könnyítve az optimum kiválasztásának problémáját. Napjaink trendjei szerint a vállalatok a
Business Intelligence (BI), azaz üzleti intelligencia rendszerrel valósítják meg döntéstámogató
rendszerüket. Az üzleti intelligencia az a folyamat, amely az adatot információvá, az elemzéssel
pedig tudássá transzformálja [3]a.
Az adatbányászat és az üzleti intelligencia térhódítása alatt az integráció problémájával is
szembesülnie kellett a vállalatoknak. A nyolcvanas, kilencvenes években a sok részleggel
rendelkező nagyvállalatok mind-mind különböző middleware1 megoldást alkalmaztak. Az
Enterprise Application Integration (EAI) fogalmával hivatkozunk a vállalat alkalmazásainak
integrációs igényére. Mindennek célja a folyamatok áramoltatása, a meglévő megoldások
újrahasznosítása, illetve az üzleti folyamatok átlátszóságának növelése [4]a.
Az EAI két fő problémát vet fel:
1. A vállalati információs rendszerek elosztott és heterogén részekből állnak.
2. Az integrációs logika karbantartása a változó igényeknek megfelelően.
A másik felmerülő probléma a Business to Business Integration (B2Bi) [4]a [9]b, azaz egy vállalat
üzleti folyamatainak kiterjesztése üzleti partnereire. Ez egy bonyolult feladat lehet, hiszen az egyes
vállalatok különböző rendszereket használhatnak, heterogén környezetet kialakítva ezzel.
A kezdeti próbálkozások, mint például a Message Broker Architecture [4]a, nem váltották be a
hozzájuk fűzött reményeket. A gyakorlat azt mutatta, hogy bár történt számos előrelépés,
1 Olyan szoftver, amely egy alkalmazás komponenseit képes összekapcsolni [9]a.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
2
ugyanakkor keletkeztek ebből adódó problémák is melyek hatására az eredeti problémák más
szinteken jelentkeztek.
Lehetséges megoldásként a Service Oriented Architecture (SOA), azaz szolgáltatásorientált
architektúrával álltak elő. A SOA célja, hogy a vállalat hatékonyságát és költséghatékonyságát úgy
növelje, hogy eközben az IT terheit a teljes szervezetben csökkenti. A SOA a rendszer minden
komponensére úgy tekint, mint szolgáltatásra. A szolgáltatások újrafelhasználhatóak, melyek értéke
növekedhet újabb szolgáltatások alkotásával. Szabványosítás útján egyszerűsíti az EAI és B2Bi
problémáját [4]a [10].
A két terület, a döntéstámogatás és a rendszerintegráció párhuzamosan fejlődtek az idők során, oda-
vissza hatva egymásra. Az egyes vállalati információs rendszerek hatékonyságában kulcsszerepet
játszik az integrációs problémák megfelelő feloldása, így az üzleti intelligencia megvalósítása
esetén is felkészültnek kell lennie a rendszer tervezőinek.
Diplomamunkám elkészítése két féléves feladat, melyből ez a dokumentáció az első félév alatt
elvégzett munkát és annak tapasztalatait rögzíti. Munkám adatbányászati algoritmusok
integrációjára összpontosít, de a megoldás kiterjeszthető az üzleti intelligencia többi egységére is,
illetve ezen túl más integrációs problémákra is. Célom, hogy egy olyan kész rendszert adjak, amely
segít a fejlesztőknek az alkalmazásfejlesztésben újrafelhasználható szolgáltatásai által,
hatékonyabbá teszi az információáramlást a végpontok között,
biztonságos kommunikációt tesz lehetővé átlátszó módon,
a lehető legtöbb környezetben használható és platformfüggetlen.
Mindezt a tudomány aktuális állásának követelményeit kielégítve.
A dokumentáció a következő struktúrát követi: a második fejezetben ismertetem a kutatási területen
belül fellelhető próbálkozásokat, tapasztalatokat. A harmadik fejezetben a rendszer tervezésének
menetét, döntéseit ismertetem és a tervezett rendszert mutatom be, majd a negyedik fejezetben a
rendszer aktuális implementációs állapotát írom le. Az összefoglalásban leírom az integrációs és
webszolgáltatások együttműködése témakörökben szerzett tapasztalataimat, illetve véleményemet.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
3
2. Irodalomkutatás
Ebben a fejezetben az integrációs problémát részletezem, és felsorolom az általam fellelt és múltbeli
próbálkozásokat, tapasztalatokat.
A [11] forrás egy asztali alkalmazást alakít át JAX-WS webszolgáltatást használó klienssé. A forrás
felismeri a webszolgáltatásokból adódó kliens-szerver megközelítés előnyeit, azaz hogy az
adatbányász eszközök nagy terhet jelentenek egy asztali számítógépnek. A forrás megemlíti a
folyamatkövetés problémáját, azaz hogyan tudjuk jelezni a kliensnek, hogy az általa meghívott
szolgáltatás feladatának hány százalékát teljesítette? Ez az információ valós igény lehet egy
adatbányász rendszerben, ahol nagyon gyakoriak az időigényes folyamatok. A folyamatkövetés
problémájára irodalomkutatásom során nem találtam megoldást Java webszolgáltatások esetében,
viszont .NET webszolgáltatások esetében találtam erre módszert.
A Weka4WS keretrendszer [2]e a Weka eszköztárát egészíti ki úgy, hogy az támogassa az elosztott
adatbányászatot GRID környezetben. Célja, hogy biztosítsa adatbányász algoritmusok távoli
elérését Web Service Resource Framework (WSRF) webszolgáltatásokkal. A WSRF egy sokat
kritizált szabvány, mivel korlátozott a kompatibilitása a WS-Interoperability specifikációknak
megfelelő webszolgáltatásokkal.
Az eddig felsorolt megoldásokhoz képest az általam tervezett rendszer a Metro technológiára épít,
amely az együttműködés lehető legmagasabb fokának biztosítása mellett gazdag eszköztárat kínál
webszolgáltatások fejlesztéséhez. A Metro által nyújtott lehetőségeket a következő fejezetben
mutatom be részletesen.
A Service Oriented Miner (SOMiner) [12] megoldás egy olyan rendszer, melynek segítségével a
felhasználó a tudásfeltárás folyamatának minden lépését végre tudja hajtani, mindezt SOA
környezetben, webszolgáltatások felhasználásán keresztül. Ez a megoldás nem von le
következtetéseket arról, hogy milyen technológiákkal, milyen szabványok használatával érdemes a
rendszert megvalósítani.
Irodalomkutatásom során nem találtam olyan forrást, amely platformfüggetlen, az együttműködésre
alkalmas technológiát használó rendszert dokumentál, amely az elemzési rendszer fejlesztését
segítő univerzális segédprogramokkal és funkciókkal szolgál. Ugyanakkor tisztán látszik egy
irányvonal, az adatbányászat területén belül is, amely az eszközöket, algoritmusokat
újrafelhasználható webszolgáltatásokként teszi elérhetővé. A fellelt irodalmak jól tükrözik, hogy
ahogy a vállalatokat elérte az üzleti intelligencia és a szolgáltatásorientált architektúra forradalma,
úgy az adatbányászat területére is hatással volt, mivel a BI piramis alkotóeleme az adatbányászat
[6]a.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
4
3. Szolgáltatásorientált megoldás tervezése
Ebben a fejezetben ismertetem a tervezés alatt meghozott döntések hátterét és az egyes
technológiák indoklásait.
3.1. Felhasznált technológiák és indoklásaik
Az adatbányász algoritmusok számításigényes mivolta miatt érdemes levenni a terhet az asztali
számítógépekről és központosítva, dedikált szerveren futtatni ezeket a hardverigényes számításokat.
Ennek következményeként egy olyan rendszert kell megvalósítani, amelyben a klienstől elválasztott
szolgáltatásokat átlátszó módon érhetjük el, és az együttműködés lehető legnagyobb szintjét kell
biztosítani.
Mi indokolja a webszolgáltatások használatát? Vállalati környezetben az integrációs problémák
általánosan elfogadott architektúrája a SOA, mely a rendszer minden komponensét szolgáltatásnak
tekinti. Mivel az általam választott architektúra a SOA, elkerülhetetlen a szolgáltatások használata.
A webszolgáltatások előnye, hogy az implementációt megváltoztathatjuk, továbbfejleszthetjük úgy,
hogy ez a kliens számára rejtett marad. A SOA integrációs problémákat szabványosítás útján
egyszerűsíti. A legfontosabb szabványok:
Simple Object Access Protocol (SOAP)
Általános, XML alapú üzenet protokoll, amely operációs rendszer, objektum modell,
programozási nyelv és architektúra független. A SOAP HTTP protokollt használ szállítási
protokollnak, és távoli eljáráshívást lehet megvalósítani vele.
Web Service Description Language (WSDL)
XML nyelvtan, amellyel a webszolgáltatásokat írhatjuk le. A WSDL kontraktus egy
publikus leírása a webszolgáltatásnak.
WS-* specifikációk, WS-Interoperability
A WS-* webszolgáltatásokkal kapcsolatos specifikációk gyűjteménye. Ezek közül egy a
WS-Interoperability, amely a webszolgáltatások együttműködésének irányelveit specifikálja
[4]b.
Az általam választott programozási platform a Java EE, ezen belül pedig a WS-I Basic Profile-nak
megfelelő keretrendszer a Metro [24]a, amelyet 2008 óta fejlesztenek a GlassFish projekt keretein
belül. A Metro egy nagyteljesítményű, kiterjeszthető, egyszerűen használható webszolgáltatás
’verem’. Verem alatt az értendő, hogy az alapértelmezett Java webszolgáltatásokon (JAX-WS) túl
olyan eszköztárat kínál, amellyel WS-* specifikációknak megfelelő tulajdonságokat
implementálhatunk. Ilyen tulajdonságok például a szállítás, a megbízható üzenetküldés, az atomi
tranzakciók és a biztonság.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
5
A Metro ezekkel az implementációkkal biztosítja a vállalati környezetben elengedhetetlen
webszolgáltatás technológiákat. A Metro által kínált fő szolgáltatások láthatóak az 1. ábrán.
1. ábra: A Metro által kínált fő szolgáltatások
A Metro-nak alrendszere a Web Service Interoperability Technologies (WSIT), amely számos
webszolgáltatás specifikáció implementációját tartalmazza. A Metro ezekkel az implementációkkal
támogatja a vállalati szintű webszolgáltatások együttműködésének megvalósítását. A Metro-t
folyamatosan fejlesztik és hangolják össze a .NET-beli Windows Communication Foundation-el
(WCF). A Metro jelenleg a .NET keretrendszer 3.5 verziójához biztosít teljes körű együttműködést.
A WSIT által biztosított szolgáltatások láthatóak a 2. ábrán.
2. ábra: A WSIT által megvalósított szolgáltatások
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
6
A dokumentáció írásakor a Metro verziószáma 2.1 és része a GlassFish Server Open Source Edition
3.1-es verziójának (a továbbiakban: GlassFish). Ezzel egy olyan alkalmazásszervert kapunk, amely:
platformfüggetlen;
nagy teljesítményű;
skálázható, klaszterezési lehetőségekben gazdag;
a Java EE robusztus programozási platformra épül;
alapértelmezetten tartalmazza a vállalati környezet integrációs problémái által igényelt,
webszolgáltatás specifikációkat támogató alkalmazásprogramozási interfészt (a
továbbiakban: API).
A Metro mellett az Axis2 [23] webszolgáltatás keretrendszert is vizsgáltam. A fellelt szakirodalom
[13] egyértelműen levonja a következtetést: a Metro jobb teljesítményt nyújt az Axis2-nél, ezért a
Metro mellett döntöttem. A felsorolt tulajdonságok mellett a GlassFish és a Metro megfelelt a
feladat elvárásainak, így ezeket a technológiákat felhasználva fogtam neki a rendszer tervezésének,
elkészítésének.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
7
3.2. A tervezett rendszer
A rendszer különböző alkalmazásokkal teszi hatékonyabbá a szolgáltatásorientált környezetet. Ezek
mind modulszerűek és az alkalmazásszerveren futnak, de a webszolgáltatásoktól függetlenül.
Fontos, hogy az alkalmazások lazán csatoltak legyenek, így ezzel szintén a szolgáltatásorientált
irányelvet követik, hiszen implementációjukat úgy változtathatjuk, hogy az őket használó többi
alkalmazásra ez nincs hatással. Ebben a fejezetben a teljes rendszer szerkezetén túl ezeket az
alkalmazásokat mutatom be tervezési szempontból.
A rendszer webszolgáltatásait gyakorlatilag bármilyen programozási nyelvből meg lehet hívni, ha a
kliens megfelel a WS-I Basic Profile-nak. Eszközök hiányában ez nehéz feladat, ezért érdemes
olyan keretrendszert használni, amely támogatja
A rendszerben a fejlesztők az egyes adatbányászati eszközök szolgáltatás szintű közzététele után
olyan klienseket írhatnak különböző programozási nyelveken, amelyek a szolgáltatásokat komplett
folyamatokba integrálják.
3. ábra: A tervezett rendszer
Egyes alkalmazásokban adattárolás céljából objektumorientált adatbázis implementációt használok.
Az objektumorientált adatbázis feladatának ellátására kiváló választás az ObjectDB [22], amely a
Java Persistence API-ra (JPA), azaz a Java objektum-relációs leképzés (ORM) megoldására épít. Az
ObjectDB a piacon található egyéb perzisztencia szolgáltatókhoz képest extrém teljesítményt nyújt
[15]a, emellett pedig egyszerűen használható. Az egyes API webszolgáltatásokhoz azért is ideális
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
8
választás az ObjectDB, mert egy fájlban tárolja az adatbázist, azaz egy API alkalmazáshoz egy
adatbázis fájl tartozik, amivel a szolgáltatás megtartja teljes függetlenségét és modulszerűségét.
3.2.1. Rendszerinformációs alkalmazás
A rendszerinformációs alkalmazás futási időben képes listázni az alkalmazásszerveren elérhető
webszolgáltatások információit. Ezek közül a legfontosabb a WSDL elérési útvonala és a
szolgáltatáson által elérhető műveletek listája. A rendszerinformációs alkalmazás a 3. ábrán látható
’Web service informations’ komponensnek felel meg.
A rendszerinformációs alkalmazás a Java Management Extensions (JMX) [16] segítségével
implementálható, amely a Java SE része. A JMX egy Java technológia, amely eszközökkel szolgál
Java alkalmazások, eszközök és szolgáltatás-vezérelt hálózatok kezeléséhez és felügyeletéhez. A
Metro alapú kliensek és szolgáltatásokba alapértelmezetten be van építve a JMX [24]b. A
monitorozáson keresztül megtekinthető a Metro futási rendszerének állapota. A fejlesztőnek
lehetősége van monitorozás céljából saját menedzselt objektumokat létrehozni és futási időben
ellenőrizni ezeket JMX-en keresztül.
Ez az alkalmazás a webszolgáltatások fejlesztőinek hasznos, akik az elérhető webszolgáltatások
listáját, és azok információit a GlassFish adminisztrációs felületének elérése nélkül tudják
megtekinteni, ugyanakkor az alkalmazás elhanyagolható terhelést jelent az alkalmazásszerverre
nézve.
3.2.2. Folyamatkövetés
Számításigényes műveletek esetén fontos, hogy a kliens értesítést kapjon a feladatból hátralevő
időről és arról, hogy a feladat mekkora részét sikerült elvégezni. Webszolgáltatások esetén
ismernünk kell kliensoldalon az adat küldésének, és fogadásának állapotán túl a hívás állapotát. Az
adatküldés állapotának követése SOAP kiterjesztéseken keresztül lehetséges [19].
Mivel a webszolgáltatások állapotmentesek, ezért készíteni kell egy folyamatkövető API-t. Az API
egy olyan Singleton, azaz egyke objektummal szolgál, amin keresztül az egyes szolgáltatáshívások
adminisztrálhatják állapotukat [4]c. Az egyke objektum azt jelenti, hogy az alkalmazás életciklusa
alatt csak egy példány jöhet létre belőle. Az alkalmazás saját adatbázisban tartja nyilván a
hívásokat, és állapotukat. A folyamatkövető alkalmazás a 3. ábrán látható ’Progress’ komponensnek
felel meg.
Az egyke objektum Java EE platformon Singleton EJB2 objektummal valósítható meg, amelyet
közzé lehet tenni az alkalmazásszerveren webszolgáltatás formájában. Az adatbányász
webszolgáltatás meghíváskor regisztrálja magát az egyke objektummal, és állapotváltozását is
jelenti. Így a kliens rögzített időközönként lekérheti a hozzá tartozó hívás állapotát annak
azonosítójával.
2 Enterprise JavaBeans (EJB): Java EE esetén az üzleti logikai réteget EJB komponensekben valósíthatjuk meg [8]a.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
9
Egy eseményvezérelt megközelítése a problémának, ha nem a kliens kéri le a hívás állapotát, hanem
a webszolgáltatás hívja meg vissza a klienst [21]. Ne feledjük, hogy a szolgáltatásorientált
architektúra minden komponensére szolgáltatásként tekint, így a kliensek is definiálhatunk olyan
metódust, aminek az állapotot átadva frissítjük a kliens oldalon megjelenített információkat. Ebben
az esetben az eseményvezéreltséget figyelembe véve az algoritmusokat minél több
újrafelhasználható metódusra kell bontani. Így a hívott metóduson belül automatikusan
regisztrációra kerülnek a végrehajtási folyamat szakaszai.
3.2.3. Biztonság
A Metro tizenhárom darab biztonsági mechanizmussal szolgál a webszolgáltatások védelmére
[24]c. Ezek egytől egyig a tudomány állásának megfelelő biztonsági megoldások. Az
irodalomkutatásból kiderült, hogy a biztonsági mechanizmusok közül a ’Transport Security (SSL)’
[24]d, azaz szállítási rétegben megvalósított biztonság, a védelem nélküli hívások teljesítményénél
alig produkál rosszabbat, ugyanakkor ez a többi megoldásról nem mondható el [14].
A szállítási rétegben megvalósított biztonság védett HTTP kapcsolatra épül, amelyet a Secure
Sockets Layer (SSL) kriptográfiai protokoll segítségével valósít meg. A szállítási rétegben
megvalósított biztonság egy pont-pont összeköttetésen alapuló biztonsági mechanizmus, amellyel
az azonosítás, az adatintegritás3 és a bizalmasság
4 tulajdonság implementálható. A védelem
használatához digitális tanúsítvány használatára van szükség.
A szállítási rétegben megvalósított biztonság élettartama a forrás elhagyásától a fogyasztó oldalán
történő megérkezésig szól, így egyik problémája, hogy a szállított adat nem védett miután elérte a
célt. Ez a probléma megoldható olyan biztonsági mechanizmussal, amely SSL-t használ, de az
üzenet szintjén is védi az adatot. A végleges döntés meghozása csak konkrét igények ismeretében
lehetséges.
3.2.4. Nagy adathalmazok fogadásának képessége
Metro webszolgáltatások esetén a SOAP Message Transmission Optimization Mechanism (MTOM)
nevű eljárással tudjuk megvalósítani bináris mellékletek üzenetekhez csatolását [24]f. Az MTOM-
mal átküldhető maximális adatméret nem definiált, a szerver kapacitása határozza meg. Az MTOM
a bináris csatolmányt többrészes MIME5 üzenetbe csomagolja, azaz ugyanazt a mechanizmust
használja, amelyet e-mail üzenetek mellékletei esetén alkalmaznak.
Alapértelmezetten az MTOM pufferelt módban végzi az adatok küldését, a különböző adattípusok
Base64 kódolásával. A Base64 kódolás 33%-kal növeli a küldendő adat méretét, ami nagy, több
gigabájtos adathalmaz küldésekor elfogadhatatlan. Pufferelt módban a küldendő, illetve fogadott
adat teljes egésze bekerül a memóriába, nagy adathalmaz küldésekor kerülendő a kiszolgáló
terheltségének csökkentése érdekében.
3 A sértetlenség követelménye azt rögzíti, hogy egy adott információt vagy rendszert csak az arra jogosultak változtat-
hatnak meg [5]a.
4 A bizalmasság követelménye azt rögzíti, hogy egy adott információt csak az arra jogosultak tudhatnak meg [5]a.
5 Multipurpose Internet Mail Extensions: multimédia mail kiterjesztés [7]a.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
10
Az MTOM-mal lehetőség van streaming-re, ami az adatot folyamként továbbítja. A streaming
megoldást jelent az előbb felsorolt problémákra, mivel a küldendő adat méretét nem növeli, és
automatikusan eldönti, hogy rendelkezésre áll-e elég erőforrás a memóriában való tárolásra, azaz ha
nem szükséges nem fér hozzá a fájlrendszerhez [20] [24]g.
3.2.5. Intelligens adattár
A rendszer felhasználói adathalmazaikat távolról tölthetik fel. Nagy adathalmazok esetén kezelni
kell az újraküldés esetét, és implementálni kell egy tároló API-t, melyet a webszolgáltatások egy
egyke objektumon keresztül érnek el. Az egyke objektum a feltöltött fájlokhoz CRC326 kódot
készít, az információkat pedig objektum adatbázisban tartja nyilván. Kliens oldalon szükség van
egy olyan metódusra, amely a küldendő adathalmaz CRC32 kódját ki tudja számolni. Az intelligens
adattár alkalmazás a 3. ábrán látható ’Cache’ komponensnek felel meg.
Bár egyértelműen lehetőség van adatforrás szerepét betöltő adatbázis csatlakoztatására, csak a
tárgyalt módszerrel foglalkoztam mivel a két irány közötti döntés csak a konkrét igények
ismeretében hozható meg. A cache használata előnyös, mivel csökkenti a hálózati linkek
terheltségét, ami vállalati környezetben fontos a költséghatékony működéshez.
3.2.6. Folyamatok létrehozása
Az egyes webszolgáltatásokat a klienseknek folyamatba kell tudni foglalni. Tanulmányaim szerint
[4]a ennek elsődleges ipari szabványa a Business Process Execution Language (BPEL), amellyel
XML alapon írhatjuk le az üzleti folyamatokat. A BPEL folyamatok nagy előnye, hogy akár
webszolgáltatásként is meghívhatjuk őket, ezzel kiválóan illeszkedik a szolgáltatásorientált
környezethez.
A rendszer együttműködő képességéből adódik, hogy egy folyamatba különböző programozási
nyelveken írt webszolgáltatások is foglalhatók. Ez viszont felveti a kérdést, hogy a
webszolgáltatások adatbemenetére milyen megszorítás, illetve formátum vonatkozik. Ugyanakkor
ennek a kérdésnek a megválaszolásához konkrét igények ismerete szükséges.
6 32 bites ciklikus redundancia kód, amelyet az adat megváltozásának észlelésére használhatunk.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
11
4. Implementációs állapot
Ebben a fejezetben bemutatom a rendszer dokumentációjának készítésekor aktuális implementációs
állapotot. Egy egyszerű k legközelebbi szomszéd algoritmust [6]b valósítottam meg, mint Metro
webszolgáltatást. A tervezett funkciók közül a webszolgáltatáshoz az MTOM adatküldést és a
rendszerinformációs alkalmazást készítettem el. A webszolgáltatás eléréséhez a .NET keretrendszer
3.5 verziójában C# nyelven implementáltam WCF klienst. A biztonsági mechanizmusok közül a
’Message Authentication over SSL’-t [24]e valósítottam meg, amely abban különbözik a ’Transport
Security (SSL)’ eljárástól, hogy csak az azonosításra használ védelmet.
A .NET környezethez Visual Studio 2010 Professional fejlesztői környezetet használtam, a Java
platformon történő fejlesztést pedig a NetBeans 6.9.1 fejlesztői környezetben végeztem.
4.1. A webszolgáltatás implementációja
A NetBeans fejlesztői környezet kiváló eszközöket és támogatást nyújt a fejlesztőnek Metro
webszolgáltatások fejlesztéséhez.
4. ábra: A Metro webszolgáltatás konfigurálásának lehetőségei NetBeans-ben
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
12
A NetBeans fejlesztői környezetben új webszolgáltatást a projekten az egér jobb gombjával
kattintva, a ’New’ helyi menü ’Web Service’ opciójával hozhatunk létre. A webszolgáltatás
különböző tulajdonságainak beállítását végezhetjük a webszolgáltatáson az egér jobb gombjával
kattintva, és az ’Edit Web Service Attributes’ opciót kiválasztva. Lásd 4. ábra.
A teszt céljából készített adatbányász webszolgáltatás k legközelebbi szomszéd algoritmust valósít
meg, melynek egy adathalmazt átadva, abból egy véletlenszerűen választott egyedhez megkeresi öt
legközelebbi szomszédját euklideszi távolság alapján. A webszolgáltatásnak az adathalmazt
MTOM-on keresztül küldhetjük.
Biztonság
A ’Message Authentication over SSL’ biztonsági mechanizmus beállítását a webszolgáltatás ’Edit
Web Service Attributes’ panelén végezhetjük. A ’Use Development Defaults’ opció kiválasztásával
a webszolgáltatás a GlassFish alapértelmezett, fejlesztéshez használható tanúsítványát fogja
használni. Lásd 4. ábra.
Nagy adathalmazok fogadásának képessége
Az MTOM beállításához első lépésként a webszolgáltatás ’Edit Web Service Attributes’ panelén be
kell kapcsolni az ’Optimize Transfer Of Binary Data (MTOM)’ opciót, majd pedig a
webszolgáltatás osztályát kell ellátni az @MTOM és @StreamingAttachment annotációkkal. A
@StreamingAttachment annotáció engedélyezi a streaming lehetőségét a webszolgáltatásra.
Lásd 5. ábra.
5. ábra: MTOM és streaming engedélyezése a webszolgáltatáson
Annak webszolgáltatás metódusnak, amellyel MTOM használatával kívánunk bináris csatolmányt
adatfolyamként fogadni, szignatúrájában fel kell tüntetni az
@XmlMimeType("application/octet-stream") annotációval ellátott DataHandler
data paramétert. Lásd 6. ábra.
6. ábra: Webszolgáltatás metódus, amely a bináris csatolmányt adatfolyamként képes fogadni
Ezzel a beállítással a metódus képes fogadni pufferelt módban és streaming módban küldött adatot
is. A data paraméterrel kapott adatot nekünk kell eredeti formájára hoznunk. Erre a feladatra a
WSUtil segédosztály getSourceFromHandler(DataHandler data) metódusát hoztam
létre, amely a data paraméter típusa alapján eldönti, hogy pufferelt vagy streaming módban
érkezett-e az adat, majd ennek megfelelően adja vissza az adathalmazt.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
13
4.2. A rendszerinformációs alkalmazás implementációja
A rendszerinformációk egy Java webalkalmazáson keresztül érhetők el. Ez az alkalmazás JMX-szet
használ a webszolgáltatások információinak lekérésére. A Metro-ban alapértelmezetten be van
kapcsolva a monitorozás funkció. A webszolgáltatások információit a WSEndpoint menedzselt
objektumon keresztül érhetjük el, amelyet a Metro automatikusan regisztrál.
Fejlesztéskor a Java Monitoring & Management Console (JConsole) alkalmazást használtam a
regisztrált menedzselt objektumok, illetve webszolgáltatás információk megtekintésére. A JConsole
alapértelmezett részét képezi a Java Development Kit-nek (JDK). A JConsole grafikus felülete,
illetve ez által megjelenített webszolgáltatás információk láthatók a 7. ábrán.
7. ábra: A JConsole-ból elérhető információk
Ha a saját Java alkalmazásunkból szeretnénk elérni a regisztrált menedzselt objektumokat, akkor
referenciát kell kérnünk egy MBeanServer példányra, amit a
ManagementFactory.getPlatformMBeanServer() függvény meghívásával tehetünk
meg [17].
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
14
Fontos, hogy az egyes webszolgáltatásokhoz tartozó menedzselt objektumok az Appserver
Management Extensions (AMX) tartományon belül találhatók, és az AMX az alkalmazásszerver
indulásakor nem kerül inicializálásra. Az AMX kézi inicializálásához meg kell hívnunk az amx-
support tartományban található boot-amx menedzselt objektum bootAMX függvényét. A
bootAMX metódus meghívását végző utasítás látható a 8. ábrán.
8. ábra: Az AMX manuális inicializálása
A rendszerinformációs alkalmazás JMXQueryBean objektuma az AMX inicializálása után
összegyűjti az alkalmazásszerveren futó webszolgáltatások információit úgy, mint a webszolgáltatás
nevét és WSDL kontraktusának elérését. A JMXQueryBean-ből egy példány jön létre a
rendszerinformációs alkalmazás életciklusa alatt, és minden kérést ez szolgál ki, ezzel csökkentve
az alkalmazás lábnyomát. Korábbi munkám során már tárgyaltam a megközelítés előnyeit [1]d.
Az egyes webszolgáltatások által nyújtott műveletek listája JMX-szen keresztül közvetlenül nem
elérhető, de a webszolgáltatás WSDL kontraktusából ezek kiolvashatóak. A kontraktus tartalmának
kiolvasására és manipulálására használható a WSDL4J könyvtár [18]. A 9. ábrán látható az így
kapott információk megjelenítése a rendszerinformációs alkalmazás főoldalán.
9. ábra: A rendszerinformációs alkalmazásban elérhető információk
Az alkalmazás képes megjeleníteni a szolgáltatás WSDL kontraktusát a böngészőben. Ez a funkció
akkor lehet hasznos, ha a böngésző nem támogatja az XML fájlok megjelenítését. Lásd 10. ábra.
10. ábra: WSDL kontraktus megtekintése a rendszerinformációs alkalmazással
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
15
4.3. A .NET kliens implementációja
A Visual Studio 2010 fejlesztői környezetben szolgáltatás referenciát (ServiceReference)
tudunk létrehozni a webszolgáltatás eléréshez. Erre a fejlesztői környezet az svcutil.exe eszközt
használja, amely a webszolgáltatás WSDL kontraktusa alapján létrehozza az eléréshez szükséges
proxy osztályt és ennek konfigurációját. A proxy osztályt példányosítva a webszolgáltatás elérésére
alkalmas objektumot kapunk. Lásd 11. ábra.
11. ábra: ServiceReference létrehozása .NET-ben
Alapértelmezetten a biztonsági megszorítások miatt előfordulhat, hogy a GlassFish alapértelmezett
tanúsítványát érvénytelennek tekinti a .NET keretrendszer. Ezt az ellenőrzést kizárólag fejlesztéskor
kerülhetjük ki, ha az érvényesítést úgy állítjuk be, hogy minden tanúsítványt elfogadjon. Lásd 12.
ábra.
12. ábra: A tanúsítvány érvényesítésének kikerülése (a fejlesztés céljából).
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
16
A proxy osztályból létrehozott példány ClientCredentials adattagjában be kell állítani a
webszolgáltatás eléréséhez szükséges felhasználónevet és jelszót. A GlassFish által használt
alapértelmezett felhasználónév ’wsitUser’, a jelszó pedig ’changeIt’.
Az úgynevezett adathalász oldalak elkerülése végett a kliens ellenőrzi a tanúsítványban feltüntetett
kiszolgáló identitást és a tényleges kiszolgáló identitást. Ha a két érték nem egyezik meg, a kliens
megszakítja a kapcsolatot. Fejlesztéskor megadhatjuk a célkiszolgáló identitását manuálisan a
kliens konfigurációs fájljában (app.config). Lásd 13. ábra.
13. ábra: A célkiszolgáló identitásának kézi megadása
Az elvégzett beállítások után meghívható az adatbányász webszolgáltatás. Lásd 14. ábra.
14. ábra: A .NET kliens megjeleníti a Metro webszolgáltatástól kapott választ
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
17
5. Összefoglalás
Első feladatom az volt, hogy megvizsgáljam milyen módon lehetséges az egyes adatbányászati
szoftvercsomagok integrációja a különböző programozási nyelvekben. A megvizsgált alternatívák
közül a webszolgáltatások útján történő integrációt választottam, amely következményeképp
szolgáltatásorientált architektúrára alapoztam a rendszert. Ez a rendszer csak a WS-I
specifikációknak megfelelő, együttműködni képes webszolgáltatásokat tudja fogadni.
A második feladat olyan szerver és kliens komponens megvalósítása volt, amely az inhomogén
környezet részeit transzparens módon integrálja. Munkám során tesztelési célból készítettem egy
Java webszolgáltatást, amely egy egyszerű k legközelebbi szomszéd algoritmus távoli, transzparens
és biztonságos elérését teszi lehetővé. A Java webszolgáltatás távoli elérését .NET 3.5
keretrendszerben, C# nyelven írt asztali kliensalkalmazással valósítottam meg. Kipróbáltam egy, a
Metro által kínált biztonsági mechanizmust. A tervezett, végleges biztonsági mechanizmus a
szállítási rétegben megvalósított biztonság, amelyet a diplomamunka második félévében fogok
megvalósítani.
Harmadik feladatom a szerverkomponens által nyújtott API megtervezése, illetve a kliens és
szerveroldalon használt objektumhierarchia összehangolása volt. A tervezett rendszerben az egyes
webszolgáltatások metódusai, és a rendszerinformációs webalkalmazás adják az API-t. Az
webszolgáltatásoknak küldhető több gigabájtos adathalmaz is, az MTOM bináris adatküldés
megoldásnak köszönhetően. Így ebben a rendszerben – mivel adathalmazok küldéséről van szó – az
objektumhierarchia összehangolása helyett elég megegyezni a küldött adat formátumáról.
Véleményem szerint a webszolgáltatások együttműködése olyan terület, amely a következő
években továbbra is fejlődni fog. Úgy gondolom, hogy az ESB nélküli szolgáltatásorientált
architektúrák felé fog konvergálni a terület, viszont ennek eléréséhez rögös út vezet a WS-I
konzorcium nagyvállalatainak eltérő érdekei miatt. Ezzel párhuzamosan tovább nő az egyes WS-I
specifikációk, illetve az ezeket támogató fejlesztőeszközök száma.
Nehéznek találtam az együttműködés összehangolását a különböző biztonsági mechanizmusok
esetén, amit a dokumentáció hiányosságai, és a példaprogramok hiánya indokol. A megfelelő
dokumentáció elkészítése nehéz feladat a WCF, illetve METRO készítőire nézve, hiszen rengeteg
lehetőséget kell lefedni, így a fejlesztő nem mindig találja meg azt, ami a saját igényeinek megfelel.
Bár elmondható, hogy az egyes technológiák külön-külön jól dokumentáltak, nehezen találni olyan
irodalmakat, ami az egyes biztonsági mechanizmusok megvalósításait írja le úgy, hogy az
együttműködés van fókuszban. Ezeket a hiányosságokat munkám során egyensúlyozta, hogy az
egyes szakmai közösségi oldalakon kaptam specifikusan a problémámra segítséget.
Előfordult, hogy adott biztonsági mechanizmusokhoz a WCF nem volt képes megfelelő kliens
proxy osztályt, illetve konfigurációs fájlt generálni. Ez mutatja, hogy a két platform technológiái
még mindig összehangolás alatt állnak. Véleményem szerint a WS-I megtanulása azért nehéz és
időigényes folyamat, mert a fejlesztőnek meg kell értenie, hogy csak specifikációkat, irányelveket
kap, az ő feladata pedig hogy ezek szerint készítse az implementációt.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
18
Jelen dokumentáció által tárgyalt rendszer felhasználását olyan, főként vállalati környezetekbe
ajánlom, ahol számításigényes feladatokat ellátó webszolgáltatásokra van igény, különböző
platformokon alapuló rendszerek mellett. Mivel a meglévő rendszer olyan szolgáltatásait, amelyek
nem felelnek meg a WS-I specifikációknak, nehéz, és költséges lehet együttműködővé tenni,
munkámat új rendszerek létrehozásakor, vagy a meglévő lecserélésekor lehet felhasználni. Bár a
dokumentáció kifejezetten adatbányászati algoritmusokra specializálja a rendszert, ettől eltekintve
alkalmas más területek problémáinak feloldására, hiszen a biztonság, teljesítmény, skálázhatóság,
platformfüggetlenség nem egyedi igények napjainkban.
Ebben az integrációs témakörben végzett munkámban felhasználtam a korábbi mester szintű
tanulmányaim alatt megszerzett tudást; a tantárgyak közül az Információs rendszerek szolgáltatás
biztonsága, Adat- és tudásbázis rendszerek és Információs rendszerek fejlesztése és modellezése
tárgyak hallgatása során megszerzett tudás segített abban, hogy ezt a rendszert meg tudjam tervezni
a modern szoftvertechnológia elvárásainak megfelelően. Az integráció témaköre sok területet érint,
véleményem szerint egy ilyen jellegű rendszer tervezéséhez több területről származó szaktudást kell
felhasználni, ezt tükrözi a felsorolt tantárgyak száma.
A komplett, működő rendszer implementációja, elemzése és dokumentációja a diplomamunka
második félévében kerül elvégzésre. Azaz a tervezett, de még nem implementált funkciókat fogom
elkészíteni, így a diplomamunka második részében készülő dokumentáció a kész rendszert fogja
magába foglalni. Továbbra is megpróbálok ötletekkel előállni a rendszerinformációs alkalmazás
gazdagítása érdekében, hiszen ez egy alapalkalmazás azok számára, akik a rendszert használva
webszolgáltatásokat fejlesztenek. A rendszert mindig a korral haladva, a legkorszerűbb eszközökkel
fogom fejleszteni, és ha lehetőségem lesz rá, kiaknázom a JavaEE 7-ben rejlő lehetőségeket,
amelyet 2012 negyedik negyedévében fognak kiadni [15]b.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
19
Irodalomjegyzék
Források utolsó megtekintésének és ellenőrzésének dátuma: 2011. május 13.
[1] Korábbi munkák
a. Szalay Dániel: JAXB architektúra megvalósítása az ECWINS rendszerben.
Önálló labor, 2008. december 5.
b. Szalay Dániel: JavaServer Faces felhasználói felület az ECWINS rendszer Thermal
moduljához. Önálló labor, 2009. május 25.
c. Szalay Dániel: Integrated JavaServer Faces Interface for the ECWINS System. Integrált
JavaServer Faces interfész az ECWINS rendszerhez. Szakdolgozat, 2009. december 5.
d. Szalay Dániel: ECWINS webalkalmazás optimalizálása.
Önálló labor, 2010. augusztus 27.
e. Szalay Dániel: CRUD generálás JSF 2.0 technológiával.
Önálló labor, 2010. december 3.
[2] Nyílt forráskódú adatbányászati eszközök
a. http://rapid-i.com/content/view/181/196/
RapidMiner
b. http://www.knime.org/
KNIME
c. http://www.cs.waikato.ac.nz/ml/weka/
Weka
d. http://www.r-project.org/
R
e. http://grid.deis.unical.it/weka4ws/
Weka4WS
[3] Adatbányászat tantárgy
a. Kardkovács Zsolt Tivadar Adatbányászat című előadás
[4] Információs rendszerek fejlesztése és modellezése tantárgy
a. Bruno Wassermann: Business Process Execution Language előadás.
b. Albert István: Web szolgáltatások című előadás
c. Asztalos Márk: Tervezési minták című előadás..
[5] Információs rendszerek szolgáltatás biztonsága tantárgy
a. Bacsárdi László: Kockázatelemzés című előadás. 2010. február 16.
[6] Adat- és tudásbázis rendszerek tantárgy
a. Edelényi Márton: Bevezetés című előadás.
b. Edelényi Márton: Osztályozási algoritmusok című előadás.
[7] Számítógépes hálózatok tantárgy
a. Dr. Farkas Károly, Ph.D.: 2. fejezet: Alkalmazási réteg.
[8] Szoftvertechnikák és architektúrák tantárgy
a. Dr. Takách Géza: Java EE bevezetés című előadás.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
20
[9] Fogalmak
a. http://it.toolbox.com/wiki/index.php/Middleware
Middleware definíciója
b. http://it.toolbox.com/wiki/index.php/B2B_Integration
Business to Business Integration definíciója
[10] Thomas Erl: SOA Design Patterns. SOA tervezési minták. 2009.
[11] Sujala.D.Shetty, S.Vadivel, Sakshi Vaghella: Weka Based Desktop Data Mining as
WebService. Weka alapú asztali adatbányászat webszolgáltatás használatával. 2010.
[12] Derya Birant: Service-Oriented Data Mining. Szolgáltatásorientált adatbányászat. 2011.
[13] Dennis Sosnoski: Java Web services: Metro vs. Axis2 performance. Java webszolgáltatások:
Metro és Axis2 webszolgáltatás keretrendszerek teljesítményének összehasonlítása. 2010.
[14] Dennis Sosnoski: Java web services: The high cost of (WS-)Security. Java webszolgáltatások:
A (WS-)biztonság magas költsége. 2009.
[15] DZone Javalobby szakmai weboldal
a. http://java.dzone.com/articles/new-jpa-performance-benchmark
New JPA Performance Benchmark. Új JPA teljesítmény összehasonlítás. 2010.
b. http://java.dzone.com/articles/java-ee-7-%E2%80%93-i-have-few-dreams
Java EE 7 – I have a (few) dream(s). Java EE 7 helyzetjelentés.
[16] http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html
Java Management Extensions (JMX) Technology
[17] http://download.oracle.com/javase/6/docs/technotes/guides/jmx/overview/agent.html
Java SE documentation, Chapter 4: Using JMX Agents. Java SE dokumentáció negyedik
fejezet: JMX ügyfelek használata.
[18] http://sourceforge.net/projects/wsdl4j/
Web Services Description Language for Java Toolkit (WSDL4J)
[19] http://msdn.microsoft.com/en-us/library/aa480520.aspx
Adding a Progress Bar to Your Web Service Client Application. Folyamatkijelző funkció
hozzáadása a webszolgáltatás kliens alkalmazásához.
[20] http://msdn.microsoft.com/en-us/library/ms733742(v=VS.90).aspx
Large Data and Streaming, Large Data Content. Nagy adathalmazok és küldésük
adatfolyamként, Nagyméretű adat fejezet.
[21] http://www.infoq.com/articles/BI-and-SOA
Bridging the gap between BI & SOA. A BI és a SOA közötti nehézségek áthidalása.
[22] http://www.objectdb.com/
ObjectDB Java alapú objektumorientált adatbázis.
[23] http://axis.apache.org/axis2/java/core/
Axis2 webszolgáltatás keretrendszer
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
21
[24] Metro felhasználói kézikönyv – http://metro.java.net/guide/
a. http://metro.java.net/discover/
What is Metro? Mi az a Metro?
b. http://metro.java.net/guide/Introduction_to_Metro_JMX_Monitoring.html
19.1. Introduction to Metro JMX Monitoring. A Metro JMX monitorozás
lehetőségeinek bemutatása.
c. http://metro.java.net/guide/Security_Mechanisms.html
12.3. Security Mechanisms. Biztonsági mechanizmusok.
d. http://metro.java.net/guide/Security_Mechanisms.html#ahicx
12.3.5. Transport Security (SSL). Szállítási rétegben megvalósított biztonság (SSL)
e. http://metro.java.net/guide/Security_Mechanisms.html#ahicz
12.3.6. Message Authentication over SSL. Üzenet azonosítás SSL-en keresztül.
f. http://metro.java.net/guide/Binary_Attachments__MTOM_.html
6.2. Binary Attachments (MTOM). Bináris csatolmányok (MTOM).
g. http://metro.java.net/guide/Large_Attachments.html
6.3. Large Attachments. Nagy csatolmányok.
Diplomamunka 1. – Szalay Dániel
Adatbányászati algoritmusok integrációja szolgáltatásorientált architektúrában
22
Ábrajegyzék
1. ÁBRA: A METRO ÁLTAL KÍNÁLT FŐ SZOLGÁLTATÁSOK ................................................................................................... 5
2. ÁBRA: A WSIT ÁLTAL MEGVALÓSÍTOTT SZOLGÁLTATÁSOK ........................................................................................... 5
3. ÁBRA: A TERVEZETT RENDSZER ....................................................................................................................................... 7
4. ÁBRA: A METRO WEBSZOLGÁLTATÁS KONFIGURÁLÁSÁNAK LEHETŐSÉGEI NETBEANS-BEN ......................................... 11
5. ÁBRA: MTOM ÉS STREAMING ENGEDÉLYEZÉSE A WEBSZOLGÁLTATÁSON .................................................................... 12
6. ÁBRA: WEBSZOLGÁLTATÁS METÓDUS, AMELY A BINÁRIS CSATOLMÁNYT ADATFOLYAMKÉNT KÉPES FOGADNI ........... 12
7. ÁBRA: A JCONSOLE-BÓL ELÉRHETŐ INFORMÁCIÓK ....................................................................................................... 13
8. ÁBRA: AZ AMX MANUÁLIS INICIALIZÁLÁSA ................................................................................................................. 14
9. ÁBRA: A RENDSZERINFORMÁCIÓS ALKALMAZÁSBAN ELÉRHETŐ INFORMÁCIÓK ............................................................ 14
10. ÁBRA: WSDL KONTRAKTUS MEGTEKINTÉSE A RENDSZERINFORMÁCIÓS ALKALMAZÁSSAL ........................................ 14
11. ÁBRA: SERVICEREFERENCE LÉTREHOZÁSA .NET-BEN ................................................................................................. 15
12. ÁBRA: A TANÚSÍTVÁNY ÉRVÉNYESÍTÉSÉNEK KIKERÜLÉSE (A FEJLESZTÉS CÉLJÁBÓL). ................................................ 15
13. ÁBRA: A CÉLKISZOLGÁLÓ IDENTITÁSÁNAK KÉZI MEGADÁSA ...................................................................................... 16
14. ÁBRA: A .NET KLIENS MEGJELENÍTI A METRO WEBSZOLGÁLTATÁSTÓL KAPOTT VÁLASZT ......................................... 16