Adatbányászati algoritmusok integrációja ...documento.inf.nyme.hu/sites/default/files/SZALAYD... · Az adatbányászat az új, jelentéstartalommal bíró összefüggések, minták,

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



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.



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.



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.



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.



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



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.



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



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.



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.



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.



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



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.



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].



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



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).



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



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.



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.



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.

http://rapid-i.com/content/view/181/196/

http://www.knime.org/

http://www.cs.waikato.ac.nz/ml/weka/

http://www.r-project.org/

http://grid.deis.unical.it/weka4ws/



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

http://it.toolbox.com/wiki/index.php/Middleware

http://it.toolbox.com/wiki/index.php/B2B_Integration

http://java.dzone.com/articles/new-jpa-performance-benchmark

http://java.dzone.com/articles/java-ee-7-%E2%80%93-i-have-few-dreams

http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html

http://download.oracle.com/javase/6/docs/technotes/guides/jmx/overview/agent.html

http://sourceforge.net/projects/wsdl4j/

http://msdn.microsoft.com/en-us/library/aa480520.aspx

http://msdn.microsoft.com/en-us/library/ms733742(v=VS.90).aspx

http://www.infoq.com/articles/BI-and-SOA

http://www.objectdb.com/

http://axis.apache.org/axis2/java/core/



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.

http://metro.java.net/guide/

http://metro.java.net/discover/

http://metro.java.net/guide/Introduction_to_Metro_JMX_Monitoring.html

http://metro.java.net/guide/Security_Mechanisms.html

http://metro.java.net/guide/Security_Mechanisms.html#ahicx

http://metro.java.net/guide/Security_Mechanisms.html#ahicz

http://metro.java.net/guide/Binary_Attachments__MTOM_.html

http://metro.java.net/guide/Large_Attachments.html



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

Documents

Adatbányászati algoritmusok integrációja ...documento.inf.nyme.hu/sites/default/files/SZALAYD... · Az adatbányászat az új, jelentéstartalommal bíró összefüggések, minták,