SOA KERETRENDSZEREK ÖSSZEHASONLÍTÓ

BME IK

SOA KERETRENDSZEREK ÖSSZEHASONLÍTÓ ELEMZÉSE

E-közigazgatás keretrendszer kialakítása

1

BME IK

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer” tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett:


2

BME IK

Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description)

Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás SOA keretrendszerek összehasonlító elemzése Az e-közigazgatás informatikai rendszerének alapjául szolgáló SOA keretrendszerek. A dokumentum a szolgáltató állam által a közeljövıben kialakítandó ügyfélközpontú és ügyfélbarát elektronikus közigazgatási szolgáltatások megvalósításához szükséges informatikai rendszer alapjául szolgáló – neves szállítók által készített, a piacon elérhetı – keretrendszerek összehasonlító vizsgálatának eredményeit összegzi és mutatja be.; eközigazgatási pilot projektek szöveg . . Magyarország e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal BME Informatikai Központ, KOPINT-DATORG Zrt . 2008. MS Word . HU V2 Végleges EKK_ekozig_SOA_keretrend_osszehas_elemzes_081209_V2 . . .


3

BME IK

Verziókövetési táblázat A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

SOA keretrendszerek összehasonlító elemzése BME IK, Kopint-Datorg

2009.09.21. V2 108 EK3

Változáskezelés Verzió V1 V2

Dátum 2008.07.30 2009.09.21.

A változás leírása Annotált tartalomjegyzék végleges


4

BME IK

Szövegsablon Megnevezés 1. Elıszó (Foreword)

2. Bevezetés (Preamble)

3. Alkalmazási terület (Scope) 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia 8. Rövidítésgyőjtemény 9. Fogalomtár 10. Ábrák 11. Képek 12. Fogalmak 13. Verzió 14. Mellékletek (Appendix)

Leírás Az „E-közigazgatási keretrendszer kialakítása” projekt egyes feladatainak magalapozott kidolgozásához kísérleti módszerekre is szükség van, továbbá a kidolgozott javaslatok, módszerek, eljárások, eszközök értékeléséhez a gyakorlati alkalmazások során is tapasztalatokat kell szerezni. Ennek érdekében indítunk e-közigazgatási pilot projekteket. Az indítandó pilot projekteknek két típusa van: a) Kísérleti rendszer és tesztágy kialakítása, amelyik lehetıséget ad aa) különbözı gyártók SOA rendszereinek vizsgálatára, ab) web-service szabványoknak való megfelelések vizsgálatára, ac) együttmőködési tesztek végrehajtására, ad) fejlesztési technológiák, módszerek gyakorlati, laboratóriumi jellegő kipróbálására és demonstrálására, b) Fejlesztési pilot projektek a nagy alrendszereken, amelyek célja: ba) néhány nagy alrendszeren minta-szolgáltatások kialakítása az architektúrára, a közigazgatási szolgáltatási sínre, valamint a fejlesztési módszerre és keretrendszerre tett javaslat tesztelésére és validálására, bb) a kulcsszereplık (Kopint-Datorg, KEKKH, PM-ISZK, stb.) aktív részvételének biztosítása a sikeres e-közigazgatási integráció megoldásában. Jelen dokumentum az aa) ponthoz kapcsolódik, összefoglalja a vizsgálat eredményeit. A dokumentum a szolgáltató állam által a közeljövıben kialakítandó ügyfélközpontú és ügyfélbarát elektronikus közigazgatási szolgáltatások megvalósításához szükséges informatikai rendszer alapjául szolgáló – neves szállítók által készített, a piacon elérhetı – keretrendszerek összehasonlító vizsgálatának eredményeit összegzi és mutatja be. Elektronikus közigazgatás


5

BME IK

Tartalomjegyzék 1. 2. 3. 4. 5.

Vezetıi összefoglaló ..................................................................................................................................... 10 Bevezetés ...................................................................................................................................................... 11 Definíciók, fogalmak, rövidítések................................................................................................................. 12 SOA integrációs koncepció........................................................................................................................... 14 SOA keretrendszerek általában ..................................................................................................................... 15 5.1. A SOA keretrendszerek helye a szolgáltatás orientált architektúrában.............................................. 15 5.2. A SOA keretrendszerekkel szemben támasztott elvárások ................................................................ 15 5.2.1. Életciklus....................................................................................................................................... 15 5.2.2. Modellezés .................................................................................................................................... 15 5.2.3. Felépítés ........................................................................................................................................ 16 5.2.4. Megvalósítás ................................................................................................................................. 16 5.2.5. Felügyelet...................................................................................................................................... 17 5.2.6. Szolgáltatások ............................................................................................................................... 17 5.2.6.1. Interakciós szolgáltatások .................................................................................................... 17 5.2.6.2. Folyamatszolgáltatások........................................................................................................ 18 5.2.6.3. Üzleti alkalmazásszolgáltatások .......................................................................................... 18 5.2.6.4. Információs szolgáltatások .................................................................................................. 19 5.2.6.5. Elérési szolgáltatások........................................................................................................... 19 5.2.6.6. Partnerszolgáltatások ........................................................................................................... 19 5.2.6.7. Szolgáltatásmenedzsment .................................................................................................... 19 6. Jelentıs SOA keretrendszer szállítók és termékeik....................................................................................... 21 6.1. HP Magyarország............................................................................................................................... 21 6.1.1. SOA technológiai modell (blokk diagram) ................................................................................... 21 6.1.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 21 6.1.3. Szolgáltatás publikáció módjai...................................................................................................... 21 6.1.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 21 6.1.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 22 6.1.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 22 6.1.6.1.1. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard... 22 6.1.7. Fejlesztı rendszer,......................................................................................................................... 22 6.1.8. xml / soap /wdsl specifikumok...................................................................................................... 22 6.1.9. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)................. 22 6.1.10. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.)........................................................ 22 6.1.11. skálázhatóság / üzembiztonsági elemek / redundancia.................................................................. 22 6.1.12. Kommunikációs modell ismertetése (blokk diagram)................................................................... 22 6.1.13. Szolgáltatás tárak meghajtási módja ............................................................................................. 23 6.1.14. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 23 6.1.15. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 23 6.1.16. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat)................................................................................................................. 23 6.1.17. Támogatott hitelesség ellenırzési módszerek ............................................................................... 23 6.1.18. Támogatott elektronikus fizetési módok ....................................................................................... 23 6.1.19. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 23 6.1.20. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek).................................. 24 6.2. IBM Magyarország ............................................................................................................................ 24 6.2.1. SOA technológiai modell (blokk diagram) ................................................................................... 24 6.2.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 25 6.2.3. Szolgáltatás publikáció módjai...................................................................................................... 25 6.2.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 25 6.2.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 25 6.2.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 25


6

BME IK

6.2.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard ........................ 25 6.2.8. Fejlesztı rendszer.......................................................................................................................... 26 6.2.9. xml / soap /wdsl specifikumok...................................................................................................... 26 6.2.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)................. 26 6.2.11. Workflow programozhatósága (nyelvek, BPEL, JAVA, stb.)....................................................... 26 6.2.12. skálázhatóság / üzembiztonsági elemek / redundancia.................................................................. 26 6.2.13. Kommunikációs modell ismertetése (blokk diagram)................................................................... 26 6.2.14. Szolgáltatás tárak meghajtási módja ............................................................................................. 27 6.2.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 27 6.2.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 27 6.2.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat)................................................................................................................. 27 6.2.18. Támogatott hitelesség ellenırzési módszerek ............................................................................... 28 6.2.19. Támogatott elektronikus fizetési módok ....................................................................................... 28 6.2.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 28 6.2.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) ......................................... 28 6.3. MICROSOFT Magyarország ............................................................................................................. 29 6.3.1. SOA technológiai modell (blokk diagram) ................................................................................... 29 6.3.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 30 6.3.3. Szolgáltatás publikáció módjai...................................................................................................... 30 6.3.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 31 6.3.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 31 6.3.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 32 6.3.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard ........................ 32 6.3.8. Fejlesztırendszer........................................................................................................................... 33 6.3.9. xml / soap /wdsl specifikumok...................................................................................................... 33 6.3.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)................. 33 6.3.11. Workflow programozhatósága (nyelvek, BPEL, JAVA, stb.)....................................................... 34 6.3.12. Skálázhatóság / üzembiztonsági elemek / redundancia ................................................................. 34 6.3.13. Kommunikációs modell ismertetése (blokk diagram)................................................................... 35 6.3.14. Szolgáltatás tárak meghajtási módja ............................................................................................. 35 6.3.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 36 6.3.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 37 6.3.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) .................................................................................................................. 37 6.3.18. Támogatott hitelesség ellenırzési módszerek ............................................................................... 38 6.3.19. Támogatott elektronikus fizetési módok ....................................................................................... 38 6.3.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 39 6.3.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) ......................................... 39 6.4. ORACLE Magyarország.................................................................................................................... 40 6.4.1. SOA technológiai modell (blokk diagram) ................................................................................... 40 6.4.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 40 6.4.3. Szolgáltatás publikáció módjai...................................................................................................... 41 6.4.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 42 6.4.4.1. Oracle ESB .......................................................................................................................... 42 6.4.4.2. Az Oracle BPEL Process Manager ...................................................................................... 44 6.4.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 45 6.4.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 46 6.4.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard ........................ 47 6.4.8. Feljesztı rendszer.......................................................................................................................... 47 6.4.9. xml / soap /wsdl specifikumok...................................................................................................... 47 6.4.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek .................. 48 6.4.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.)........................................................ 49 6.4.12. Skálázhatóság / üzembiztonsági elemek / redundancia ................................................................. 49 6.4.13. Kommunikációs modell ismertetése (blokk diagram)................................................................... 49 6.4.14. Szolgáltatás tárak meghajtási módja ............................................................................................. 50


7

BME IK

6.4.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 50 6.4.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 52 6.4.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) .................................................................................................................. 52 6.4.18. Támogatott hitelesség ellenırzési módszerek ............................................................................... 53 6.4.19. Támogatott elektronikus fizetési módok ....................................................................................... 53 6.4.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 53 6.4.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) ......................................... 54 6.5. RED HAT / JBoss (képviseli: ULX Kft.) .......................................................................................... 54 6.5.1. SOA technológiai modell (blokk diagram) ................................................................................... 54 6.5.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 55 6.5.3. Szolgáltatás publikáció módjai...................................................................................................... 55 6.5.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 55 6.5.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 55 6.5.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 55 6.5.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard ........................ 55 6.5.8. Fejlesztı rendszer.......................................................................................................................... 55 6.5.9. xml / soap / wsdl specifikumok..................................................................................................... 55 6.5.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)................. 56 6.5.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.)........................................................ 56 6.5.12. Skálázhatóság / üzembiztonsági elemek / redundancia ................................................................. 56 6.5.13. Kommunikációs modell ismertetése (blokk diagram)................................................................... 56 6.5.14. Szolgáltatás tárak meghajtási módja ............................................................................................. 57 6.5.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 57 6.5.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 57 6.5.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat)................................................................................................................. 57 6.5.18. Támogatott hitelesség ellenırzési módszerek ............................................................................... 57 6.5.19. Támogatott elektronikus fizetési módok ....................................................................................... 57 6.5.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 57 6.5.21. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek).................................. 57 6.6. SUN Microsystems Magyarország .................................................................................................... 58 6.6.1. SOA technológiai modell (blokk diagram) ................................................................................... 58 6.6.2. Többszörözött szolgáltatás tárak létrehozása ................................................................................ 60 6.6.3. Szolgáltatás publikáció módjai...................................................................................................... 60 6.6.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése............................................ 61 6.6.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) ...................................... 62 6.6.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) ............................................ 63 6.6.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard ........................ 65 6.6.8. Fejlesztı rendszer.......................................................................................................................... 65 6.6.9. xml / soap /wdsl specifikumok...................................................................................................... 65 6.6.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)................. 66 6.6.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.)........................................................ 66 6.6.12. Skálázhatóság / üzembiztonsági elemek / redundancia ................................................................. 67 6.6.13. Kommunikációs modell ismertetése (blokk diagram)................................................................... 67 6.6.14. Szolgáltatás tárak meghajtási módja ............................................................................................. 68 6.6.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) ............................................................................................... 68 6.6.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása........................................................ 68 6.6.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) .................................................................................................................. 68 6.6.18. Támogatott hitelesség ellenırzési módszerek ............................................................................... 69 6.6.19. Támogatott elektronikus fizetési módok ....................................................................................... 69 6.6.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek).......... 69 6.6.21. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek).................................. 69 7. Vizsgálati környezetek és részletes eredmények........................................................................................... 70


8

BME IK

7.1. Tesztágy elsı változata ...................................................................................................................... 70 7.1.1. Architektura................................................................................................................................... 70 7.1.1.1. Ügyfél, Ügyintézı................................................................................................................ 71 7.1.1.2. Ügyfélkapu .......................................................................................................................... 71 7.1.1.3. Cégbíróság ........................................................................................................................... 72 7.1.1.4. Apeh .................................................................................................................................... 72 7.1.1.5. Igazságügy ........................................................................................................................... 73 7.1.1.6. Központ ............................................................................................................................... 73 7.1.2. EVA áttérési folyamat................................................................................................................... 73 7.1.3. Biztonság....................................................................................................................................... 74 7.1.4. Tapasztalatok és eredmények........................................................................................................ 75 7.1.4.1. Megoldott problémák........................................................................................................... 75 7.1.4.2. Hatékonysági mérések ......................................................................................................... 76 7.2. Tesztágy második változata ............................................................................................................... 77 7.2.1. A tesztelt keretrendszerek ............................................................................................................. 77 7.2.2. Tesztfeladatok ............................................................................................................................... 78 7.2.2.1. Számológép ......................................................................................................................... 78 7.2.2.2. MTOM kódolás ................................................................................................................... 79 7.2.2.3. Banki szolgáltatás ................................................................................................................ 80 7.2.2.4. Aszinkron hívás ................................................................................................................... 81 7.2.3. Tesztelı keretprogram................................................................................................................... 81 7.2.4. Tesztelési eredmények .................................................................................................................. 82 7.2.4.1. WsHttp SOAP 1.1................................................................................................................ 83 7.2.4.2. WsHttp SOAP 1.2................................................................................................................ 84 7.2.4.3. WsHttps SOAP 1.2 .............................................................................................................. 85 7.2.4.4. WsAddr 1.0 SOAP 1.1......................................................................................................... 86 7.2.4.5. WsAddr 2004 SOAP 1.1...................................................................................................... 87 7.2.4.6. WsAddr 1.0 SOAP 1.2......................................................................................................... 88 7.2.4.7. WsRm SOAP 1.2 ................................................................................................................. 89 7.2.4.8. WsSc SOAP 1.2................................................................................................................... 90 7.2.4.9. WsFault SOAP 1.2............................................................................................................... 91 7.2.4.10. WsMtom SOAP 1.1 ............................................................................................................. 92 7.2.4.11. WsMtom SOAP 1.2 ............................................................................................................. 93 7.2.4.12. WsBank SOAP 1.1 .............................................................................................................. 94 7.2.4.13. WsBank SOAP 1.2 .............................................................................................................. 95 7.2.4.14. WsAt SOAP 1.1................................................................................................................... 96 7.2.4.15. WsAt SOAP 1.2................................................................................................................... 97 7.2.4.16. WsAsync SOAP 1.1............................................................................................................. 98 7.2.4.17. WsAsync SOAP 1.2............................................................................................................. 99 8. Vizsgálati eredmények összesítése.............................................................................................................. 100 8.1. Vizsgálati szempontok alapján készült összesítés............................................................................ 100 8.2. A keretrendszerek együttmőködésének összefoglalása.................................................................... 103 8.3. A keretrendszerek konfigurációinak megfeleltetése egymással....................................................... 104 9. SOA keretrendszerek az e-Közigazgatásban............................................................................................... 106 9.1. HP .................................................................................................................................................... 106 9.2. IBM.................................................................................................................................................. 106 9.3. Oracle............................................................................................................................................... 107 10. Útmutató további SOA keretrendszerek vizsgálatához ........................................................................... 108


9

BME IK

1. Vezetıi összefoglaló Az „E-közigazgatási pilot projektek” alprojekt célja, hogy az EKOP projektek számára kidolgozott és javasolt integrációs elveket és módszereket kísérletekkel is alátámassza és megvalósíthatóságukat igazolja. Végrehajtása a következı fı feladatokat ölelte fel: ― Tesztágy: Létrehoztunk egy laboratóriumi kísérleti rendszert, amelyik tesztágyként szolgál SOA rendszerek funkcionális, konformancia, interoperabilitási és fejlesztés-módszertani vizsgálataihoz. ― KR-pilot: A központi rendszerre és további nagy alrendszerekre kiterjedı pilot-projektet terveztünk meg és hajtottunk végre egy több alrendszert érintı folyamat (anyasági támogatás igénylése) laboratóriumi rendszeren létrehozott szolgáltatási sínre és a KOPINT ügyfélkapujára és hivatali kapujára alapozott megvalósításával. ― Tanulmány: A kísérletek eredményeit is felhasználva összehasonlító tanulmányt készítünk a megvizsgált SOA rendszerekrıl. ― MKA-v1 és MKSZS-v1: A kísérletek tapasztalatai alapján kidolgozzuk az „Alkalmazásfejlesztési keretrendszer kidolgozása” alprojekt keretében elkészített két kulcsdokumentum, a „Magyar eKözigazgatási Architektúra” és a „Magyar Közigazgatási Szolgáltatási Sín” második változatát (v1). A Konzorciumi tagok közül az alprojektben a BME IK és a Kopint-Datorg vett részt. A munka során irodalmi áttekintés és korábbi tapasztalatok alapján kiválasztottunk néhány SOA-rendszert, felállítottuk a tesztágy elsı változatát, és kísérleti rendszert építettünk. Az eredményekre alapozva elkészítettük a tesztágy továbbfejlesztett változatát. Kidolgoztunk egy tesztsorozatot, amely alkalmas a keretrendszerek interoperabilitási képességének tesztelésére, és a különbözı WS-* szabványoknak való megfelelés vizsgálatára. Elvégeztük a választott keretrendszerek együttmőködésének vizsgálatát. A KR-pilot megvalósítása során felvetıdı problémák megoldásához szükséges kísérletek elvégzéséhez is a tesztágyat használtuk. Jelen Tanulmány célja, hogy kísérleti vizsgálatokkal is alátámasztott összefoglalót és összehasonlító elemzést adjon a beszerezhetı SOA keretrendszerekrıl és azok együttmőködési képességeirıl. Ezzel segíteni kívánja a döntéshozókat a feladatokhoz és a fejlesztési körülményekhez leginkább igazodó termékek és megoldások kiválasztásában. Elkészítése során kidolgozzuk az összehasonlítás szempontrendszerét, az értékelés dimenzióit. A vizsgálatba bevont SOA rendszereket a dokumentációkból származó, a szakirodalmi, és a kísérleti adatok alapján ezen szempontrendszer szerint hasonlítjuk össze. Kísérletekkel igazolni tudjuk, hogy http-n a keretrendszerek képesek együttmőködni. A ma elérhetı megvalósítások különbözı WS-* szabványok szintjén történı együttmőködése még nem hibamentes, alkalmanként nehézkes. A termékek folyamatos és gyors változása pozitív fejlemény, a konvergencia irányába mutat.


10

BME IK

2. Bevezetés Jelen Tanulmány célja, hogy kísérleti vizsgálatokkal is alátámasztott összefoglalót és összehasonlító elemzést adjon a beszerezhetı SOA keretrendszerekrıl és azok együttmőködési képességeirıl. Ezzel segíteni kívánja a döntéshozókat a feladatokhoz és a fejlesztési körülményekhez leginkább igazodó termékek és megoldások kiválasztásában. Elkészítése során kidolgoztuk az összehasonlítás szempontrendszerét, az értékelés dimenzióit. A vizsgálatba bevont SOA rendszereket a dokumentációkból származó, a szakirodalmi, és a kísérleti adatok alapján ezen szempontrendszer szerint hasonlítottuk össze. A Tanulmány elsıként a SOA keretrendszerekkel szemben manapság támasztható elvárásokat fogalmazza meg. Ezt követi a jelentıs szállítók (pl: HP, IBM, SUN, MS stb.) piacon is elérhetı termékeinek összehasonlítása. A Kopint szakértıi a keretrendszerrel kapcsolatos elvárások alapján kérdıívet szerkesztettek, amelyekre választ kértek a fontos piaci szereplıktıl. A beérkezett válaszok és anyagok alapján – egységes szempontok szerinti, de szóródó mélységő – képet kapunk arról, hogy a gyártók mit állítanak a maguk készítette keretrendszerekrıl. A következıkben bemutatjuk a tesztágy különbözı változatait, és röviden vázoljuk a különbözı gyártók konkrét termékein elvégzett konkrét kísérletek lényegét. Az interoperabilitási vizsgálatok eredményeit részletes, táblázatos formában összegezzük. A Tanulmány végül összefoglalja a tapasztalatokat és a további lépésekre tesz javaslatot.


11

BME IK

3. Definíciók, fogalmak, rövidítések 2PC API BPEL BPEL4WS BPML CORBA EJB EPR HTTP HTTPS IIS IBM JavaEE JAXB JAX-RPC JAX-WS JDBC JMS JNDI KPI LRT MEP MIME MTOM OMG QoS RAD RMI RPC SAAJ SCA

Two Phase Commit, kétfázisú commit protokoll Application Programming Interface, alkalmazás programozási interfész Business Process Execution Language, üzleti folyamatok szabványos leírása BPEL for Web Services, a BPEL specifikáció hivatalos elnevezése Business Process Modeling Language, folyamatok platformfüggetlen leírására kidolgozott jelölınyelv Common Object Request Broker Architecture, platformfüggetlen távoli eljáráshívás protokoll Enterprise Java Bean, az üzleti logikai réteg objektuma Java környezetben EndPoint Reference, webszolgáltatások végpontjainak szállítási rétegtıl független leírása HyperText Transfer Protocol, elsıdlegesen weboldalak továbbítására kidolgozott szállítási protokoll HTTP over SSL, HTTP üzenetek titkosított csatornán történı továbbítása Internet Information Services, a Microsoft web- és alkalmazásszervere International Business Machines, informatikai óriásvállalat Java Enterprise Edition, a Java API alkalmazáskiszolgáló-specifikus szolgáltatásokkal bıvített változata Java Architecture for XML Binding, Java adattípusok XML elemekre való leképzését és sorosítását definiáló API Java API for XML-based RPC, a JavaEE 1.4 webszolgáltatás API-ja Java API for XML-based Web Services, a JavaEE 5 webszolgáltatás API-ja Java DataBase Connectivity, adatbázisok egységes kezelését biztosító API Java Message Service, üzenetkezelést támogató API Java Naming and Directory Interface, erıforrások elnevezését és név szerinti keresését támogató API Key Performance Indicator, alapvetı teljesítményjellemzı, kulcsmérıszám Long-Running Transaction, hosszú lefolyású tranzakció Message Exchange Pattern, üzenetváltási minta Multipurpose Internet Mail Extensions, kezdetben e-mail üzenetek tartalmának típusa jelzésére használt kiterjesztés Message Transmisson Optimization Mechanism, nagymérető bináris adatok optimális továbbítását leíró szabvány Object Management Group, szabványosítási szervezet Quality of Service, szolgáltatásminıség Rational Application Developer, az IBM által készített fejlesztıkörnyezet Remote Method Invocation, szabványos távoli eljáráshívás protokoll a Java platformra Remote Procedure Call, távoli eljáráshívás, továbbá egy korai protokoll annak megvalósítására SOAP with Attachments API for Java, üzenet-orientált webszolgáltatás API Service Component Architecture, szolgáltatás-összetevı architektúra


12

BME IK

SOA SOAP SPI SSL STS TLS URI WAS WCF WF WID WPS WSDL WSFL WSFP XA XML XLANG XOP

Service Oriented Architecture, szolgáltatás-orientált architektúra Simple Object Access Protocol, webszolgáltatások üzenetformátumát leíró szabvány System Programming Interface, rendszer programozási interfész Secure Sockets Layer, biztonságos kommunikációt biztosító protokoll Security Token Service, biztonsági tokeneket kibocsátó webszolgáltatás Transport Level Security, biztonságos kommunikációt biztosító protokoll Universal Resource Identifier, az interneten használt címformátum Websphere Application Server, az IBM által fejlesztett alkalmazáskiszolgáló Windows Communication Foundation, a Microsoft .NET 3.0-ban bemutatkozó webszolgáltatás API Windows Workflow Foundation, a Microsoft .NET 3.0-ban bemutatkozó folyamatleíró API Websphere Integration Developer, az IBM fejlesztıkörnyezete üzleti folyamatok számára Websphere Process Server, az IBM üzleti folyamat kiszolgálója Web Service Description Language, webszolgáltatások interfész leíró nyelve Web Services Flow Language, az IBM által kidolgozott folyamatleíró nyelv Web Services Feature Pack, az IBM webszolgáltatás keretrendszerét tartalmazó kiegészítı csomag Egységes interfész elosztott tranzakciók kezelésére eXtensible Markup Language, platformfüggetlen, hierarchikus szervezéső jelölınyelv A Microsoft által kidolgozott struktúrált folyamatleíró nyelv XML-binary Optimized Packaging, bináris adatok XML formátumban történı optimális tárolását leíró szabvány


13

BME IK

4. SOA integrációs koncepció A szolgáltatás-orientált architektúra (Service Oriented Architecture, SOA) napjaink leggyorsabban terjedı informatikai infrastruktúra tervezési elve. Fı célkitőzése a lazán csatolt rendszerek kialakítása nagyvállalati és globális környezetben egyaránt. Az OASIS referencia modellje [1] szerint a SOA egy paradigma különbözı érdekeltségek hatáskörében álló elosztott erıforrások és képességek szervezésére és hasznosítására. Definiálja az erıforrások és képességek egységes módon történı felkínálását, felderítését, együttmőködését és felhasználását annak érdekében, hogy ellenırizhetı elıfeltételeknek és elvárásoknak megfelelı eredményt, hatást érjünk el. A SOA központi fogalma a szolgáltatás. Hétköznapi értelemben a szolgáltatás egy szereplı által egy másik szereplı számára végrehajtott munkát jelenti. Alaposabban elemezve a szolgáltatás a következıket is magában foglalja: ― képesség más számára való munkavégzésre ― a végrehajtandó munkatevékenység leírása ― hajlandóság a munka végrehajtására és ennek felkínálása Ez az absztrakt megközelítés a funkcionalitásra helyezi a hangsúlyt, ellentétben az objektumorientált szemlélettel, ahol az adat és a rajta végezhetı mőveletek szorosan összekapcsolódnak. A legáltalánosabb definíció szerint a SOA nem más, mint egymással kommunikáló szolgáltatások csoportja. A webszolgáltatások tökéletesen illenek a SOA koncepciójába. A platformfüggetlenségnek köszönhetıen tetszıleges funkciót webszolgáltatássá lehet alakítani, azok interfészeinek és üzeneteinek szabványos leírása pedig biztosítja, hogy egy szolgáltatást anélkül lehessen használni, hogy a hívónak bármilyen tudomása legyen az implementáció részleteirıl, a futtató környezetrıl vagy akár a fizikai elhelyezkedésrıl, ami minimálisra csökkenti a komponensek közti csatolás mértékét. A szolgáltatás-orientált architektúra koncepciója arra épül, hogy az egyes szolgáltatások felhasználásával összetett mőveletek állíthatók össze, melyek önmaguk is egy-egy szolgáltatásként jelennek meg. Az üzleti folyamatok, különös tekintettel a BPEL folyamatokra egyenesen ezt az elvet követik.


14

BME IK

5. SOA keretrendszerek általában 5.1.

A SOA keretrendszerek helye a szolgáltatás orientált architektúrában

Mivel a SOA egy absztrakt tervezési paradigma, egy IT architektúra, amelyet a gyakorlatban egyebek között a webszolgáltatások és az üzleti folyamatok alkalmazásával lehet megvalósítani, ezért szükséges azon szoftvereszközök képességeinek feltérképezése, melyek ezen két technológia valamelyikét kínálják. Nem csak technológiáról szól azonban a SOA; fontos építı elemei még az alábbiak. ― az eszközök és metodológiák, amelyek az üzleti, kormányzati, közigazgatási mőködési mintákat képesek rögzíteni ― az eszközök, a SOA programozási modell és technikák, amelyek az implementáció során használhatóak ― a middleware infrastruktúra, amely biztosítja az implementáció hatékonyságát ― a folyamatos kontroll, amely a SOA teljes életciklusa során segíti a megvalósítást.

5.2.

A SOA keretrendszerekkel szemben támasztott elvárások

A mindennapi gyakorlatban elérhetı keretrendszerek képességei, az általuk nyújtott szolgáltatások jelentısen szórnak. A különbségek ellenére – talán ma még nem követelmény jelleggel – megfogalmazhatók azok az elvárások, amelyeket a felhasználók támasztanak a keretrendszerekkel szemben. Jelen fejezetben kerülnek ismertetésre mindazon tényezık, amelyeket, vagy amelyeknek módszeres támogatását a különbözı SOA keretrendszerekben részben vagy teljes mértékben megvalósították, illetıleg a megvalósítása elvárható. 5.2.1. Életciklus A SOA megvalósítását alapvetıen több szakaszra lehet bontani: ezek alkotják a SOA életciklusát. A ciklus a modellezéssel indul, majd ennek eredményei kerülnek át az információs rendszer tervezésén keresztül a megvalósítási fázisba. Az üzemeltetés fázisban a megvalósítás eredményességét mérjük, majd az eredményeinket a modell finomítására felhasználva visszacsatolunk az elsı fázis felé, akár több iterációs körben is. Valamennyi fázist átfogó kontroll irányít, amely biztosítja, hogy a felhasználói elvárásoknak megfelelı és megfelelıen mőködı rendszer készüljön, illetve, hogy csak az üzleti, kormányzati, közigazgatási irányelveknek megfelelı változások legyenek csak végrehajthatók a rendszereken. 5.2.2. Modellezés A modellezés során elsıdleges feladatunk mőködési modell rögzítése, az üzleti, kormányzati, közigazgatási követelmények feltérképezése és dokumentálása, ezek megfelelı üzleti, kormányzati, közigazgatási folyamatokként történı reprezentálása. A modellezés eredményeinek rögzítése egyszerőbb esetben történhet egy megfelelı szöveges dokumentum


15

BME IK

és/vagy valamilyen eszközben elkészített folyamatábra segítségével. A modellezés fázisa a dokumentációs célokon túlmenıen a folyamatok vizsgálatát, elemzését és szükség szerint finomítását is szolgálja. Ehhez megfelelı elemzı-szimulációs eszköz használata javasolt, amely a folyamatok „lerajzolásán” túl azok próbapadszerő mérését, szimulációját is képes elvégezni. A szimuláció, amely az egyes lépésekhez a már a modell szintjén definiálható idı, erıforrás és más paraméterek felhasználásával kimutathatja az esetleges szők keresztmetszeteket, ahol szükséges lehet a beavatkozás, a folyamat módosítása. Szintén a modellezés fázisának a feladata azoknak a mérıszámoknak a rögzítése, amelyek késıbbi mérése láttatja a konkrét, implementált folyamatok valós viselkedésének minıségét. Ezeket a mérıszámokat KPI-knek (key performance indicator) nevezzük. 5.2.3. Felépítés A felépítés fázisa kezdi meg az elızı fázisban kialakított modell eredményeinek átformálását a konkrét IT implementációban használható formába. Itt történik meg a folyamat egyes lépéseiben, az azok végrehajtásához szükséges szolgáltatások és a folyamat megfelelı pontjának logikai (és szolgáltatás-hívás szint) összekapcsolása. Ennek a lépésnek az elvégzéséhez kialakításra kell kerülniük a késıbb felhasználható szolgáltatásoknak. Ez történhet a meglévı alkalmazások kínálta, szemantikailag megfelelı funkciók megfelelı illesztıfelülettel történı ellátásával („becsomagolásával”), amennyiben azok képesek a kormányzati, közigazgatási elvárások szerint megfogalmazott funkcionalitás biztosítására. Az eddigi implementációktól függıen, megfelelı adapterekkel a legacy alkalmazások is illeszthetık. A meglévı, az elvárásoknak nem, vagy nem pontosan megfelelı mőködéső komponensek esetében a funkciók SOA elvek szerinti (újra)fejlesztett verzióinak létrehozása lehet szükséges. Természetesen lesznek olyan szolgáltatások is, amelyek a frissen kialakítandó rendszer részeként ekkor kerülnek implementálásra. Bármelyik fenti módszert használjuk is fel, elı kell állítani a szabványos felülettel rendelkezı szolgáltatások tárházát, hiszen ezeknek a hivatkozásaival kerülnek a felépítés fázisban összeállításra a SOA alapú folyamataink. 5.2.4. Megvalósítás A megvalósítás fázisának kettıs feladata van: egyrészt kialakítja a futtatókörnyezetet az elkészült alkalmazások és folyamatok számára, másrészt gondoskodik ezek tényleges telepítésérıl és beüzemelésérıl. Ide értendık a kapacitás-követelményekkel kapcsolatos kérdések, valamint a biztonsági kérdések (pl. hozzáférés-kontroll) megoldása is. A futtatókörnyezet feladatai is szerteágazók. Biztosítani kell a különbözı részterületek megfelelı támogatását, így – természetesen a kormányzati, közigazgatási folyamatok operatív környezetén túl – a felhasználói interakciós logika, a különbözı üzleti, kormányzati, közigazgatási szolgáltatások, (legacy) alkalmazás-elérési szolgáltatások, ill. adatlogika runtime környezete is meg kell valósuljon. A megvalósítás fázisában kell kialakítani azokat a feltételeket, amelyek garantálják a SOA környezet megfelelı rendelkezésre állását, megbízhatóságát, integritását, performanciáját, stb.


16

BME IK

5.2.5. Felügyelet A SOA életciklus menedzsment fázisába fordulva azokat a szempontokat kell figyelembe venni, hogy hogyan mőködtethetı a korábban felállított futtatókörnyezet. A klasszikus rendszerfelügyeleti tevékenységeken túl (pl. hálózat-, szerver- és alkalmazás-menedzsment, naplófájlok elemzése, stb.) belépnek olyan tevékenységek, amelyek kifejezetten a SOA rendszerek specifikus viselkedését hivatottak megfigyelni. Így megoldandó a szolgáltatáshívások és –kiszolgálás teljesítményparamétereinek, a válaszidıknek a folyamatos megfigyelése. A menedzsment másik rétege a kormányzati, közigazgatási modell felügyeletét jelenti. Amennyiben a kormányzati, közigazgatási elvárásoknak megfelelı mőködés megkívánja, a futtatókörnyezet hangolása, módosítása is szükségessé válhat. Azt, hogy a pillanatnyi mőködés mennyiben teljesíti az elvárásokat, a modellezés fázisában definiált KPI (key performance indicator) metrikák monitorozásával dönthetı el. A modellezett és azután megvalósított folyamataink kormányzati, közigazgatási szakmai monitoringját is el kell tehát végezzük, és ezek azok a valós mérési eredmények, amelyeket a modellezés fázisba visszaemelve elvégezhetjük kormányzati, közigazgatási modellünk finomítását. Az ún. BPM ciklus (business process management) itt zárul tehát. Az egyes életciklus-fázisok közötti átmenet nem biztos, hogy a fenti sorrendet követi, egyes esetekben más sorrendő elırehaladás is elképzelhetı. A KPI mérıszámok változtatása például a modellezési fázisból azonnal a felügyeleti fázisba kerül átemelésre, ahol ezek tényleges monitorozása történik. Hasonlóan, a megvalósítási fázis kötöttségei (pl. az erıforrások elhelyezkedése) befolyással lehet a felépítés fázis tevékenységeire. 5.2.6. Szolgáltatások 5.2.6.1.

Interakciós szolgáltatások

Az interakciós szolgáltatások adják a rendszereink prezentációs logikáját, biztosítják a kapcsolatot az alkalmazások és a felhasználók között (felhasználó persze adott esetben nem csak humán közremőködı lehet, az ilyen speciális esetek kezelése szintén e blokk feladata). Fontos jellemzıje e blokknak, hogy az interakció gyakorisága, módja, csatornája és felhasználói kontextusa (szerepkör), preferenciái, elhelyezkedése, stb. alapján képes a megjelenített információ megfelelı szőrésére, a megjelenítés hangolására, esetleg a nyelvi környezet váltásával is. Gondoskodik arról, hogy a különbözı kliensek (pl. böngészı, kézi eszköz, mobil eszköz) számára, a nekik értelmezhetı formában juttassa el a különbözı tartalmakat. Az interakciós szolgáltatások réteg az elıbb ismertetett információ-megosztási funkciókon túl egyben képes kollaborációs (csevegés, jelenlét-érzékelés) feladatok ellátására a felhasználók között, ezzel segítve a felhasználók közötti információáramlást.


17

BME IK

5.2.6.2.

Folyamatszolgáltatások

A folyamat szolgáltatások feladata, hogy az architektúra további komponenseinek (Üzleti1 alkalmazásszolgáltatások, Partnerszolgáltatások, vagy az Elérési szolgáltatások segítségével az architektúrába bekapcsolt gyári alkalmazások) mőködését az üzleti, kormányzati, közigazgatási stb. folyamatok igényei szerint koreografálják. A folyamat szolgáltatások ennek érdekében többféle kompozíciós logikát is megvalósíthatnak. Ezek közül a két legfontosabb az üzleti, kormányzati, közigazgatási stb. folyamatok és az ún. "üzleti állapotgépek" támogatása, de emellett lehetıvé teszik üzleti szabályok, vagy döntési fák feldolgozását is. Az üzleti, kormányzati, közigazgatási stb. folyamatok megvalósítása - mint e blokk kiemelt célja - mellett könnyő belátni, hogy az állapotgépek használata milyen elınyökkel jár. Folyamataink, amelyek modellezését, majd implementációját végezzük, valószínőleg nem változnak olyan gyakorisággal, mint azok a paraméterek, amelyek egy-egy elágazás irányát, vagy egy-egy döntés kimenetelét meghatározzák (pl. külsı feltételek, amelyek dinamikusan változó összeghatártól függnek, vagy gyakori változású feltételeket figyelı ellenırzések). Az üzleti folyamat absztrakció fontos eleme lehet tehát az üzleti állapotgép, amely a folyamattól függetlenül definiált és kezelt üzleti, kormányzati, közigazgatási szabályok alapján teszi az üzleti logikát finomhangolhatóvá. Ez láthatóan megint egy dekompozíciós szint, amikor magát az üzleti folyamatot leválasztjuk az üzleti szabályainkról, tesszük ezt éppen a nagyobb rugalmasság és a könnyebb menedzselhetıség kedvéért. A szabályokat tartalmazó táblázat karbantartása azután nem az üzleti logika programozását végzı munkatárs feladata, hanem egy erre feljogosított üzleti adminisztrátoré lehet. A folyamat szolgáltatások blokk biztosítja annak funkcionális infrastruktúráját is, hogy a modellünkben definiált kulcsmérıszámok (KPI) monitorozhatók legyenek. 5.2.6.3.

Üzleti alkalmazásszolgáltatások

Feladata a központi üzleti, kormányzati, közigazgatási logika implementálása. Ezek olyan szolgáltatás-komponensek, amelyek az üzleti, kormányzati, közigazgatási modellben megfogalmazott szolgáltatásokként kerülnek létrehozásra. Olyan szolgáltatások, amelyek nem dekomponálhatók tovább a modellnek megfelelıen, ugyanakkor magasabb szint (összetett, más néven kompozit) szolgáltatások felépítésére felhasználhatók. Ezek a szolgáltatások jellemzıen az üzleti folyamatainkban kerülnek hivatkozásra és hívásra, de elképzelhetı, hogy közvetlenül az interakciós szolgáltatások prezentációs logikája hívja meg ıket.

1

Beleértendı: kormányzati, közigazgatási stb.


18

BME IK

5.2.6.4.

Információs szolgáltatások

A kormányzati, közigazgatási mőködést támogató adatlogikát valósítja meg. A felszínen tekintve elérést biztosít az üzleti perzisztens adatok felé. Ezek az adatok jellemzıen elosztott környezetben, különbözı módon, és formátumban tárolva vannak jelen – különbözı relációs és más adatbázisokban, fájlrendszerekben, XML tárakban, stb. Fontos szolgáltatás tehát ebben a blokkban az ún. federáció, amely egységes logikai nézeten át teszi mindezeket elérhetıvé. Eltakarja az adatok heterogenitását, kezeli a formátumok és fizikai elérési módok különbözıségét, egyszerősíti az adatelérést az ezt igénylı más szolgáltatások számára. Információs szolgáltatásként tekintjük az adatkezelés egy speciális, ám jelentıségében mégis kiemelt módját, az ún. tartalomkezelést. A kapcsolódó szolgáltatások teszik lehetıvé, hogy a nem-strukturált (dokumentum, média, stb. jelleg) információkat hatékonyan tárolni, és feldolgozni lehessen.

5.2.6.5.

Elérési szolgáltatások

Ez a blokk a különbözı meglévı (legacy) alkalmazások integrációját biztosítja a SOA környezetbe. Abban az esetben, ha ezek az alkalmazások az üzleti, kormányzati, közigazgatási modellünk elvárásainak jól megfelelı funkciókat kínálnak, akkor ez jelentheti ezen funkciók „becsomagolását” és szolgáltatásokként történı elérhetıvé tételét. Kevésbé szerencsés esetben arra is szükség lehet, hogy ezeket a funkciókat kibıvítve/kombinálva állítsuk el a megfelelı szemantikájú szolgáltatást. Ilyenkor az elérési szolgáltatások egynél több legacy funkciót is felhasználnak a kívánt mőködés megvalósításához. A blokk mőködéséhez elengedhetetlenek a különbözı adapterek, amelyek egyik oldalon a legacy alkalmazások specifikumait ismerve, ezek „nyelvét beszélve”, másik oldalon szabványos felületet kínálva teremtik meg a kapcsolatot a SOA-legacy felületen. 5.2.6.6.

Partnerszolgáltatások

A partnerszolgáltatások feladata a szervezeten kívüli irányok (esetleg speciális, a B2B területen elterjedt protokollok és módszerek, pl. SWIFT, EDI, stb. kihasználásával) kommunikációs integrációjának megvalósítása. Ez a blokk valamelyest analóg az interakciós szolgáltatások blokkal, hiszen megteremti a kapcsolatot a SOA architektúra és a kötött kommunikációs formákra képes partner között, ezzel lehetıvé téve, hogy ebbıl az irányból is fogadhassunk interakciót a SOA rendszereinkben. 5.2.6.7.

Szolgáltatásmenedzsment

Ezek a szolgáltatások azokat az eszközöket és metaadat-struktúrákat foglalják magukba, amelyek lehetıvé teszik az üzleti folyamatok leképzését, az üzleti, kormányzati, közigazgatási elvárások és követelmények rögzítését. Az üzleti, kormányzati, közigazgatási innováció a


19

BME IK

rögzített modell folyamatos, iteratív finomításán és javításán keresztül valósul meg, amelyet a valósidejő üzleti, kormányzati, közigazgatási paraméterek méréseivel támogatunk. Ebben a blokkban válik az is lehetıvé, hogy a mérendı értékeinket (KPI-k) definiáljuk – ezek azok az általános üzleti, kormányzati, közigazgatási mérıszámok, amelyek teljesülését eleve, már a modell megfogalmazásakor célul tőztük ki. A mérés kivitelezéséhez, illetve a KPI-k esetleges változtatásainak végrehajtásához ez a blokk kapcsolatban áll majd az IT szolgáltatások felügyelete blokkal, illetve a folyamatszolgáltatások blokkal.


20

BME IK

6. Jelentıs SOA keretrendszer szállítók és termékeik A Kopint-Datorg munkatársai összeállítottak egy kérdıívet a SOA keretrendszerek kiértékelése céljából. A kérdéseket megküldték a legnagyobb szállítóknak. A beérkezett válaszok és anyagok alapján az alábbi összeállítás készült. Fontos hangsúlyozni, hogy az egyes pontokra adott válaszok maguktól a szállítóktól származnak.

6.1.

HP Magyarország

6.1.1. SOA technológiai modell (blokk diagram)

1. ábra – HP SOA technológiai modell

6.1.2.

Többszörözött szolgáltatás tárak létrehozása

A HP SOA Center támogatja a többszörözött szolgáltatás tárak (federated registry) kialakítását 6.1.3. Szolgáltatás publikáció módjai A HP SOA Center regisrty UDDI-n teszi elérhetıvé a szolgáltatás definíciókat (WSDL, esetleg XML sémadefiníciók), de ismeri az UDDI v3-at is (egyedüliként egyelıre) 6.1.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése A HP által használt IDE a leginkább elterjedt, és jól ismert Eclipse alapokon nyugszik.


21

BME IK

6.1.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) A HP által használt IDE grafikus eszközökkel támogatja WSDL-ek szerkesztését 6.1.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) A HP által használt IDE támogatja ilyen sorok összeállítását 6.1.6.1.1. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard A HP által használt IDE támogatja „összetett” szolgáltatások létrehozását, ezek a registry-be új szolgáltatásként kerülnek be. 6.1.7. Fejlesztı rendszer, A HP által használt IDE Eclipse alapú 6.1.8. xml / soap /wdsl specifikumok A SOA eszközeik az ipari szabványként elterjedt XML leíró nyelvet, SOAP protokollt és WSDL webszolgáltatás-leírást használják 6.1.9. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek) A HP SOA architektúra-elemek a piacon levı jelentısebb adatbázis-termékekkel és operációs rendszerekkel kompatibilisek. J2EE alapú elemekrıl van szó (vagyis operációs rendszertıl függetlenek) 6.1.10. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.) A BPEL 2.0 , BPELJ támogatott 6.1.11. skálázhatóság / üzembiztonsági elemek / redundancia A HP SOA eszközei magas rendelkezésre állásúak, hibatőrıek, illetve kiemelkedı mértékben skálázhatók. J2EE alapú elemekrıl lévén szó 6.1.12. Kommunikációs modell ismertetése (blokk diagram) A szolgáltatások soap protokollon érhetık el. Üzenetek : XML formátumban


22

BME IK

6.1.13. Szolgáltatás tárak meghajtási módja A HP szolgáltatástára J2EE alkalmazásszerveren futtatható.

alkalmazás,

vagyis

bármilyen

szabványos

Java

6.1.14. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) A HP által használt üzleti monitoring eszközök alkalmasak a publikált szolgáltatások minıségi paramétereinek mérésére (már tervezéskor elkészül a monitorozási modell, definiálásra kerülnek a KPI-k). HP-nak külön üzemeltetés-támogató monitorozó eszközei is vannak, mint pl. a Business Avalability Center. 6.1.15. RSA / PKI / biometrikus azonosítási rendszerek támogatása Természetesen mindezeket támogatjuk. 6.1.16. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat) A HP-s registry támogatja 6.1.17. Támogatott hitelesség ellenırzési módszerek A piacon szereplı valamennyi jelentısebb SSM gyártó termékeivel integrálható 6.1.18. Támogatott elektronikus fizetési módok A SOA architektúránk nem kifejezetten része az elektronikus fizetés közvetlen támogatása, de bármilyen fizetési mód megvalósítható SOA szolgáltatásként. 6.1.19. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) AGES (national agency for the management of the communal secretaries registry) Adaptive Enterprise Service-oriented Architecture (SOA),Public Sector (PUB), Enterprise Application Integration (EAI),Security HP External Reference Italy May 11, 2004 Capital & Coast District Health Board HP Services Healthcare, Service-oriented Architecture (SOA), Business Process Workflow HP External Reference New Zealand Jun 13, 2007 Cheshire Building Society Adaptive Enterprise, Service-oriented Architecture (SOA), Financial Industries (FIN) HP External Reference United Kingdom Jun 01, 2004


23

BME IK

Defense Information Systems Agency (DISA) Adaptive Infrastructure, HP OpenView, HP Services, Service-oriented Architecture (SOA) HP External Reference United States Oct 31, 2006 Municipality of Rome Adaptive Enterprise, HP Services, Itanium Business Continuity & Availability, IT Consolidation, Service-oriented Architecture (SOA) HP External Reference Italy Apr 28, 2004 The Office of the Government Chief Information Officer (OGCIO) HP Services, Microsoft Enterprise Microsoft Architecture, Service-oriented Architecture (SOA), E-Commerce HP External Reference Hong Kong,Apr 28, 2007 6.1.20. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek) Record Bank Banking, Compliance, Corporate Account, Itanium End-user Workplace Solutions, Service-oriented Architecture (SOA), Service Management (ITSM) HP External Reference Belgium, Jul 01, 2006 Lukas Bank Banking, Service-oriented Architecture (SOA) HP External Reference Poland, Oct 17, 2003

6.2.

IBM Magyarország


2. ábra – IBM SOA technológiai modell

Példa egy lehetséges implementációra:


24

BME IK

― ― ― ― ― ―

WebSphere Portal Rational Application Developer for WebSphere Software WebSphere Portlet Factory Workplace Designer DB2 Tivoli Access Manager (WebSeal)

6.2.2. Többszörözött szolgáltatás tárak létrehozása A gyártó nem jelentette ki, hogy több szolgáltatástárat tud kezelni. (A prezentáció során kaptunk információkat – egy szolgáltatástárat képes kezelni, azon belül különíti el a szolgáltatásokat.) 6.2.3. Szolgáltatás publikáció módjai A szolgáltatások publikálására alapvetıen a service registry infrastruktúra szolgál, amelynek megfelelı funkcionalitású termékkel az IBM rendelkezik. 6.2.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése A Rational brand megoldásai a SOA megoldások kialakításához a fejlesztési feladatok teljes életciklusát lefedı megoldást adnak. Az egységes Eclipse alapú grafikus felülettel rendelkezı eszközök a követelmény- specifikáció és-dokumentálás fázisától a különbözı modellezési feladatok (UML alapú modellezés, adatmodellek kialakítása) elvégzésének támogatásán át a szorosan vett fejlesztési tevékenységeket (kódolás, unit tesztek, stb.) és a kész kód tesztelési (funkcionális, performancia) feladatait is segítik. Az eszközök alapvetıen a business driven development (üzleti igények által vezérelt fejlesztés) és a különbözı szerepkörök által megbontott fejlesztési módszertan elveinek megfelelıen adnak támogatást. 6.2.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) A Rational fejlesztıi környezet grafikus felülető, támogatja a szolgáltatásleírók készítését, akár azok automatikus generálásával is. 6.2.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) WebSphere MQ, ill. a Message Broker és a WebSphere ESB. Ezekhez mind rendelkezésre áll a grafikus adminisztrátori/fejlesztıi környezet. 6.2.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard Ez nem feltétlenül jelent minden esetben workflow wizard igényt. Összetett szolgáltatás definiálható egy folyamatként is, de ehhez más eszközök is rendelkezésre állnak (pl. további, elemi szolgáltatásokat hívó EJB-k létrehozása, stb.). Amennyiben folyamatként definiáljuk az E-közigazgatás keretrendszer kialakítása

25

BME IK

összetett szolgáltatást, annak tervezéséhez rendelkezésre áll grafikus környezet a modellezéstıl kezdve az implementációig. Maga a folyamat is kialakítható oly módon, hogy szolgáltatásként hívható (indítható) legyen. 6.2.8. Fejlesztı rendszer Rational termékcsaládban az architektúra nyílt ipari szabványokra (TCP/IP, HTML, HTTP, XML, Java, JDBC, JSP, BPEL, Web Services, SOAP, UDDI, WSDL, WFDL, stb.) támaszkodik, ezzel megteremtve a különbözı új és meglévı (akár legacy) rendszerek integrációjának alapjait. 6.2.9. xml / soap /wdsl specifikumok Az IBM megoldások fontos jellemzıje a nyílt szabványok támogatása. Ezek közül az XML, SOAP, WSDL kiemelt szerepet játszanak. A SOA megvalósítását szolgáló szoftverkomponenseink több más szabvány mellett ezeket is támogaták. 6.2.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek) Az IBM megoldások futtatására általában számos platform (pl. Win, Unix, Linux, ...) használható, míg az ezek részét képezı összetevık esetében is (termékenként esetleg eltérı listáról választhatóan) a saját IBM komponenseken túl más gyártók megoldásaival is együttmőködnek. Ilyen módon pl. a DB2 helyett sok esetben Oracle adatbáziskezelı, vagy IBM Directory Server helyett MS Active Directory is használható. 6.2.11. Workflow programozhatósága (nyelvek, BPEL, JAVA, stb.) A BPEL az IBM által támogatott, az üzleti folyamatok leírására szolgáló környezet. Az IBM eszközökkel felépített SOA rendszerek ezen felül gyakorlatilag bármilyen programnyelv használatát lehetıvé teszik pl. Az egyes szolgáltatások kialakításához. Mindaddig, amíg a SOA szabványait alkalmazzák (pl. SOAP, WSDL, stb.) a késıbbi integrációhoz, a fejlesztık akár .NET, akár J2EE vagy más környezetben is dolgozhatnak maguknak a komponenseknek a kifejlesztésekor. Természetesen az IBM a saját fejlesztıkörnyezetével elsısorban a J2EE fejlesztéseket preferálja. 6.2.12. skálázhatóság / üzembiztonsági elemek / redundancia Az IBM megoldásai támogatják nagy megbízhatóságú környezetek kialakítását redundáns (pl. clusterelt) elemek konfigurálásával. 6.2.13. Kommunikációs modell ismertetése (blokk diagram) SOA felépítésében szereplı komponensek az ESB segítségével kommunikálnak, az ESB pedig elrejti az egyes szolgáltatások konkrét implementációs (platform, helyszín, fejlesztési és E-közigazgatás keretrendszer kialakítása

26

BME IK

futtatókörnyezet, elérési protokoll, stb.) sajátosságait, a hívó oldal ezekkel nem kell tisztában legyen.:

3. ábra – IBM SOA kommunikációs modell

6.2.14. Szolgáltatás tárak meghajtási módja A gyártó nem adott felvilágosítást arról, hogy a szolgáltatástárakat milyen szabványú meghajtással tudja kezelni abban az esetben, ha harmadik fél kezeli. 6.2.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) A gyártó a Tivoli rendszerrel javasolja megoldani a szolgáltatások jóságának és futásidejének mérését. 6.2.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása Gyártó szó szerinti válasza: „egyes termékek képesek a PKI infrastruktúrával, vagy RSA környezettel együttmőködni”. 6.2.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat) A gyártó nem válaszolta meg ezt a kérdést. (Átadott anyagban közvetlen információk találhatók)


27

BME IK

6.2.18. Támogatott hitelesség ellenırzési módszerek A gyártó nem válaszolta meg ezt a kérdést. 6.2.19. Támogatott elektronikus fizetési módok A kérdést a SOA, mint architektúra, ill. rendszerépítési módszertan vonatkozásában nem tudták értelmezni. 6.2.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) A szállító szóbeli tájékoztatása alapján a jelenleg futó hazai projektjeik nem tekinthetıek még refrenciának. A megkapott száznál több referenciából a külföldi kormányzati refrenciák az alábbiak (hazaiakkal nem rendelkeznek) Aalborg Kommune, Dánia Beijing Chaoyang Municipal Government, Kína Centro de Processamento de Dados do Estado de Mato Grosso, Brazília Commonwealth of Massachusetts - Executive Office of Health and Human Services, USA Department of the Environment, Heritage and Local Government, Írország Deutsche Rentenversicherung Zentrales Rechenzentrum West GmbH, Németország Deutsches Patent-und Markenamt (DPMA), Németország Housing Development Board, Szingapur New York State Department of Taxation and Finance, USA State of Nevada Division of Welfare and Supportive Services, USA Tullverket (Swedish Customs "Managing the Trade" Division), Svédország 6.2.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) Külön listán közreadott közel 90 referencia


28

BME IK

6.3.

MICROSOFT Magyarország


4. ábra – Microsoft SOA technológiai modell


29

BME IK

5. ábra: Connected Government Framework architektúra

6.3.2. Többszörözött szolgáltatás tárak létrehozása A Windows Sever 2003 Enterprise UDDI Services biztosítja az XML webszolgáltatások szabványos és megbízható nyilvántartását, lekérdezését és integrációját. A menedzselt kódban írt alkalmazás része a Windows Server-nek így nem igényli külön licensz beszerzését. Alapértelmezésben a Microsoft Data Engine (MSDE) ingyenes adatbázismotort használja a szolgáltatástár alapjául, de a megbízhatóság, rendelkezésre állás és a menedzselhetıség érdekében lehetıség van arra, hogy külön Microsoft SQL Server-t használjon a tár alapjául. A tár lekérdezhetı a szabványos UDDI 1.0 és 2.0 fejlesztıi API-kon keresztül, de a Windows-os implementáció tartalmaz egy intuitív webes felületet is, ahol a fejlesztık és felhasználók közvetlenül hozzáférhetnek a tárban tárolt adatokhoz. 6.3.3. Szolgáltatás publikáció módjai A Windows Server 2003 R2 Enterprise UDDI Services kompatibilis a UDDI 1.0 és 2.0 fejlesztıi API-val, így szabványos módon lehetıvé teszi a szolgáltatások publikációját és lekérdezését SOAP interfészeken keresztül is. A szolgáltatások felhasználásához a Microsoft Visual Studio .NET fejlesztıkörnyezet egy UDDI klienst tartalmaz az „Add web reference”


30

BME IK

funkció részeként, amellyel a fejlesztıkörnyezet részeként fedezhetik fel és integrálhatják a UDDI tárban található szolgáltatásokat a fejlesztık. 6.3.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése A Microsoft .NET fejlesztıkörnyezet robosztus és hatékony fejlesztési környezetet nyújt a Microsoft platformra fejlesztık számára. A legtöbb alkalmazással is integrált környezet az operációs rendszer alapvetı szolgáltatásai mellett olyan komplex algoritmusokat is elérhetıvé tesz, mint pl. a kriptográfia, vagy a komplex üzenetküldési mechanizmusok programozása. A keretrendszer lehetıvé teszi alkalmazások különbözı verzióinak egymás mellett futtatását és azt is, hogy vastagkliens alkalmazásokat olyan egyszerően adminisztráljunk, mintha webes alkalmazások lennének. Beépített támogatást ad az XML webszolgáltatások létrehozására és üzemeltetésére, valamint nagyteljesítményő webes alkalmazások létrehozására is. Ugyanebben a környezetben könnyen fejleszthetünk a Microsoft Office alkalmazásokkal integrálódó alkalmazásokat is. A .NET -es alkalmazások és minden Microsoft platform és alkalmazás fejlesztıkörnyezete a Visual Studio.net. Ez az integrált, grafikus fejlesztıkörnyezet hatékony eszközt ad a programozók kezébe grafikus tervezıkkel, egy sokoldalú kódszerkesztıvel és az IntelliSense technológiával, amely szerkesztés közben nyújt javaslatokat a kód alapján a lehetséges kulcsszavakra és elnevezésekre megkönnyítve így a fejlesztık munkáját. 6.3.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) Az ASP.NET környezetben megírt és futtatott XML webszolgáltatások számára a .NET keretrendszer automatikusan generál szolgáltatásleíró fájlt. Ezt a szolgáltatás elérési útjának kibıvítésével (a ?WSDL karakterlánc hozzáadásával) érhetjük el. Ha a szolgáltatás létrehozása elıtt szeretnénk a leírást elkészíteni, lehetıség van arra, hogy a Visual Studio.net segítségével létrehozzunk és szerkesszünk WSDL fájlokat. Ezt a Visual Studio szintaktikai ellenırzéssel, illetve az IntelliSense szerkesztést segítı ajánlásrendszerrel támogatja:


31

BME IK

6. ábra: WSDL fájl szerkesztése Visual Studio.net-ben.

6.3.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) A Windows operációs rendszer beépítve tartalmazza a Microsoft Message Queue technológiát (MSMQ), amely lehetıvé teszi a megbízható, tranzakcionált és garantált üzenettovábbítást alkalmazások és rendszerek között. A .NET keretrendszer korábbi változata és a legfrissebb Windows Communication Foundation is széleskörő fejlesztıi támogatást biztosít az MSMQ kezeléséhez. A BizTalk kiszolgáló mőködésének alapját képezi a MessageBox adatbázis, ami megbízható módon tárolja az üzeneteket a beérkezés után és a feldolgozás során is. Felállítható olyan konfiguráció, ahol a beérkezı üzeneteket a központi adatbázis sorba állítja addig, amíg valamelyik kiszolgáló képes feldolgozni ıket. A feldolgozó kiszolgálók számának növelésével bıvíthetı a rendszer kapacitása. 6.3.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard A Microsoft platform több szinten is támogatja a szolgáltatások kompozícióját. A Windows platform szintjén a Windows Workflow Foundation infrastruktúrát nyújt ahhoz, hogy a fejlesztık hatékony workflow-kat definiáljanak, amelyek egységes eszközökkel és formában futtathatók az alkalmazások részeként. A Windows Workflow Foundation-ben összeállított munkafolyamatok képesek számukra külsı XML webszolgáltatásokat meghívni, azok eredményére várni, azokat bevonni a munkafolyamat végrehajtásába.


32

BME IK

A Windows Workflow Foundation lehetıségeit használja ki a Microsoft Office Sharepoint Server, ami lehetıséget ad a végfelhasználóknak, hogy megfelelı jogosultságok mellett maguk alakítsák munkafolyamataikat. A munkafolyamatok szerkesztésére a Sharepoint Designer alkalmazás szolgál. A Shrepoint Designer által nyújtott lehetıségeken túl a Visual Studio .NET fejlesztıeszköz segítségével komplexebb (pl. állapotgép alapú) munkafolyamatokat is tervezhetünk. Az itt használt tervezıfelület különlegessége, hogy beágyazható vezérlıként a fejlesztık saját alkalmazásaikba is beépíthetik azt, így komplex tervezıfelületet nyújthatnak akár a végfelhasználóiknak is. A szolgáltatások kombinálásának másik szintje a BizTalk Server-ben definiálható orkesztrációk világa. Ennek tervezési felülete és szerkezete nagyban hasonlít a Windows Workflow Foundation lehetıségeihez, de ahhoz képest fontos elınye, hogy az integráció során a fejlesztık rendelkezésére állnak a BizTalk Server adapterei, amelyek számos más rendszerrel (ERP, adatbázisok, nagygépes rendszerek stb.) való egyszerő és gyors kapcsolódást tesznek lehetıvé, illetve az ilyen szolgáltatások mögött természetesen ott vannak a BizTalk Server rendelkezésre állást, menedzsmentet és a folyamatok monitorozását lehetıvé tévı funkciói is. Ezek új lehetıségeket nyújtanak az egész folyamat rendszer monitorozásában és felügyeletében. 6.3.8. Fejlesztırendszer A Microsoft platform minden elemének fejlesztıi eszköze a Visual Studio termékcsalád. Azzal, hogy egy eszközben integrálja a fejlesztéshez szükséges eszközöket növeli a fejlesztık produktivitását, hiszen nem kell foglalkozniuk az egyes alkalmazások közötti váltásokkal, nem kell újabb felületeket megtanulniuk. A Visual Studio-ból érhetık el pl. az adatbázisok, a kiszolgálók beállításai, de innen tervezhetnek üzleti intelligencia projekteket és BizTalk folyamatokat is. A Visual Studio termékcsalád csúcsán a Visual Studio Team System olyan nagyvállalati eszköztárat is biztosít, mint pl. az alkalmazástervezés, a csoportos szoftverfejlesztést támogató verziókezelés és feladatkiosztás, vagy az offline adatbázis fejlesztés. 6.3.9.

xml / soap /wdsl specifikumok

A Microsoft platform és termékek támogatják az említett szabványok több verzióját is. 6.3.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek) A megoldásokban alkalmazható technológiák (.NET, BizTalk, SQL Server) natívan támogatják az XML formátumot, ami széles körben használt ipari szabvány. Ez számos rendszerrel biztosít üzenet szinten kompatibilitást. Adatbázis szinten a .NET keretrendszer tartalmaz interfészeket OleDb és ODBC adatkapcsolatok használatához, illetve Oracle adatbázisokhoz natív kapcsoló is létezik. A Windows operációs rendszer és a rajta futó


33

BME IK

alkalmazások is számos nyílt hálózati szabványt támogatnak, így könnyen mőködnek együtt számos gyártó operációs rendszereivel és alkalmazásaival. A BizTalk Server-t számos gyártó alkalmazásaival való együttmőködésre felkészítették. Az ún. adaptereken keresztül lehetıség van arra, hogy háttéralkalmazásokhoz (pl. ERP rendszerek), más platformokhoz (pl. nagygépes rendszerek), vagy adatbázisokhoz és más adatforrásokhoz (XML fájlok, szöveges fájlok) csatlakozzanak a rendszerek. Számos adapter elérhetı a termék részeként és a dokumentáció alapján lehetıség van további adapterek fejlesztésére is. 6.3.11. Workflow programozhatósága (nyelvek, BPEL, JAVA, stb.) Mindaddig, amíg a SOA szabványait alkalmazzák (pl. SOAP, WSDL, stb.) a késıbbi integrációhoz, a fejlesztık akár .NET, akár J2EE vagy más környezetben is dolgozhatnak a komponenseknek a kifejlesztésekor. 6.3.12. Skálázhatóság / üzembiztonsági elemek / redundancia A BizTalk Server üzenet- és folyamatállapot tároló háttere a Microsoft SQL Server, amely kiválóan skálázható és nagy rendelkezésre állású rendszerek építhetık belıle. Maga a BizTalk Server és a mögötte álló SQL Server is képes hibatőrı klaszterben mőködni, ahol az egyes végponti kiszolgálók képesek átvenni egymás feladatát hiba esetén. A BizTalk Server konfigurálható olyan módon is, hogy a központi üzenetsorból több kiszolgáló párhuzamosan dolgozza fel az üzeneteket. Ez akár a klaszterezés nélkül is biztosítja a rendelkezésre állást, amellett, hogy skálázásra is lehetıséget ad. Az SQL Server 2005 lehetıséget ad az adatbázis tükrözésére is, ami hiba fellépése nélkül is lehetıséget ad az átállásra, így biztosítva idıt pl. a karbantartási mőveletekre anélkül, hogy a szolgáltatás elérhetetlenné válna. Lehetıség van arra is, hogy több SQL Server kiszolgáló végezze az üzenetek kiszolgálását további skálázhatóságot biztosítva a rendszernek.


34

BME IK

6.3.13. Kommunikációs modell ismertetése (blokk diagram)

7. ábra – Microsoft SOA kommunikációs modell

6.3.14. Szolgáltatás tárak meghajtási módja A UDDI szolgáltatások segítségével komplex metaadatokkal is ellátott szolgáltatástárak épülhetnek, hogy a szolgáltatások fejlesztés közben és futásidıben is felfedezhetık és integráltak legyenek. A CGF útmutatást tartalmaz arra, hogy hogyan érdemes strukturálni ezeket az információkat, és hogy hogyan építsünk robosztus, elosztott szolgáltatástárakat.


35

BME IK

6.3.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) A BizTalk Server részeként elérhetı Business Activity Monitoring (BAM) szolgáltatás lehetıvé teszi, hogy a rendszerben éppen futó folyamatokról adatokat, kimutatásokat kérjünk le. Így elemezni lehet a folyamatok dinamikáját, futásidejét. A folyamatokat elemezni kívánó felhasználó a BAM Activity Wizard segítségével megfogalmazza azt, hogy milyen eseményeket és tulajdonságokat szeretne követni, ezt egy Excel táblázatba menti el. Ebbıl a BizTalk Server automatikusan létrehoz egy adatbázist, amiben a tárolt eljárások és táblák a megfelelı folyamatfelügyelethez vannak igazítva. A következı lépésben az itt felhalmozott információkból egy csillagsémás elıkészítı adatbázison keresztül OLAP kockát épít a BAM, amibıl a szokásos analízis eszközökkel (Excel, ProClarity stb.) összesített elemzéseket lehet végezni. Az OLAP kocka bizonyos dimenzióit meg lehet jelölni, mint valósidejő aggregátumokat, amelyeket triggereken keresztül folyamatosan frissít a BAM, így közel valósidejő aggregált követésre van lehetıség.

8.ábra: a BAM architektúrája


36

BME IK

9. ábra: a BAM által szolgáltatott információk felhasználása.

6.3.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása A Windows Server 2003 R2 Enterprise Edition beépített szolgáltatása a PKI tanúsítványtár. A kiszolgálók képesek akár egy nagymérető, elosztott tanúsítvány infrastruktúra teljes kiszolgálására a tanúsítványok létrehozásától a hitelesítésen át a visszavonási listák kezeléséig. A rendszer képes támogatni külsı hardverelemeket is a tanúsítványok tárolásához. A Windows platform API szinten támogatja a titkosítási algoritmusok széles skáláját. A sokak által használt, kipróbált algoritmusgyőjtemény a fejlesztık rendelkezésére áll, ezzel erıs adatbiztonságot építhetnek alkalmazásaikba. A Windows natív programozói felületén túl a .NET keretrendszer megfelelı névterei a menedzselt kód fejlesztıi számára is elérhetıvé teszik ezeket az algoritmusokat ezzel még könnyebbé téve beépítésüket. Az Crypto API bıvíthetı, akár külsı kriptográfiai szolgáltatókkal is, így lehetıvé válik pl. smartcard-ok, vagy más hardvereszközök használata is pl. a többfaktoros azonosításhoz, vagy aláíráshoz és titkosításhoz. 6.3.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) Ennek a kérdésnek a megválaszolásához további információkra lenne szükségünk.


37

BME IK

6.3.18. Támogatott hitelesség ellenırzési módszerek A Windows Server 2003 R2 támogatja a Kerberos alapú hitelesítést, amely elismerten biztonságos, elosztott és más rendszerekkel együttmőködni képes azonosítási infrastruktúrát biztosít. A más azonosítási rendszerekkel való együttmőködés érdekében több technológiai lehetıség is rendelkezésre áll: Kapcsolat Windows Active Directory címtárak között: több, egymástól független szervezet címtárai összeköthetık az Active Directory Federation Services segítségével (ez a szolgáltatás része a Windows Server 2003 R2-nek). Ennek során a két címtár adminisztrátorai jogosultságokat adhatnak a másik rendszer felhasználóinak és csoportjainak. Ezzel kihasználhatják, hogy nem kell az adott felhasználókat mindkét rendszerben adminisztrálni és mindig naprakész jogosultságok szerint férhetnek hozzá a felhasználók az erıforrásokhoz. Kapcsolat más típusú címtárakkal, single-sign-on: a Microsoft Identity Lifecycle Manager segítségével lehetıség nyílik arra, hogy több alkalmazás, több szervezet több technológián futó azonosítását egységesítsük és közösen kezeljük. Single Sign On a BizTalk segítségével: a BizTalk Server alapvetı funkciója, hogy különbözı alkalmazásokat integrál, amelyek különbözı platformokat és különbözı azonosítási módokat használhatnak. Beépítve tartalmaz single-sign-on funkciókat, amelyek segítségével kialakítható egy integrált rendszer. Hivatkozás alapú azonosítás az adathalászat elkerülésére: a Windows CardSpaces technológia segítségével lehetıség van a klasszikus felhasználónév és jelszó alapú hitelesítés kényelmes és rugalmas leváltására. A rendszer lényege, hogy a felhasználó gépén tanúsítvány alapú, ún. információs kártyák tárolódnak biztonságosan. Ezeket vagy a felhasználó hozza létre magának (mint a klasszikus felhasználónév és jelszó esetén), vagy egy megbízható harmadik fél (egy bank, vagy hivatal) adja a felhasználónak. Amikor egy alkalmazás (internetes, vagy lokális) azonosítást kér, akkor a felhasználó egy biztonságos ablakban kiválasztja, hogy melyik kártyájával szeretné azonosítani magát. Ez alapján a rendszer a benne foglalt tanúsítvány alapján összeállít egy azonosító csomagot, ami az alkalmazás számára azonosítja a felhasználót. A rendszer lényege, hogy a tanúsítvány soha nem hagyja el a számítógépet, így nem is lehet azt lehalászni. 6.3.19. Támogatott elektronikus fizetési módok A Windows Workflow Foundation illetve a BizTalk folyamatok is szabványos eszközöket és protokollokat használnak a külsı komponensekkel történı kommunikációra. Minden olyan fizetési szolgáltatással képesek együttmőködni, amelyek szabványos, vagy dokumentált interfészeket nyújtanak. Több referenciával is rendelkezünk, ahol Microsoft platformon mobil fizetést, illetve díjak, illetékek elektronikus fizetését oldották meg (pl. Izraelben és Romániában) A BizTalk Server iparági megoldások megkönnyítésére a Microsoft összeállított több ún. BizTalk Accelerator-t. Ezek a konkrét problémakör speciális igényeihez igazítva technológiai


38

BME IK

útmutatást és mőködı megoldásokat adnak. Az egyik ilyen accelerator a SWIFT rendszerbe való integrálást segíti, ezzel biztosítva a bankközi pénzügyi rendszerekkel való integráció lehetıségét. 6.3.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) UK Government Gateway: az Egyesült Királyság kormányzatának egységes, központosított folyamatkezelı rendszere. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=51003 Bolgár Kormányzati online szolgáltatások: az EU csatlakozás elıtt Bulgáriának legalább 20 online szolgáltatás kellett nyújtani polgárai számára. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=52373 Egyiptomi elektronikus kormányzati szolgáltatások: a kormányzat legtöbb szolgáltatásának online kiszolgálása egységes belépéssel és felhasználó központú felülettel. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=53349 Cseh Informatikai Minisztérium: három év alatt 50.000 felhasználó, 800.000 ügy és 1.000.000 őrlap. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201262 Integrált közszolgáltatások keretrendszer (Connected Government Framework) országos Nagy Britannia, Olaszország, Dánia, Portugália, Csehország, Szlovénia, Horvátország, Szlovákia, Litvánia, Málta, Románia, Bulgária, Egyiptom, Izrael, Kolumbia, India, Thaiföld regionális, Olaszország, Ausztria, Svájc, Németország, Spanyolország, India, önkormányzati Indonézia, Latin-Amerika, Svédország, Lettország, Egyesült Államok 6.3.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) Audi Hungária Motor Kft: Rugalmas, BizTalk alapú adatgyőjtı és standardizáló rendszer a világ egyik legnagyobb motorgyárában. http://www.microsoft.com/hun/casestudy/Audi.mspx GIRO Rt: Nagy megbízhatóságú, BizTalk alapú megoldás a magyarországi bankközi fizetési forgalom elszámolásában http://www.microsoft.com/hun/casestudy/giro.mspx VPOP: Nemzetközi tranzitrendszerhez való csatlakozás, nagy vámolókkal való elektronikus kapcsolat, regisztrációs adó, okmányirodák on-line kiszolgálása. Dreher Rt: PDA-s kereskedelmi rendszer információnak workflow-n keresztüli integrálása SAP rendszerbe Magyar Posta Rt: küldemények követése, központi törzsadat kezelés Malév Rt: B2B megoldás (SITA) és alkalmazásintegráció Richter Rt: csomagolóanyag kezelési folyamatok támogatása, termelésirányítási rendszer SAP integrációja MNB: Alkalmazásintegráció


39

BME IK

6.4.

ORACLE Magyarország


10. ábra –Oracle SOA technológiai modell

Az Oracle SOA Suite részei: 1. A szolgáltatásokat üzleti folyamatokká szervezı BPEL alapú Process Manager 2. Az üzleti folyamatok és szolgáltatások mőködésébe valós idejő betekintést nyújtó Business Activity Monitoring (BAM) 3. Az üzleti elıírásokat rögzítı és automatizáló Business Rules Engine 4. Az alkalmazások között kapcsolatot teremtı és az üzeneteket továbbító többprotokollos Enterprise Service Bus (ESB) 5. A szolgáltatásokra vonatkozó hitelesítési és jogosultságkezelési szabályokat érvényesítı webszolgáltatás-felügyeleti és biztonsági megoldás 6. A szolgáltatások életciklusát feltérképezı és felügyelı szolgáltatás-nyilvántartás (UDDI Registry) 7. A szolgáltatások fejlesztéséhez, hibamentesítéséhez, profilokba rendezéséhez és rendszerbe állításához használt Integrated Service Environment (ISE) - JDeveloper. 6.4.2. Többszörözött szolgáltatás tárak létrehozása Szolgáltatások tárolása Oracle Service Registry-ben történik. A megoldás támogatja a konfigurálható üzleti és technikai besorolásokat. A termék az UDDIspecifikációknak megfelelıen kész taxonómia-ellenırzési szolgáltatásokat is tartalmaz. A vállalatok könnyedén saját besorolási osztályokat is definiálhatnak, amelyeket az érdekeltek adott körére leképezve elısegíthetik a webszolgáltatások feltérképezését, és/vagy támogatást


40

BME IK

nyújthatnak a szolgáltatások felügyeletére és közreadására vonatkozó belsı üzleti folyamatoknak. Minden egyes beállított taxonómiához a termék olyan ellenırzési szolgáltatást biztosít, amely ellenırzi, hogy az adott kategorizálás érvényes-e az adott taxonómián belül. Egyszerő és összetett szolgáltatások különválasztása, metrikák. Fı jellemzık: ― Az egyetlen UDDI szintő replikációs megoldás, amely támogatja a külsı partnerek rendszereire is kiterjedı közös szolgáltatástárakat ― A lehetı legmagasabb szintő biztonsági támogatás, a szolgáltatástár hozzáférésének és integritásának szabályozása ― Az UDDI V3 szabvány teljes körő támogatása ― Az Oracle Application Server 10g 2. (10.1.2.0.2) és 3. kiadása (10.1.3) egyaránt teljes körően támogatja 6.4.3. Szolgáltatás publikáció módjai Szolgáltatást több módszerrel fejleszthetünk. Java és PL/SQL kódból egyszerő varázslóval támogatott vagy folyamattal támogatott a webszolgáltatás fejlesztése. Kész rendszerek, adatbázisok, technológiák, meglévı alkalmazások webszolgáltatáson keresztüli elérhetıségét adapterek teszik lehetıvé. Jelenleg 300+ adapter hitelesített a megoldásainkkal. Bıvebben lásd: http://www.oracle.com/technology/products/integration/adapters/index.html Oracle fusion middleware adapter Az Oracle integrációs adapter, mint a Oracle Fusion Middleware komponense olyan szolgáltatás orientált megközelítést ajánl a különbözı szervezeteknek azért, hogy el tudják érni azokat információs eszközöket, amelyek a legtöbb IT környezetben megtalálhatók. Ezek az adapterek, melyek J23EE alapú szabványokat használnak, rendelkezésre állnak az Oracle Fusion Middleware összes komponense számára. Az Oracle adapterek könnyő kezelhetıséget, flexibilitást és szabvány alapú SOA platformot biztosítanak, gyors és valós idejő hozzáférést lehetıvé téve az alkalmazásokhoz. Széles körő összekapcsolhatóság Az adapter több ajánlott interfészt támogatnak, az alkalmazásokkal történı kommunikáció és az alkalmazások adatainak a szabványos XML nyelvre történı fordítása és visszafordítása érdekében. Kétirányú összekapcsolhatóságot kínál, és szinkronban lehet használni különbözı alkalmazásokban elindított tranzakciók és munkafolyamatok, valamint adatok lekérdezése esetén. Mindezeken felül, aszinkron módon is képes az alkalmazásokból érkezı eseményeket feldolgozni. Fıbb jellemzık ― Kétirányú összekapcsolhatóság ― Egyidejő kérés/válasz ― Publikálás/leiratkozás Technológia és protokollok ― Fájlok


41

BME IK

― FTP ― Adatbázis ― AQ Szabvány alapú támogatás ― JCA 1.5 ― XML ― WSDL ― WSIF Kész szolgáltatások publikálásáért a SOA architektúrában a Service Registry felelıs. Az Oracle alkalmazásszerverének szolgáltatástára (Service Registry) kulcsfontosságú komponense bármely szolgáltatásorientált architektúrának, mivel konfigurálható, jól méretezhetı és biztonságos webszolgáltatás-tára közvetlenül az Oracle Fusion Middleware szoftverkörnyezettel felügyelhetı, feltérképezhetı és irányítható. A szolgáltatástár maradéktalanul kielégíti a szolgáltatások felügyeletére vonatkozó alapvetı vállalati igényeket: ― A szolgáltatók közzétehetik és meghirdethetik szolgáltatásaikat ― A fogyasztók megkereshetik és igénybe vehetik a követelményeknek megfelelı szolgáltatásokat ― A szolgáltatásorientált architektúrák közös irányítópontjaként funkcionál Közvetlenül együttmőködik az Oracle Fusion köztes szoftvercsalád más termékeivel is, mint például az Oracle BPEL Process Manager, Oracle ESB, az Oracle Web Services Manager és az Oracle JDeveloper megoldásokkal. Az együttmőködésrıl a többi termékben alkalmazott kompatibilis UDDI-böngészık gondoskodnak. A szolgáltatástár teljes mértékben támogatja a legújabb UDDI V3 szabványt, és minden egyéb SOA-szolgáltatástárnál szélesebb körő funkciókkal rendelkezik.

6.4.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése Magas szintő alkalmazásfejlesztésrıl két termék esetén beszélhetünk. Ha a feladat csak informatikai rendszerek „rövid idın belüli” integrációját jelenti szinkron és aszinkron módon, akkor az ESB termékrıl beszélünk. 6.4.4.1.

Oracle ESB

Áttekintés Az Oracle Business Integration üzleti integrációs megoldás a webszolgáltatásokat támogató teljes körő infrastruktúrát biztosít a nyílt rendszerszabványokon alapuló elosztott alkalmazások létrehozásához, rendszerbe állításához és felügyeletéhez. Az Oracle ESB komponens a szolgáltatásorientált architektúra (SOA) és az eseményvezérelt architektúra (EDA) megvalósításával az üzleti problémák megoldásának technológiai hátteréül rugalmas, alacsony költséggel járó, kiváló hatékonyságú keretrendszert biztosít. Termékismertetı Az ESB a SOA és EDA architektúrákra épülı szolgáltatások elérhetıvé tételének alapja. Központi részét egy olyan lazán összekapcsolt alkalmazási keretrendszer alkotja, amely


42

BME IK

rugalmasabb mőködést, az újrahasznosíthatóságot és jobb reagálóképességet biztosít a vállalatoknak az elosztott szolgáltatásokkal mőködı, heterogén, üzenetközpontú környezetekben. Az Oracle Business Integration a következı négy fontos megoldáselembıl áll: (1) ESB, (2) BPEL PM, (3) B2B és (4) BAM. Az Oracle a vállalati integrációhoz szükséges valamennyi megoldást egyetlen platformon kínálja. A megoldás teljes mértékben együttmőködik az Oracle alkalmazáskiszolgálóval, az Oracle 10g relációs adatbázis-kezelıvel, az Oracle JDeveloper integrált fejlesztıkörnyezettel és az Oracle BI-megoldásaival. Az Oracle infrastruktúrájának és számítóhálózatos környezetének támogatásával biztonságos, magas rendelkezésre állású és jó méretezhetı megoldást kínál. Megbízható többprotokollos üzenetközvetítés Az Oracle ESB a többcsatornás protokollokat támogató rugalmas, valós idejő vállalati gerincrendszert kínál, ahol valamennyi szolgáltatás a Web Services Definition Language (WSDL) szabvány szerinti tipizált adattartalommal bír. Egyazon virtuális gépen belül engedélyezi a szolgáltatáshívások speciális optimalizálását a háttértárhoz fordulás nélküli, memóriában való mőködéssel. Az Oracle ESB az Oracle Enterprise Messaging Service (OEMS) üzenetkezelési infrastruktúrájával gyors, jól méretezhetı és garantált minıségő szolgáltatást biztosít a pont–pont (P2P) jellegő, illetve a publish/subscribe (közzététel– elıfizetés) alapú kapcsolatokhoz. Az OEMS más gyártók számos üzenetkezelési megoldásával együttmőködik, és a szolgáltatások JMS-szolgáltatás minıségeként az adattároláshoz perzisztens adatbázisban, perzisztens fájlrendszerben vagy memóriában való tárolás választható. Fıbb jellemzık ― Nyílt szabványokon alapuló integrált platform ― Átfogó SOA-fejlesztıkörnyezet ― Rendkívül könnyő kezelhetıség ― Megbízható többprotokollos üzenetközvetítés ― Összetett üzletiadat-transzformációk ― Átfogó felügyeleti és telepítési infrastruktúra ― Sokoldalú kapcsolat a vállalati rendszerekkel (Oracle, PeopleSoft, JDE és Fusion alkalmazások) ― Rugalmas, tartalom alapú feltételes üzenettovábbítás Nyílt szabványok ― WSDL, SOAP, HTTP(s) ― Megbízható SOAP és WSIF protokoll ― JMS.XSLT, BPEL ― JCA, XPATH, XQuery ― UDDI, JNDI, J2EE ― JDBC, SMTP, FTP Integrációs platform ― Oracle AS adapterek ― Oracle Enterprise Messaging Service ― Oracle BPEL PM


43

BME IK

― ― ― ― ― ― ― ― ― ―

Oracle AS BAM Oracle AS B2B Oracle Web Services Manager Oracle Business Rules Oracle AS J2EE Oracle 10g Oracle Grid Enterprise Manager Oracle Data Hub központi törzsadatkezelı megoldások Oracle Bl Oracle JDeveloper

Hosszan lefutó folyamat esetén, amiben már emberi beavatkozás is szerepet játszik, a BPEL Process Managerrıl beszélünk. 6.4.4.2.

Az Oracle BPEL Process Manager

Az Oracle BPEL Process Manager lehetıvé teszi, hogy a szervezetek üzleti folyamataikat a BPEL szabványra alapozva modellezzék és állítsák rendszerbe. A folyamatok szolgáltatásorientált architektúra keretein belül történı összehangolásához és kivitelezéséhez kulcsfontosságú BPEL szabvány egy vállalati szintő modellt szolgáltat az integrációs projektek egyszerősítésére és költségeinek mérséklésére, valamint stratégiai értékük növelésére. A már kapható Oracle BPEL Process Manager fıbb jellemzıi: ― Az elsı olyan natív BPEL-motor, amely teljes folyamathordozhatóságot biztosít ― Éles környezetekben bevált BPEL-folyamatkezelési megoldás, amelyet az ügyfelek azonnal használatba vehetnek ― Az eddigi telepített rendszerekben már bevált megoldás a BPEL szabvány megvalósítására

11. ábra Egyszerő és kompozit szolgáltatásokra épülı fejlesztési keretrendszer.

Az Oracle alkalmazásfejlesztési keretrendszere (Oracle ADF)


44

BME IK

Az Oracle ADF az alkalmazásfejlesztık szélesebb köre számára is „elérhetı közelségbe hozza” a J2EE-fejlesztést, hasonlóan ahhoz, ahogy a Windows-fejlesztés a többség számára az olyan keretrendszerek bevezetésével vált igazán elérhetıvé, mint az Oracle Forms, a PowerBuilder és a Visual Basic. A Model-View-Controller (modell–nézet–vezérlı, MVC) architektúrán alapuló Oracle ADF lehetıvé teszi, hogy a fejlesztık a mögöttes technológia helyett a feldolgozások üzleti aspektusára összpontosítsanak. A keretrendszer vizuális, deklaratív, segédletekkel támogatott programozási technikákkal segíti azokat az alkalmazásfejlesztıket, akik nem szükségszerően J2EE-szakértık. Így ık is gyorsan beletanulhatnak, és rövid idın belül termelékenyen dolgozhatnak. A keretrendszer ipari szabványú J2EE-tervezési sablonokon alapul. A fejlesztık a munkát felgyorsító vizuális eszközökkel kezelhetik az alkalmazás metaadatait, a keretrendszer pedig a bevált sablonok segítségével gondoskodik arról, hogy az alkalmazás végrehajtható kódja a lehetı leghatékonyabban mőködjön. A JDeveloper a következı vizuális segédeszközöket biztosítja a keretrendszerben: ― UML-eszközök az üzleti logika modellezéséhez és legenerálásához ― Vizuális szerkesztıprogramok az ügyféloldali felhasználói felületek kialakításához ― Page flow-modellezés az egyes oldalak közti navigáció definiálására és szabályozására ― Az adatkapcsolatok egérrel való ráhúzása a felhasználói felület képernyıire 6.4.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) Az Oracle JDeveloper támogatja webszolgáltatások legújabb szabványait, és könnyen kezelhetı vizuális eszközöket biztosít webszolgáltatás alapú fejlesztésekhez. A JDeveloper vizuális (UML alapú modellezés, vizuális WSDL szerkesztés) és deklaratív (tulajdonság paletta, struktúra paletta, kódszerkesztı) eszközökkel a webszolgáltatások topdown, bottom-up fejllesztését. Egyetlen kattintással lehet webszolgáltatást készíteni Java-osztályokból, és összetett PL/SQLes webszolgáltatásokat is ki lehet alakítani. BPEL folyamat fejlesztése és szerkesztése az Oracle JDeveloper termékben történik, vizuális és deklaratív módon. A BPEL kód végig elérhetı a fejlesztés során, amit szerkeszthetünk a kódszerkesztıben.


45

BME IK

12. ábra BPEL szerkesztése Oracle JDeveloperben.

6.4.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) A JDeveloper a Java szabványos kérési sorát a JMS-t támogatja. BPEL és ESB termékekkel tudunk JMS queuehoz és MQ-hoz kapcsolódni natív adapterekkel. Oracle J2EE motor (OC4J) JMS támogatása: JMS Az OC4J J2CA implementáció fontos funkcionális egysége az azonnal használatba vehetı generikus JMS Resource Adapter, amellyel külsı JMS-szállítók termékei is zökkenımentesen becsatlakoztathatók az OC4J infrastruktúrájába. Ezen az adapteren keresztül az Oracle Application Server 10g tanúsítottan együttmőködik olyan külsı JMS-szerverekkel, mint a WebSphereMQ, a Tibco JMS és a SonicMQ. A külsı JMS-termékek támogatása mellett a generikus JMS Resource Adapter az olyan MDB-ket is kiszolgálja, amelyek automatikusan igazodnak a változó üzenetterheléshez, valamint optimalizálja a globális tranzakciótámogatást és a JMS-kapcsolatkezelést (JMS connection pooling). JMS Router A JMS Router OC4J-csomagként mőködı J2EE-alkalmazás, amely megbízható message bridging funkciókat kínál tetszıleges támogatott JMS-gyártók termékei között, például: OracleAS JMS, OJMS (AQ/JMS), WebSphereMQ, Tibco JMS vagy SonicMQ. Emellett a JMS Router az üzenetek továbbirányítását szolgáló üzenetszőrést is támogatja.


46

BME IK

6.4.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard Az Oracle a BPEL eszközt használja a szolgáltatásorientált architektúrán belül „workflow” feladatokra. A webszolgáltatásokhoz használt BPEL az üzleti folyamatok összehangolásához és végrehajtásához szükséges ipari szabványt kínál a vállalatoknak. Technikai szempontból a BPEL egy szabványos nyelvet biztosít, amellyel elıírja, hogy miként kell XML-üzeneteket küldeni távoli szolgáltatásoknak, kezelni az XML-adatstruktúrákat, XML-üzeneteket aszinkron módon fogadni távoli szolgáltatásoktól, eseményeket és kivételeket kezelni, meghatározni a párhuzamosan végrehajtható mőveleteket, illetve visszavonni az olyan részfolyamatok részeredményeit, amelyekben kivételesemények léptek fel. Ezek azok az építıelemek, amelyekkel a szolgáltatások egy adott csoportját együttmőködı és tranzakció alapú üzleti folyamatokká lehet egyesíteni. A BPEL az XML-sémán, valamint a SOAP és a WSDL szabványokon alapul. A BPEL eszközben létrehozott minden egyes folyamat a futtató környezetben alapértelmezetten elérhetı, mint webszolgáltatás. Ezen tulajdonságai miatt minden egyes folyamat mint elemi szolgáltatás elérhetıvé és felhasználhatóvá válik másik BPEL folyamatból, vagy webszolgáltatást felhasználó egyéb eszközbıl (pl. webszolgáltatásra épülı web felületekbıl). Elemi folyamatok könnyő elıállítása és felhasználása lehetıvé teszi a tervezéskor különbözı absztrakciós szintek használat és annak könnyő implementálását. 6.4.8. Feljesztı rendszer A SOA komponensek közül a szolgáltatások fejlesztéséhez, hibamentesítéséhez, profilokba rendezéséhez és rendszerbe állításához használt Integrated Service Environment (ISE) az Oracle Jdeveloper. (Más eszköz használatára nincs szükség). A JDeveloper egységes fejlesztıi környezetben biztosítja az összes szükséges eszközt a J2EEalkalmazások, BPEL folyamatok, ESB, webszolgáltatások, PL/SQL kódok megtervezéséhez, kifejlesztéséhez, teszteléséhez, hibakereséséhez, hangolásához, telepítéséhez és verziókövetéséhez. 6.4.9. xml / soap /wsdl specifikumok Az Oracle a kezdetektıl ipari szabványokat használ,termékeiben nem használ gyártó specifikus kiegészítéseket. Az Oracle elkötelezett tagja a szabványosítási társaságoknak. Használt J2EE 1.4 és webszolgáltatás szabványok JavaServer Pages (JSP) .......................................... 2.0 Servlets ................................................................... 2.4 Java Server Faces ................................................... 1.1 Enterprise JavaBeans (EJB) ................................... 3.0 Java Management Extensions (JMX)..................... 1.2


47

BME IK

JMX Remote Access API....................................... JSR-160 J2EE Management.................................................. 1.0 (JSR-77) J2EE Application Deployment............................... 1.1 (JSR-88) Java Transaction API (JTA)................................... 1.0 Java Message Service (JMS).................................. 1.1 Java Naming and Directory Interface..................... 1.2 Java Mail ................................................................ 1.2 Java Database Connectivity (JDBC) ...................... 3.0 Java Authentication & Authorization Service........ 1.0 J2EE Connector Architecture................................. 1.5 Enterprise Web Services ........................................ 1.1 (JSR-921) Web Services Metadata.......................................... 1.0 (JSR-181) Java API for XML-Based RPC (JAX-RPC) .......... 1.1 SOAP with Attachments API for Java (SAAJ)...... 1.2 Java API for XML Processing (JAXP) .................. 1.2 Java API for XML Registries (JAXR) ................... 1.0.5 Java API for Rules Engines.................................... JSR-94 Common Annotations for the Java Platform.......... JSR-250 SOA témájú szabványokról külön oldal található az Oracle Technology Network oldalán. http://www.oracle.com/technology/tech/standards/soa-standards.html Egyéb szabvány alkalmazása nem szükséges a szolgáltatás nyújtójának. 6.4.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek Az Oracle a kompatibilitás certifikálását az alábbi gyártók / termékek vonatkozásában vizsgálta: ― SUN ― Linux ― Windows ― IBM ― HP Pontos certification információ az alábbi linken található: http://www.oracle.com/technology/software/products/ias/files/oracle_soa_certification_10131 0.html A sok komponens miatt elég összetett a támogatottsági mátrix, de összefoglalva elmondható, hogy a SOA Suite komponenseinek metaadatait adatbázisban tárolja, ami támogatott formában csak Oracle adatbázis lehet. J2EE alkalmazásszerverek közül a komponensek telepíthetıek BEA WebLogic, IBM Websphere, Jboss alkalmazás-szerverrekre is. Operációs rendszer szinten támogatott a Windows, Linux, HP-UX, Solaris


48

BME IK

6.4.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.) Nem érkezett határidıre válasz. 6.4.12. Skálázhatóság / üzembiztonsági elemek / redundancia Az Oracle konzekvens SOA stratégiájának köszönhetıen a komponensek skálázhatósága, nagy megbízhatósága és redundancia a kezelése nem más mint J2EE motor üzemeltetési kérdés. Az Oracle SOA komponensei J2EE alapú alkalmazások (BPEL, ESB, OWSM, UDDI Registry, Rules Engine) amik az Oracle J2EE motorjában (OC4J) futnak, ezáltal minden üzemeltetési kérdésben öröklik a J2EE motor képességeit és ezen felül, egységes menedzsment felületet biztosít minden komponensnek. Az OC4J alkalmas nagyvállalati infrastruktúrák kihívásainak (skálázhatóság, üzembiztonság, redundancia) kezelésére. Bıvebb információ: http://www.oracle.com/technology/products/ias/index.html Az magas szintő rendelkezésre állást biztosító, Oracle 10g Release 3 (10.1.3) alkalmazás szervert az Oracle Oracle Application Server 10g új relese-ét és az Oracle Fusion Middleware komponensét úgy tervezték, hogy szabványos, misszió-kritikus platformot biztosítson a különbözı szervezetek számára azért, hogy a jövıjüket ilyen nagy megbízhatóságú architektúrák köré építhessék Az Az Oracle 10g Release 3 alkalmazás szerver kiterjesztette az elızı release-ekre jellemzı Magas Szintő Rendelkezésre Állást annak érdekében, hogy flexibilis, rugalmas és hibatőrı alkalmazásszerver platformot biztosítson, lehetıvé téve a SOA rendszerek telepítését maximális rendelkezésre állással és garantált szolgáltatással.. http://www.oracle.com/technology/products/ias/hi_av/index.html 6.4.13. Kommunikációs modell ismertetése (blokk diagram) Megvalósított architektúrától függ a kommunikációs modell. A következı blokk diagram számos lehetséges külsı rendszert is tartalmaz. Tényleges feladatnál természetesen lehetnek eltérések.


49

BME IK

13. ábra Oracle SOA kommunikációs modell

6.4.14. Szolgáltatás tárak meghajtási módja Minden egyes komponens SOAP/RPC kapcsolaton tud szolgáltatás tárakhoz kapcsolódni, vagy szabványos módon tud UDDI szolgáltatás tárakhoz kapcsolódni. A Jdeveloperben alkalmazásszerver és UDDI kapcsolatot lehet létrehozni, aminek felhasználásával az elıre telepített egyszerő és kompozit szolgáltatásokhoz tud kapcsolódni. Ha távoli szolgáltatásról van szó, akkor a WSDL link megadásával lehet szolgáltatásokhoz kapcsolódni. 6.4.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) Az Oracle SOA architektúrájában a webszolgáltatások biztonságáért és minıségi mutatóinak helyességért az Oracle Web Services Manager (OWSM) komponens felelıs. Az OWSM egy webszolgáltatásokhoz készült biztonsági és felügyeleti megoldás, amely a webszolgáltatások éles rendszerekbe való telepítéséhez szükséges átláthatóságot és ellenırizhetıséget biztosítja. Az Oracle WSM megoldással a szervezetek valamennyi


50

BME IK

webszolgáltatásos alkalmazásukhoz egységes biztonsági infrastruktúrát használhatnak. Ez lehetıvé teszi, hogy a bevált biztonsági szabályokat és monitoringot a meglévı vagy új szolgáltatásokon belül is érvényesítsék. A WMS legfontosabb jellemzıi Webszolgáltatások hozzáférés-szabályozása és egyszeri bejelentkezéses hitelesítés. Az Oracle WSM egyszeri bejelentkezéses hitelesítést biztosít, beleértve a webszolgáltatások hitelesítését, jogosultság-hozzárendelését és auditálását. A jogosultság-hozzárendelés az XML-üzenet vagy szövegtörzs bármely részében elıforduló adatokon alapulhat, és a hozzáférés-szabályozás a szolgáltatás vagy a SOAP-metódus szintjén érvényesül. A WSM támogatja a WS-Security, a SAML és az XML aláírástípusokat. Központi biztonsági szabálykezelés és helyi szabályérvényesítés. Az Oracle WSM lehetıvé teszi, hogy egy központi biztonsági infrastruktúra segítségével a rendszer csak a legszükségesebb esetekben végezze el több alkalommal a szolgáltatások biztonságához szükséges mőveleteket. Az Oracle WSM megoldása lehetıvé teszi, hogy a legjobban bevált biztonsági gyakorlatot anélkül alkalmazzuk egy meglévı webszolgáltatásra, hogy elıtte át kellene programozni az adott szolgáltatást. A szervezetek közötti webszolgáltatásos alkalmazások egységesített monitoringja. Manapság a vállalatoknak komoly nehézséget okoz, hogy miként győjtsék ki azokat az adatokat, amelyek a Sarbanes–Oxley-féle és a Gramm–Leach–Bliley-féle törvény, illetve a HIPAA által elıírt megfelelı auditálási információkat szolgáltatják. Az Oracle WSM lehetıvé teszi, hogy a vállalatok egységes auditálási nyilvántartást hozzanak létre, amely mutatja, hogy mely felhasználó vagy szolgáltatás használta az adott webszolgáltatást, és milyen mőveleteket hajtottak végre. Hogyan mőködik? Az Oracle WSM esetében a rendszergazda egy böngészı alapú eszközzel biztonsági és felügyeleti szabályokat hoz létre. Egy ilyen tipikus, webszolgáltatáshoz készült biztonsági elıírássor lehet például a következı: 1. Fejtsd vissza a bejövı XML-üzeneteket 2. Keresd meg a felhasználó hitelesítı adatait 3. Futtass le egy hitelesítési rutint erre a felhasználóra 4. Végezd el a felhasználó és a webszolgáltatás jogosultságainak ellenırzését 5. Írd be a fenti ellenırzési eredményeket egy naplófájlba 6. Ha a fentiek közül valamennyi lépést sikerült végrehajtani, akkor küldj egy üzenetet a címzett webszolgáltatásnak 7. Ha mégsem sikerült végrehajtani a fenti lépéseket, akkor generálj hibaüzenetet, és hozz létre egy kivételrekordot A WSM ezután minden webszolgáltatáshoz érkezı kérést elfog, és lefuttatja a fenti eljárást. Végrehajtás közben a WSM statisztikát készít a mőveletekrıl, és az eredményeket egy monitorozó kiszolgálóra küldi. A monitoron megjelennek a hibaüzenetek, a szolgáltatás rendelkezésre állási adatai stb. Ennek eredményeképpen a vállalati hálózatban mőködı


51

BME IK

valamennyi webszolgáltatás automatikusan biztonsági és felügyeleti ellenırzéssel egészül ki, anélkül, hogy a szolgáltatásfejlesztınek ehhez külön programozást kellene végeznie. 6.4.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása Futtató környezet támogatja a webszolgáltatás szabványokat, amiknek része a PKI, RSA és biometrikus azonosítás. A legfontosabb public key infrastructure (PKI) standardok, amelyek hozzájárulnak a SOA biztonsághoz ― PKCS (Public Key Cryptographic Standards): A set of specifications developed and maintained by RSA Security (now part of EMC). There are currently 12 PKCS specifications. The most common are PKCS#1 (RSA Cryptography Standard), PKCS#5 (Password-Based Cryptography Standard), PKCS#7 (Cryptographic Message Syntax Standard), PKCS#8 (Private-Key Information Syntax Standard), PKCS#10 (Certification Request Syntax Standard), PKCS#11 (Cryptographic Token Interface Standard), and PKCS#12 (Personal Information Exchange Syntax Standard). Oracle supports PKCS#1, PKCS#7, PKCS#8, and PKCS#11 in Oracle Security Developer Tools (OSDT). OSDT provides libraries used across all the Oracle Fusion Middleware products. ― PKIX (Public-Key Infrastructure - X.509): An Internet Engineering Task Force (IETF) working group. The goal of the PKIX work group is to develop Internet standards to facilitate the use of X.509-based PKI environments. These standards cover areas involving X.509 certificates, Certificate Revocation List (CRL), Lightweight Directory Access Protocol (LDAP), Certificate Management Protocol (CMP), Online Certificate Status Protocol (OCSP), Time-Stamp Protocol (TSP), and Cryptographic Message Syntax (CMS). PKIX standards are supported by the Oracle Security Developer Tools (OSDT). ― XKMS (XML Key Management Specification): Defines protocols for distributing and registering public keys. Applications or web services supporting XKMS don't have to deploy a PKI solution locally. The application or web service sends XML requests (in SOAP messages) to PKI components installed at a trusted third-party site (e.g., Verisign) which executes the XML requests on behalf of the requesting party (typically, XML requests are for issuing, retrieving, or revoking a certificate). XKMS works in conjunction with XML Encryption and XML Signature. 6.4.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) Oracle Service Registry-je a Systinet termékének OEM változata. Minden szolgáltatásra meg lehet határozni a jogosultak körét. Az Oracle holisztikus megközelítést alkalmaz a SOA telepítésekhez, beleértve az azonosítás menedzsmentet (Oracle Access Manager, Oracle Identity Federation, Oracle Web Services Manager), a fejlesztési és telepítési eszközök (Oracle Security Developer Tools (OSDT), JDeveloper (Java Integrated Development Environment), Application Development Framework (ADF), valamint a HTTP/SSL


52

BME IK

6.4.18. Támogatott hitelesség ellenırzési módszerek Szolgáltatás hitelességének ellenırzését egyedileg beállított WS-S beállítással, vagy az OWSM termékkel oldhatjuk meg. Webszolgáltatások hozzáférés-szabályozása és egyszeri bejelentkezéses hitelesítés. Az Oracle WSM egyszeri bejelentkezéses hitelesítést biztosít, beleértve a webszolgáltatások hitelesítését, jogosultság-hozzárendelését és auditálását. A jogosultság-hozzárendelés az XML-üzenet vagy szövegtörzs bármely részében elıforduló adatokon alapulhat, és a hozzáférés-szabályozás a szolgáltatás vagy a SOAP-metódus szintjén érvényesül. A WSM támogatja a WS-Security, a SAML és az XML aláírástípusokat. 6.4.19. Támogatott elektronikus fizetési módok Kész termékkel nem rendelkeznek, mivel minden egyes esetben egyedileg kellene a háttér rendszerekkel integrálni. Szabványos elektronikus fizetéshez tudnak kapcsolódni, vagy mint szolgáltatás fel tudják használni. Egyik ilyen referenciájuk a www.rollcomm.com, ahol mobil eszközökkel integrált Oracle megoldás van. Alkalmazott szabványok: ISO 8583 Standard for Financial Transaction Card Originated Messages - Interchange message specifications 6.4.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) Hazai: ― ― ― ―

UKIG NHH Schengen BM

Külföldi: ― Helth Canada ― European Sapce Agency ― US Navy ― InterAccess ― Qfleet, City of Rotterdam ― Avue Technologies ― FAA ― NASA ― Norwegian Ministry of justice and Police ― NTIA OSM ― Philadelphia Housing Authority ― Shanghai Biotech Center ― Skat Denmark


53

BME IK

― ― ― ― ― ― ―

State of Iowa Toll Collect Korea Customer Service GeoScout Dutch Ministry of Agriculture AMF France stb.

6.4.21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek) Hazai referenciák: ― FCSM ― Lombard Lízing ― Erste Bank ― K&H Külföldi referenciák: ― 2006-ban több mint 27000 volt a Fusion Middleware referenciák száma.

6.5.

RED HAT / JBoss (képviseli: ULX Kft.)

6.5.1. SOA technológiai modell (blokk diagram) Architektúra:

14. ábra JBoss SOA technológiai modell


54

BME IK

6.5.2. Többszörözött szolgáltatás tárak létrehozása ebXML és UDDI interfészek támogatottak, a megvalósítás jUDDI alapú, repository replikáció biztosított 6.5.3. Szolgáltatás publikáció módjai Ipari szabvány WSDL-en keresztül történik 6.5.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése A termék neve: Red Hat Developer Studio, ami a fenti feltételnek megfelel 6.5.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) Bármely szabványos editor, javasolt az Eclipse környezet. 6.5.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) jBPM tervezı, Eclipse-be integrálva 6.5.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard Eclipse fejlesztıi keretrendszerbe illeszkedı workflow editorral rendelkezik 6.5.8. Fejlesztı rendszer A termék neve: Red Hat Developer Studio 6.5.9. xml / soap / wsdl specifikumok támogatott fontosabb szabványok: EJB 3.0, EJB3 Persistence 1.0, Servlet 2.5 , JSP 2.1, JSP/EL 1.0, JSTL 1.2, JSF 1.2, Javamail 1.4, JAF 1.1, SAAJ 1.3, JTA 1.1, JMS, SOAP, JCA, JAX-WS stb.


55

BME IK

6.5.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek) Minden fıbb operációs rendszeren mőködik (Windows, Linux, AIX, HP-UX, Solaris stb.), és minden fıbb adatbázisszervehez tud kapcsolódni (Oracle, DB2, MySQL, PostgreSQL, Sybase, bármely JDBC forrás stb.) 6.5.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.) A BPEL-en kívül folyamatorkesztrációra a jBPM és a jPDL leíró nyelvek is használhatók. 6.5.12. Skálázhatóság / üzembiztonsági elemek / redundancia Lineárisan skálázható (scale-up, scale-out), terhelésosztásos klaszter, szinkron/aszinkron session-szintő failover képességgel, magas hibatőréssel 6.5.13. Kommunikációs modell ismertetése (blokk diagram) (lásd kommunikációs modell ábra) JBoss ESB: támogatja a JBossMQ, JBoss Messaging, Oracle AQ és IBM MQSeries, adatbázis, email transzportokat.

15. ábra JBoss kommunikációs modell


56

BME IK

6.5.14. Szolgáltatás tárak meghajtási módja Adatbázisszinten minden standard adatbázisszerver (Oracle, DB2, MySQL, minden JDBC kapcsolat) Minden szabványos J2EE alkalmazásszerver, minden szabványos JNDI megoldás 6.5.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) Támogatott: JBoss Profiler 6.5.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása Támogatott: Red Hat Certificate System 6.5.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési meta-adat) Megoldott, UDDI / SAML / JAAS kombinációval JBoss alatt.

6.5.18. Támogatott hitelesség ellenırzési módszerek Digitális aláírás, tanúsítványkezelés Red Hat Certificate System-mel. 6.5.19. Támogatott elektronikus fizetési módok Kapcsolódik szabványos payment gateway-ekhez. 6.5.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) Létezik, NDA aláírásával és további egyeztetés után kiadjuk 6.5.21. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek) Létezik, NDA aláírásával és további egyeztetés után kiadjuk


57

BME IK

6.6.

SUN Microsystems Magyarország


16. ábra SUN SOA technológiai modell

Technológiai értelemben a SOA architektúra szabványosított komponensekbıl felépülı rendszer, amelynek egyik legfontosabb eleme egy kommunikációs busz (Enterprise Service Bus). A kommunikációs buszon keresztül válnak elérhetıvé az alkalmazásokban, háttér rendszerekben azonosított szolgáltatások, melyeket a szolgáltatás interfészeken keresztül érünk el. A szolgáltatások interfész definíciója becsomagolja, elrejti az architektúra elıl a nyelvfüggı implementációs részeket. ESB buszhoz kapcsolódik az egyikoldalról a motor (eWay) ezek hozzák létre a kapcsolatot az adatokkal (Database, Címtár) másikoldalról (Adatréteg és Üzleti Logika) a folyamat feldolgozó BPEL nyelven íródott alkalmazások melyekbıl összeépíthetı egy-egy folyamat. A folyamatok végeredményét jeleníti meg a portálon. A rendszer a busz végén található a repository (szolgáltatástár) itt tárolja a szolgáltatás leírásokat, kapcsolati lehetıségeket stb. A SUN SOA megoldás Sun Java System Composite ApplicationPlatform Suite (CAPS) SOA részei: A rendszer négy fı architektúra elembıl épül fel: ― A fejlesztıi környezetbıl, azaz az Enterprise Designerbıl ― A szolgáltatástárból (Repository) amely a fejlesztés alatt álló rendszerek állományait, a rendszer konfigurációs adatait tartalmazza


58

BME IK

― Az Enterprise Managerbıl mely a futtatói környezetet felügyeli és a Logikai Host-ból mely tartalmazza az Integration Szervert, azaz a SOA komponensek futtatási konténerét ― Message Szervert, ami biztosítja a perzisztenciát. A CAPS több beépített komponenst tartalmaz, melyek kiegészítik, teljessé teszik az alap SOA megoldást. Ilyen kiegészítı modul például az üzleti folyamatok leírása és végrehajtása (Business Process Management), az üzleti folyamatok indikátorainak definiálása és nyomon követése (Business Activity Monotoring), üzleti folyamatok grafikus, portál alapú megjelenítése, kezelése, külsı üzleti partnerek alkalmazásainak integrációja (B2B), egységes ügyfélkép megvalósítása a különbözı alkalmazások, adatstruktúrák között (Single Customer View) és a sort lehetne még folytatni. Ezen modulok telepítésével a modellezı / tervezı felületen, az eDesigner-ben is új nyelvek, funkciók használata válik elérhetıvé. A CAPS az alábbi komponensekkel egészítheti ki a fejlesztıi környezet képességeit: ― eGate Integrator – Szabványos J2EE alapú integrációs szolgáltatást nyújt, amely adat transzformálást, garantált tranzakciót és üzenettovábbítást végez az alkalmazás integráció során. ― eInsight Business Process Manager – Az intézmény mőködésében részt vevı rendszerek, emberek, partnerek és web szolgáltatások közremőködésével megvalósuló komplex üzleti folyamatok és workflow automatizálását és vezénylését (orchestration) végzi szabványos BPMN modellezı nyelv és BPEL alapú folyamatvégrehajtás felhasználásával. ― eVision Studio – Grafikus kompozit alkalmazás építı eszköz, amely web alapú GUI építésével gyors hozzáférést biztosít az üzleti folyamatokhoz és a háttér rendszerekhez. ― eTL Integrator – Nagy adatmennyiséghez kapcsolódó adatkinyerést (Extraction), transzformációt (Transformation) és betöltés (Loading) szolgáltatást biztosít file-ok és adatbázisok között. Tipikusan bach típusú futtatások, tranzakciók eredményeinek feldolgozására, integrálására szolgál. ― eXchange Integrator – Az eXchange Integrator egy olyan web alapú külsı partner profile menedzser és üzenetkövetı megoldás, amelyik könnyen használható partner profil menedzsment rendszerével, széleskörő B2B protokoll támogatásával és biztonságos adat transzport biztosításával megkönnyíti az üzleti partnerekkel történı elektronikus kapcsolatok létrehozását és ezek karbantartását. ― eView Studio – Adattisztítási és összerendelési módszerekkel képes egyértelmően azonosítani az elszórt rendszerekben megtalálható azonos rekordokat és automatikusan létrehozza az eltérı azonosítóval rendelkezı, de egyazon adatra mutató kereszt-index állományt. A komponens használatával valósítható meg olyan, napjainkban egyre közkedveltebb szolgáltatás, mint az egységes ügyfélkép (Single Customer View) kialakítása. ― eBAM Studio – Business Activity Monitoring stratégia megvalósítását segíti olyan testreszabható összegzıképernyıkkel, amelyek valós idıben képesek a definiált fı teljesítménymutatók (Key Performance Indicators, KPI) figyelésére és szükség esetén riasztás küldésére. ― eWay adapterek – Web szolgáltatások alkalmazását lehetıvé tevı JCA (Java Connector Architecture) alapú kapcsolódási technológiával gyorsítják fel az integráció folyamatát.


59

BME IK

6.6.2. Többszörözött szolgáltatás tárak létrehozása Csak 1 repository kezelésére képes, amiben több szolgáltatástár is található. A beállítások, komponensek, szolgáltatások, és kapcsolat információkat tárol a repository. Közös repositoryt használ a rendszerfejlesztésre, tesztelésre és az éles rendszerre. A repository és Java CAPS komponensek közti konfiguráció beállítható HTTP vagy HTTPS felületen. Az Enterprise Designer és az Enterprise Manager kliens képes kommunikálni a Repository-val akár tőzfalon keresztül is. A registry-repository SOA infrastruktúrában, kiválasztható mőködési alap módjai lehetnek: ― Saját registry-repository ― UDDI registry repository nélkül ― UDDI registry saját repository-val ― ebXML registry-repository ― Kombinált UDDI registry és ebXML registry-repository 6.6.3. Szolgáltatás publikáció módjai A szolgáltatásokat a repository-ba WSDL szabványt használva tudjuk felküldeni, illetve a rendszer felderítheti a szolgáltatásokat. Információ az összetett szolgáltatásokról, és publikációjukról: A szervizek összetevıi egyre bonyolultabbak, és összetettebbek. Ezért a szolgáltatások kezeléséhez egy egyszerő szabványos információs eszközt használunk: Web Services Description Language (WSDL). Néhány példa az információs eszközökre: ― Több WSDL fájl több különbözı protokollt, és interfészt írhat le szolgáltatási összetevıként ― Extensible Markup Language (XML) séma írják le a szolgáltatás üzeneteit ― Az üzleti folyamatok leírásának eszköze a BPEL (Business Process Execution Language) nyelv, és az Electronic Business Extensible Markup Language (ebXML) ― A metaadat leírhatja egy összetett szolgáltatás struktúráját, és összetevıit ― Extensible Stylesheet Language Transformations (XSLT) stíluslapokkal mint adapterekkel könnyen kezelhetık a szervizverziók közötti különbségek ― Web Services for Remote Portlets (WSRP) leírják, hogy a portál hogyan használja a szervizösszetevıket ― Szervezeti házirendek, üzleti szabályok, és eljárások írják le, a szolgáltatás-összetevık és információs eszközök használatát A registry-repository szolgáltat számos felderítési lehetıséget, és képes az egyszerő, és a bonyolult felderítési lekérdezésekre. Elıre definiálhatunk speciális felderítı szolgáltatásokat. Ezen felül létrehozhatunk ad hoc lekérdezéseket is, ahol összetett logikai meghatározásokat is használhatunk. Néhány példa „magyarul”: ― Keresés az összes WSDL dokumentumnévben egy megadott minta szerint


60

BME IK

― Keresés szolgáltatásban és szervizkapcsolatban, amelynek a dokumentációjában elıfordul az adott szövegminta ― Keresés szolgáltatásban, amelynek SOAP kapcsolata van ÉS nem HTTP használ transzportot ― Keresés az összes WSDL-ben mint szerviz implementációban, amely használ egy bizonyos implementációs platformot (például: Java™ 2 Platform, Enterprise Edition vagy J2EE™, .Net) ― Keress meg minden WSDL-t –amiben a szerviz implementáció bizonyos implementációs erıforrást használ (például: adatbázis, Java Message Service vagy JMS, Java API for XML Registries vagy JAXR, stb.) 6.6.4. Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése Enterprise Designer program segítségével kezelhetı és fejleszthetı az egész SOA rendszer. Itt lehet a kapcsolatokat és a munkafolyamatokat deklarálni, beállítani, szerkeszteni és modellezni egy grafikus felület segítségével. Az összekomponáláshoz az eInsight szoftver modult használjuk, mely hasonlóan az eGate-hez az eDesigner grafikus fejlesztıi felületén keresztül érhetı el, a fejlesztıi felület teljes egészében egységes. Az eInsight BPEL4WS grafikus szerkesztıjével megkomponálhatjuk az üzleti folyamatot. Szintén lehetıség van a grafikus kódból generált BPEL kód kódszintő módosítására és a grafikus megjelenítésbe történı visszaszinkronizálásra. A felület mentesíti a fejlesztıt a BPEL nyelv, illetve a WSDL, UDDI, SOAP protokollok elmélyült ismerete alól, ugyanis automatikusan generálható vele a komponált alkalmazásnak megfelelı WSDL leírás. Emellett a rendszer architektúrája biztosítja a webszolgáltatások közötti kommunikáció kezelését és a szolgáltatás regisztrációját. A CAPS további komponensei is az eGate és eInsighthoz hasonlóan az eDesigner felületébe illeszkednek be.


61

BME IK

17. ábra SUN EDesigner

6.6.5. Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet) Itt is az Enterprise Designer program segítségével kezelhetı és fejleszthetı mivel az egész SOA rendszer management megoldható errıl az egy felületrıl BPEL folyamat fejlesztése és szerkesztése az Enterprise Designer termékben történik, látványosan és deklaratív módon. A kód végig elérhetı a fejlesztés során és utána, amit szerkeszthetünk kódszerkesztıben is, ha akarunk. Modellezés és Összehangolás • Összehangolás o Web szervizre kihelyezés dinamikus felderítés alapján (UDDI) o Hozzáférés 3rd party külsı web szolgáltatáshoz o Grafikus üzleti folyamattervezı • Elvonatkoztató réteg o Fizikai rendszerben kapcsolati térkép meghatározása az üzleti folyamatoktól függetlenül o Kapcsolati térkép automatikus képzése az üzleti folyamatokból • Natív BPMN / BPEL o Nem saját szabványú formátum (mindenki által használt) o BPMN elemzés, BPEL futató • Folyamatvezérlések o tranzakció érvényességi köre


62

BME IK

o jóváírási tranzakciók

18. ábra SUN folyamattervezı GUI

6.6.6. Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet) Itt is az Enterprise Designer program segítségével kezelhetı és fejleszthetı mivel az egész SOA rendszer management megoldható errıl az egy felületrıl Fejlesztési feladatok A következı lépések írják le az alapeljárást, hogy hogyan konfiguráljuk az eIndex SPV. 1. Az alkalmazást a Configuration Editor segítségével konfigurálhatjuk, és állíthatjuk be. 2. Alkalmazás újraépítés (frissíti az egyéni összetevıket is az OTD-ket, és az adatbázis szkripteket.) 3. Testre szabhatjuk az adatbázis szkripteket, létrehozza az adatbázist, és tetszıleges alapadattal tölti fel. 4. Ha szükséges létrehozza, és definiálja a kapcsolati komponenseket, és létrehozza a kapcsolati térképet, és megteremti az adatbázis relációkat az összetevık között. 5. Definiálja a környezetet, és beállítja az alkalmazás szerver, és az adatbázis szerver kapcsolatát. 6. Létrehozza telepítési profilt, és lefuttatja a teljes telepítési eljárást. Az indexelı alkalmazás ezzel telepítésre került az alkalmazás, és integrációs szerveren. 7. Definiálja az EDM biztonsági beállításait az Enterprise Manager segítségével. 8. Az Enterprise Manager segítségével összeállíthatjuk az üzleti folyamatunkat .


63

BME IK

19. ábra SUN Enterprice Designer


64

BME IK

6.6.7. Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard Az Enterprise Designer segítségével lehetséges az elıre létrehozott modulok illetve publikált szolgáltatások egymáshoz kötése egy grafikus felületen drag and drop módszerrel. Az építıelemek, amelyekkel a szolgáltatások egy adott csoportját együttmőködı és tranzakció alapú üzleti folyamatokká lehet egyesíteni BPEL, XML-sémán, valamint a SOAP és a WSDL szabványokon alapul.

6.6.8. Fejlesztı rendszer A SOA komponensek, szolgáltatások, fejlesztéséhez, rendszerbe állításához használt Enterpise Designer (Más eszköz használatára nincs szükség). Az Enterpise Designer egységes fejlesztıi környezetben biztosítja az összes szükséges eszközt az alkalmazások, BPEL folyamatok, ESB, webszolgáltatások, adatkapcsolatok kódok megtervezéséhez, kifejlesztéséhez, teszteléséhez. 6.6.9. xml / soap /wdsl specifikumok Szabvány WSDL és XML kapcsolatokat épít a rendszer Service Description Standards WSDL 1.1 Messaging Standards SOAP 1.1 with Attachments Message Security Standards OASIS Web Service Security Access Control Policy Standards XACML 1.0 Identity Management Standards SAML 2.0 API biztosítja a típus orientált hívásokat, és kibıvíti az új UDDI típusok egyre bıvülı verzióit is


65

BME IK

20. ábra SUN Enterprice komponensek

6.6.10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek) Operációs rendszerek ― Solaris™ ― Microsoft Windows ― HP-UX ― HP Tru64 ― HP Non Stop (Tandem) ― IBM AIX ― Red Hat Linux ― SuSe Linux ― IBM z/OS ― IBM WebSphere, BEA WebLogic, JBoss, Sun Application Server MSMQ and WSMQ / MQSeries) és egyéb kérı/válasz mechanizmusok (COM/DCOM/COM+, CICS External Call Interface, IMS ITOC, CORBA, SAP BAPI, SAP ALE). 6.6.11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.) Modell vezérelt fejlesztés Near-Zero Coding™ Grafikus eszközzel biztosítja a szabványos kód létrehozást, így a teljes futásidıben garantálja a modell és a generált kód teljes szinkronitását - sohasem fog a modell és a kód egymástól különbözni. A szabványok teljes támogatása biztosítja az átjárhatóságot, a hordozhatóságot. Minden összetevı automatikusan Web szolgáltatásként ajánlódik ki.


66

BME IK

Teljes támogatás: ― Java EE, JMS, WS-I Basic Profile, XML ― Hagyományos protokollok mint a MQSeries, CORBA, COM/DCOM/COM+ ― EDI, RosettaNet, AS2 és ebXML 6.6.12. Skálázhatóság / üzembiztonsági elemek / redundancia A rendszer skálázhatósága és megbízhatósága nagyon magas, mert képes a rendszer busz megosztva mőködni több hardveren és ha bármelyik kiesek a helyét a másik átveszi. A rendszerek farmosításával nagy rendelkezés és teljesítmény állhat rendelkezésre. 6.6.13. Kommunikációs modell ismertetése (blokk diagram) Adat réteg, Szerviz busz réteg, Adat generációs réteg, Megjelenítı vagy portál réteg

21. ábra SUN SOA kommunikációs modell


67

BME IK

6.6.14. Szolgáltatás tárak meghajtási módja Saját technológiai meghajtás univerzális privát repository de megnyitható publikus UDDI tárrá tehetı a rendszerazonosítás után a publikált adatok elérhetık. Ha távoli szolgáltatásról van szó, akkor a WSDL link megadásával lehet szolgáltatásokhoz kapcsolódni. 6.6.15. Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi paramétereinek mérése (állásidı, késleltetés) Enterprise Manager ezen program segítségével lehet a programokat és a terheltséget mérni de lehet más mérı rendszert alkalmazni SNMP vagy JMX (Java Management Extensions) Felügyelet és karbantartás Az EDM Web-alapú interfésszel rendelkezik, ahol lehetıvé teszi az adatok megfigyelését és karbantartását az eIndex SPV adatbázisban. Az EDM nagymértékben konfiguráható keresési lehetıségei teljesen kiszolgálják az üzleti igényeket.

22. ábra SUN EDM felügyelet

6.6.16. RSA / PKI / biometrikus azonosítási rendszerek támogatása A SOA része az Identity management szolgáltatás képes keretrendszerként futni és külsı kapcsolatként kommunikálni az azonosító rendszerrel. Az Identity management képes több elfogadott (szabványos) azonosítási módszert támogatni és ezek alapján az alrendszernek publikálni 6.6.17. Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint szolgáltatási attribútum (hitelesítési metaadat) Rendszer bevezetés során meghatározandó kérdések alapján és egyéb informatikai feltételek szükségesek a megválaszoláshoz. A jogosultság több módszer irányából (LDAP, IDM, stb.) is deklarálható.


68

BME IK

6.6.18. Támogatott hitelesség ellenırzési módszerek Külsı hitelesítı cégek módszerei külsı megoldásokként implementálhatóak a rendszerbe. 6.6.19. Támogatott elektronikus fizetési módok A rendszer nem tartalmaz ilyen megoldást de külsı minısített partner fogadására implementálására van lehetıség, mert a fizetési módok nem mások mint különbözı szabványok és mint szolgáltatás fel lehet használni. 6.6.20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek) Van de biztonsági okokból nem kiadható információ 6.6.21. A legfontosabb hazai, külföldi pénzintézeti referenciák (nagy rendszerek) ― ― ― ― ― ― ― ― ― ― ―

AXA Germany Banca IMI BNP Paribas Equities Commerzbank Entenial HypoVereinsbank JPMorgan Chase KBC PostFinance UBS Global Asset Management ZKB


69

BME IK

7. Vizsgálati környezetek és részletes eredmények 7.1.

Tesztágy elsı változata

Célunk egy olyan mintarendszer kidolgozása volt, amely egy életszerő példán keresztül mutatja be a különbözı SOA-eszközök közti átjárhatóságot. A kitalált példa kormányzati rendszerek összekapcsolásával egy EVA áttérési folyamatot valósít meg. Hangsúlyozni kívánjuk, hogy a példában szereplı hivatalok és az áttérési folyamat elképzelt, a valóságnak nem felelnek meg. A folyamat végrehajtása hét résztvevıt igényel, nevük a könnyebb érthetıség kedvéért hasonlít a valódi életben megtalálható elnevezésekhez, azonban felépítésük és technológiájuk nem a valóságot tükrözi. 7.1.1. Architektura A tesztágy kiépítéséhez használt termékeket és a bennük szereplı termékeknek a vizsgálat szempontjából legfontosabb jellemzıit az alábbi táblázat foglalja össze. SOA termék

Sun OpenESB

Microsoft .NET 3.0

Fejlesztı eszköz

Netbeans 6

Visual Studio 2008

Alkalmazásszerver WS API WS-* támogatás

Glassfish

IIS

JAX-WS igen

WCF igen

BPEL támogatás

igen

WF konverteren át

Oracle Oracle SOA Suite 10g, 11g Oracle JDeveloper 10g, 11g Oracle AS

IBM IBM WebSphere

JAX-WS 11g következı verziójában igen

JAX-WS igen

RAD 7 (Eclipse) WebSphere

igen

Az Ügyfél az az egyéni vállalkozó, aki az áttérési folyamatot kezdeményezi. Az Ügyintézı hagyja jóvá a kérvényt. Mindketten egy egységes weboldalon, az Ügyfélkapun keresztül érik el a közigazgatási rendszert. Az Ügyfélkapu feladata a különbözı őrlapok fogadása, majd ezek alapján a szükséges közigazgatási folyamatok elindítása. Az Ügyfél és az Ügyintézı egyaránt digitális aláírással hitelesíti az általa benyújtott őrlapot. A Cégbíróság tárolja a vállalkozások formáit, valamint web-szolgáltatásokat biztosít ezek lekérdezéséhez illetve megváltoztatásához. Az Apeh az adóalanyok adózási információit tárolja, és lehetıvé teszi ezek lekérdezését. Az Igazságügy az egyes személyek büntetettségének nyilvántartását és ezen adatok kiszolgáltatását végzi. A Központ felelıs az üzleti folyamatok végrehajtásáért, különbözı felügyeleti funkciókat biztosít és egységesíti a szakrendszerek (Ügyfélkapu, Cégbíróság, Apeh, Igazságügy) egymás számára nyújtott web-szolgáltatásait. A Központ mögött nem szükségképp áll valós közigazgatási szervezet.


70

BME IK

23.ábra Tesztágy architektúra

A 23. ábrán az elkészült tesztrendszer architektúrája látható. Az Ügyfél és az Ügyintézı böngészıbıl (Internet Explorer, Firefox) HTTPS-en keresztül lép be az Ügyfélkapun. Az Ügyfélkapu weboldalai ASP.NET 2.0 segítségével készültek, a web-szolgáltatásokat WCF valósítja meg. Minden szakrendszer közvetlenül a Központtal kommunikál, az üzenetek megfelelı helyre való továbbításáért a Központ felelıs. A Központ tehát proxy-ként is viselkedik. A Központban egy Oracle alkalmazásszerver futtatja a BPEL-ben megvalósított folyamatot, amelynek állapotát egy Oracle adatbázis tárolja. Amikor a folyamat webszolgáltatást hív, azt is a Központ proxy web-szolgáltatásain keresztül teszi. Az Ügyfélkapu Windows Server 2003 operációs rendszeren, az Apeh SuSE Linux 10.3 alatt, a többi szereplı Windows XP Professional alatt fut. Az architektúra leírásából kitőnik, hogy az elkészült mintarendszer mind operációs rendszer, mind SOA-eszköz tekintetében heterogén elemeket kapcsol össze úgy, hogy azok képesek sikeresen együttmőködni. Az alábbiakban az egyes szereplık megvalósításának részletes bemutatására kerül sor. 7.1.1.1.

Ügyfél, Ügyintézı

Az Ügyfél és az Ügyintézı kötelezıen tanúsítvánnyal hitelesíti magát az Ügyfélkapunál, így elkerülhetı a kevésbé biztonságos felhasználónév-jelszó típusú bejelentkezés. Mindkét szereplı a jogosultságainak megfelelı menüt lát a weboldalon. Az Ügyfél elindíthatja az áttérési folyamatot, az Ügyintézı jóváhagyhat egy már megfelelı fázisban lévı folyamatot. Mindkét tevékenység során a szereplınek egy-egy digitálisan aláírt őrlapot kell feltölteni. A digitális aláírás az e-Szignó intelligens kártyás minısített aláíró rendszerének használatával készül. Az Ügyfél és az Ügyintézı is e-mail-ben kap egy az Ügyfélkapu által digitálisan aláírt visszaigazolást az őrlapjuk benyújtásáról. Az Ügyfél az folyamat elindulásakor és befejezıdésekor SMS értesítést is kap. 7.1.1.2.

Ügyfélkapu

Az Ügyfélkapu ASP.NET 2.0 segítségével készült, így a felhasználók adatait tároló adatbázis ennek megfelelıen jött létre. Ezen túlmenıen minden felhasználónál be van jegyezve a beléptetı és az aláíró tanúsítvány ujjlenyomata. A weboldalt IIS szerver futtatja, amely úgy


71

BME IK

van beállítva, hogy kizárólag HTTPS-en keresztül elérhetı, és megköveteli a kliens oldali tanúsítványokat is. Egy oldal letöltésekor a böngészıben megadott tanúsítványban szereplı „common name” (CN) leképzıdik egy felhasználónévre, majd az adott felhasználóhoz beregisztrált beléptetı tanúsítvány ujjlenyomatot összehasonlítja a program a kapott tanúsítványéval. Amennyiben minden adat érvényes, a kliens beléphet a weboldalra, és az ASP.NET szerepköreinek megfelelı menürendszert és funkciókat érheti el. Az Ügyfélkapu két web-szolgáltatást biztosít a Központ számára. Az egyik az EVA áttérési folyamat jóváhagyását mint alfolyamatot indítja el. Ez azt jelenti, hogy a megfelelı szerepkörrel rendelkezı Ügyintézık számára egy új jóváhagyási kérelem jelenik meg. Amikor egy Ügyintézı feldolgozta a kérelmet, az alfolyamat befejezıdik. A másik szolgáltatás feladata az elindított áttérési folyamat lezárása, ezt hívja meg legutolsó lépésében a fı BPEL folyamat. A szolgáltatásokat HTTPS csatornán keresztül lehet csak meghívni, kizárólag a Központ tanúsítványával. 7.1.1.3.

Cégbíróság

A Cégbíróság egyetlen web-szolgáltatást biztosít, melynek segítségével lekérdezhetı, illetve megváltoztatható egy adott vállalkozás formája. Az üzenetek a WS-SecureConversation protokoll szerint XML szinten vannak titkosítva és aláírva. Biztonsági okokból a Cégbíróság rendelkezik egy STS-sel (Security Token Service) is. A WCF nem tartalmaz STS implementációt, így azt különbözı internetes források alapján készítettük el. A web-szolgáltatás csak az STS által kibocsátott érvényes tokennel hívható meg. Az STS adatbázisában fel vannak sorolva, hogy kinek milyen tokenek adhatók ki. Ebben szerepel a Központ tanúsítványának ujjlenyomata és számára az elıbbi szolgáltatás meghívásához szükséges tokenek. Az STS-nél tanúsítvánnyal kell hitelesítenie magát a kliensnek, így a két szolgáltatást csak a Központ hívhatja meg, egyéb külsı szereplı nem. A megbízhatóságot növeli az is, hogy a WS-ReliableMessaging protokoll is szerepel a szolgáltatások konfigurációjában, így a Cégbíróság kiesése esetén is mőködik a rendszer. 7.1.1.4.

Apeh

Az Apeh által biztosított web-szolgáltatás segítségével lekérdezhetı egy adóalany felhalmozódott adótartozása illetve egy adott évi bevétele. Az üzenetek itt is a WS-SecureConversation protokoll alapján XML szinten vannak titkosítva és aláírva. Az egyik legnagyobb kihívás ennek a rendszernek a mőködésre bírása volt. Itt szembesültünk a Java saját formátumú tanúsítványtárának inkompatibilitásával. Problémát okoztak a folyamatosan változó OpenESB verziókban lévı hibák, amelyek közül többnek a kijavítása hosszú idıbe tellett. Nehéz feladatnak bizonyult a WCF és az OpenESB közötti üzenetforgalom titkosításához és az aláíráshoz használt algoritmusok felparaméterezése. Mindkét oldalon ugyanazokat a tanúsítványokat, ugyanazokat az algoritmusokat és ugyanolyan hosszú kulcsokat kell használni, azonban ezek beállítása az eltérı konfigurációs megoldások miatt nem nyilvánvaló. Az együttmőködéshez elengedhetetlen a két oldalt megvalósító számítógépek óráinak megadott korlátokon belüli szinkronizmusa is.


72

BME IK

7.1.1.5.

Igazságügy

Az igazságügy egyetlen szolgáltatást biztosít, amely segítségével lekérdezhetı egy személy büntetettsége. Tesztjeink azt mutatják, hogy az Oracle 10g-ben a titkosított adatátvitel web-szolgáltatás szinten nem megoldható. Míg más termékek támogatják a WS-Policy szabványt, amely lehetıvé teszi az adatátviteli paraméterek szinkronizálását, addig az általunk használt Oracle 10g verzió esetén a szabvány támogatásának hiányában empirikus úton kell a beállítandó paraméterek értékét meghatározni, amely a beállítási lehetıségek nagy száma és a protokollok verziókülönbségei miatt komoly erıfeszítéseket igényel. Próbálkozásaink eddig nem vezettek eredményre. 7.1.1.6.

Központ

A központ önállóan két web-szolgáltatást biztosít. Az egyik elindítja az EVA áttérési folyamatot, a másik az ügyintézıi ellenjegyzést várja. Ez utóbbit hívja meg az Ügyfélkapu, amikor az Ügyintézı jóváhagy vagy elutasít egy kérelmet. A központ ezen kívül a többi szereplı szolgáltatásait proxy-ként becsomagolja. Az egyes szereplık felé mindig a megfelelı protokollokat használja, kifelé azonban teljesen egységes. További feladata, hogy egységesíti az adatformátumokat, minden egyes átmenı hívást naplóz, megoldja a címzési problémákat és tárolja a futó BPEL folyamatok státuszát. Ezáltal a BPEL folyamatok leírása nagyban leegyszerősödik mind címzés, mind státuszolás tekintetében. A mintafeladatként megvalósított folyamat az Oracle alkalmazásszerverén fut. A BPEL leírás teljesen szabványos, nem használtuk ki az Oracle által biztosított (pl. címzéshez használható) bıvítményeket, ezért azt váruk, hogy a leírás hordozható. További tesztjeink során átültettük a folyamatot ActiveBPEL-be és IBM WID-be is, és kiderült, hogy a folyamatleírás egy az egyben nem portolható, kisebb-nagyobb változtatásokat mindenképpen eszközölni kell, mivel az egyes eszközök nem pontosan vagy nem ugyanúgy fedik le a szabvány egyes elemeit. 7.1.2. EVA áttérési folyamat A tesztrendszerben megvalósított EVA áttérési folyamat lényegét a 22. ábrán mutatjuk be Az Ügyfél által megadott adószám alapján a Cégbíróságtól lekérdezendı a vállalkozás típusa, az Apeh-tıl az adótartozása és az elızı két évi bevétele, majd a személyigazolvány-szám alapján az Igazságügytıl a vállalkozó büntetlensége. Amennyiben a vállalkozó büntetlen, vállalkozásának típusa „egyéni vállalkozás”, nincs adótartozása, mindkét megelızı évben nyereséges volt és bevétele egyik évben sem haladta meg a 20 millió Ft-ot, akkor a kérvény érvényesnek tekintendı és jóváhagyásra javasolt. Amennyiben az ügyintézı azt jóváhagyta, a Cégbíróságnál megváltoztatandó a vállalkozás típusa EVA-ra. A fenti szöveges leírás alapján készült BPEL folyamat 24 lépésbıl áll.


73

BME IK

22.ábra EVA áttérési folyamat

7.1.3. Biztonság A mintarendszer kialakítása során különös figyelmet fordítottunk a biztonsági vonatkozások korrekt kezelésére. A cél az volt, hogy minél többféle biztonsági protokollt használjunk a rendszerben. Az 23. ábrán látható táblázat foglalja össze a biztonsági faktorok megvalósulását az egyes kapcsolatokban. Az Ügyfélkapu (ÜK) mind az Ügyfél (ÜGYF), mind Ügyintézı (ÜGYI) számára kizárólag HTTPS-en át érhetı el, és csak tanúsítvánnyal lehet bejelentkezni. A kezelıi weboldalon megjelenı menüpontokat a megfelelı ASP.NET szerepkör határozza meg. Az Ügyfélkapu és a Központ (KR) között is HTTPS-en keresztül lehet meghívni a web-szolgáltatásokat, azaz SOAP szinten az üzenetek nincsenek titkosítva. A Központ és a Cégbíróság (CÉGB) illetve a Központ és az Apeh (APEH) között WS-SecureConversation SOAP szinten kezeli a titkosságot és az integritást. A Cégbíróságnál ezen túlmenıen egy egyszerősített STS is mőködik. Ez a szolgáltatás a központnak tokeneket ad, és biztosítja, hogy a CÉGB által


74

BME IK

nyújtott szolgáltatást csak az idıbélyeggel ellátott tokennel feljogosított kliens (esetünkben a KR) veheti igénybe.

Kapcsolat

Azonosítás

Authentikáció

Authorizáció

Integritás

Titkosítás

ÜGYF-ÜK

tanúsítvány

SSL

ASP.NET role

SSL

SSL

ÜGYI-ÜK

tanúsítvány

SSL

ASP.NET role

SSL

SSL

ÜK-KR

tanúsítvány

SSL

Automatikus

SSL

SSL

KR-CÉGB

tanúsítvány

WS-Security

WS-Trust (STS)

KR-APEH

tanúsítvány

WS-Security

Automatikus

WSSecurity WSSecurity

KR-IÜGY

-

-

-

WS-Security WS-Security

-

-

Letagadhatatlanság digitális aláírás digitális aláírás WSSecurity WSSecurity -

23. ábra: Biztonsági megoldások az egyes szereplık között

7.1.4. Tapasztalatok és eredmények Elkészítettünk egy különbözı szállítók SOA termékeibıl felépített heterogén rendszert. Célunk annak vizsgálata volt, hogy biztosítható-e a komponensek közötti együttmőködés. Tapasztalatunk szerint az általunk használt termékek esetében – megfelelı paraméterezéssel, segédprogramok igénybevételével, esetenként a biztonsági követelmények lazításával – az interoperabilitás megvalósítható. A tesztrendszer elkészült, mőködik, a szakmai nyilvánosság elıtt mőködés közben több alkalommal is bemutattuk. A kialakítás és mőködés tapasztalatait magyar és külföldi konferenciákon [2], [3], [4] a szélesebb szakmai közönségben is bemutattuk. 7.1.4.1.

Megoldott problémák

A rendszer felépítése során a legtöbb munkát az egyes szereplıket futtató számítógépek, operációs rendszerek, alkalmazásszerverek és SOA-eszközök megfelelı konfigurálása jelentette. A szokásos eljárás szerint a kézikönyvekben és mintafeladatokban megadott beállításokból indultunk ki, amelyek általában éppen az általunk használt konfigurációban bizonyultak alkalmatlannak. A mőködı változat kialakításához szükséges tevékenységek (beállítások értékeinek megváltoztatása, a komponensek – más sorrendben történı – újbóli telepítése) felderítésében sokat segítettek a levelezı listák, és gyakorta az intuíció. A felvetıdött és megoldott problémákból adunk közre néhányat az alábbiakban. Az IIS csak Windows Server operációs rendszeren képes HTTPS protokollt futtatni Különös gondossággal kell eljárni a felhasználói jogosultságok beállításakor, mert az IIS három felhasználó nevében végez mőveleteket, és egyikük sem egyezik meg az oldalt fejlesztı felhasználóval.


75

BME IK

A használt tanúsítványok legtöbbje OpenSSL-lel generált önaláíró tanúsítvány. Ezeket a Windows megfelelı tanúsítványtárába installálni kell, és az IIS három felhasználója számára külön engedélyre van szükség, hogy hozzáférjenek a privát kulcsokhoz. Erre a WinHttpCertCfg segédprogram ad megoldást. Java-ban írt programok futtatása esetén figyelembe kell venni, hogy a Java saját tanúsítványtárat használ, amelybe a privát kulcsot is tartalmazó PKCS12 formátumú tanúsítványok telepítése a JDK-ban található keytool eszközzel nem lehetséges. A telepítéshez ez esetben is külön segédeszközre van szükség (pkcs12import). Az USA exporttilalmai miatt a hosszú titkosító kulcsokat használó programok nem mőködnek, engedélyezésükhöz a JDK-ban néhány jar fájlt le kell cserélni. Az IIS futása közben a WCF részletes naplóihoz – amelyek nagyban segítik a szolgáltatások felélesztését – nem lehet hozzáférni. Ezért a szervert a naplófájlok megtekintésének idejére le kell állítani. Az ASP.NET 2.0 beépített támogatással rendelkezik felhasználónévvel és jelszóval történı bejelentkeztetésre, azonban a tanúsítvány alapú authentikáció külön megoldást igényel. A BPEL folyamatok korrelációk alapján kötik össze az aszinkron hívások kérés- és válaszüzeneteit: az Oracle JDeveloper-ben azonban nem elegendı a BPEL leírást helyesen megadni, a folyamatot tartalmazó projekt beállításainál is WS-Addressing helyett korrelációkra kell áttérni. Nem várt hibát okoz az, ha az amúgy szabványos BPEL folyamatnak az 1.0 verziószámot adjuk, mert ez esetben az alkalmazásszerver képtelen a SOAP akciók és a mőveletek összekapcsolására. A JDeveloper grafikus szerkesztıjének is vannak korlátai: az öröklést használó XSD típusokat nem tudja megfelelıen kezelni, így ezek használatakor a BPEL XML forrását kell szerkeszteni. 7.1.4.2.

Hatékonysági mérések

Megvizsgáltuk, hogy egyes gyártók termékei milyen hatékonyan képesek web- szolgáltatások futtatására. A kiszolgáló számítógép minden esetben 2.66GHz-es Pentium 4 típusú processzorral és 1 GB RAM-mal rendelkezett. Az operációs rendszer egyetlen kivétellel Windows XP Pro SP2 volt: a WCF-et Windows Server 2003 operációs rendszer alatt is vizsgáltuk. A 24. ábra vízszintes tengelyén a gyártók – esetenként különbözı környezetbe telepített – termékei láthatók, a függıleges tengelyen pedig az egy másodperc alatt teljesített kérések száma olvasható le. Az önálló szolgáltatások egyedülálló konzol alkalmazásként futottak. Ezeket mindössze referenciaként kezeljük, mivel valós környezetben nem tekinthetünk el alkalmazásszerver használatától. A megvalósított szolgáltatás minden esetben egy egyszerő számológép volt, amely két szám összegét számolta ki. A szolgáltatásokat HTTP felett szöveges XML-ként kódolt SOAP hívásokkal lehetett elérni. Az IIS a Windows XP-n egyidejőleg maximum 40 nyitott kapcsolatot támogat, így az eredmények összehasonlíthatósága érdekében minden gyártó termékét 40 kliens szál terhelte. Minden egyes kérés új kapcsolatot nyitott, majd válasz után azonnal le is zárta. Az ábrából látható, hogy az alkalmazásszerverre épülı megoldások közel hasonló hatékonyságúak, a WCF Windows Server-en és a Glassfish kicsivel jobbak.


76

BME IK

Tudomásunk szerint a web-szolgáltatások teljesítményelemzésére általános érvényő benchmark-ok nincsenek. A gyártók az általunk is alkalmazott esetekhez hasonló tesztekben közel azonos teljesítményarányokhoz jutottak [5], [6].

24. ábra: az egyes SOA termékek hatékonysága

7.2.

Tesztágy második változata

A tesztágy második változatának célja a fontosabb keretrendszerek interoperabilitásának és a WS-* szabványok szerinti megfelelıség vizsgálata. Az alábbi leírás röviden összefoglalja az elvégzett kísérleteket és tapasztalatokat. A fejezetben a tesztelt rendszerek specifikálását követıen röviden utalunk a megoldott tesztfeladatokra, majd ismertetjük a tesztelı keretprogramot. Ezt követi a teszteredmények táblázatos összefoglalása. 7.2.1. A tesztelt keretrendszerek Rövidítés Axis2

Gyártó Apache

Megnevezés Axis2/Java

JBoss

Red Hat

OpenEsb OracleSoa

SUN Oracle

OracleOc4j

Oracle

JBoss Application Server & Eclipse IDE for Java EE Developers Open ESB 2.0 Oracle 10g (OC4J szerver, JDeveloper fejlesztıkörnyezet) Oracle 11g (az eredeti Oracle vonal folytatása)


Verzió Apache Axis2/Java Version 1.4 5.0.0.CR1 & Ganymede 3.4.0 Milestone 2 (Stable) 10.1.3.4 Technology Preview 4 Studio Edition Version 11.1.1.0.0

77

BME IK

OracleWebLogi cJaxRpc

Oracle

OracleWebLogi cJaxWs

Oracle

WCF

Microsoft

WebSphere

IBM

Oracle WebLogic Server JAXRPC stílusú webszolgáltatásokkal (a felvásárolt BEA WebLogic vonal folytatása) Oracle WebLogic Server JAXWS stílusú webszolgáltatásokkal (a felvásárolt BEA WebLogic vonal folytatása) Windows Communication Foundation Websphere Application Server (WAS) Rational Application Developer for Websphere Software (RAD)

10.3

10.3

.NET 3.0 és 3.5 WAS 6.1 + RAD 7.0 WAS 7.0 + RAD 7.5

7.2.2. Tesztfeladatok A tesztelés során megoldott feladatok részletes leírása megtalálható a projekt keretében korábban átadott [7] dokumentumban. Jelen leírásban a feladat lényegét megadjuk és táblázatos formában definiáljuk az egyes tesztesetek elnevezését, valamint a feladat specifikumát (tipikusan az alkalmazott binding-ot) 7.2.2.1.

Számológép

25.ábra Calculator UML modell

Az ICalculator nevő szolgáltatást kell implementálni. Ez a négy alapmővelet elvégzésére alkalmas: E-közigazgatás keretrendszer kialakítása

78

BME IK

― Add: összeadás ― Subtract: kivonás ― Multiply: szorzás ― Divide: osztás Ha az osztás során nulla az osztó, akkor egy MathFault kivétel dobódik, melynek attribútumai a következıképpen vannak kitöltve: ― Operation=”Divide” ― Problem=”Division by zero.” WsHttp SOAP 1.1 WsHttp SOAP 1.2 WsHttps SOAP 1.2

WsAddr 1.0 SOAP 1.1 WsAddr 2004 SOAP 1.1 WsAddr 1.0 SOAP 1.2 WsRm SOAP 1.2 WsSc SOAP 1.2

WsFault SOAP 1.2 7.2.2.2.

HTTP, SOAP 1.1 HTTP, SOAP 1.2 HTTPS, SOAP 1.2 A kliensnek nem kell tanúsítványt megadni, és a szerver sem kér tıle tanúsítványt a hitelesítéshez. HTTP, SOAP 1.1, WS-Addressing 1.0 (2005/08) HTTP, SOAP 1.1, WS-Addressing August 2004 (2004/08) HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08) WS-ReliableMessaging. Az üzenetek sorrendjét meg kell ırizni, és a felépített session-t le is kell zárnia a kliensnek Üzenetszintő XML titkosítást és digitális aláírást kell végezni (message level security), Basic256 kódolást használva. A szervernek és a kliensnek is tanúsítvánnyal kell hitelesítenie magát (Mutual Certificate authentication). HTTP, SOAP 1.2, (nincs WS-Addressing). Hibajelzés

MTOM kódolás

26.ábra MTOM UML modell

Az IUpload szolgáltatásnak az UploadBytes függvényen keresztül egy fájlt kell fogadnia bináris formában. A fájl nevét a name paraméter, tartalmát a content paraméter adja meg. Az UploadBytes függvény visszatérési értéke a feltöltött fájl mérete byte-ban. WsMtom SOAP 1.1 WsMtom SOAP 1.2

HTTP, SOAP 1.1, MTOM kódolás HTTP, SOAP 1.2, MTOM kódolás


79

BME IK

7.2.2.3.

Banki szolgáltatás

27.ábra Bankos teszt UML modell

A IBank szolgáltatás a következı operációkat tartalmazza: ― AddAmount: az adott accountNumber számlaszámon tárolt pénzösszeghez az amount értékő pénzösszeget kell hozzáadni ― GetAmount: az adott accountNumber számlaszámon tárolt pénzösszeget kell visszaadni Ha a számlaszám nem létezik, egy BankFault kivételt kell dobni, az attribútumokat a következıképpen kell kitölteni: ― Operation = ”AddAmount” vagy “GetAmount” ― AccountNumber = az accountNumber paraméter ― Problem = ”Invalid account number.” Ha az AddAmount esetén nincs elég fedezet, akkor egy BankFault kivételt kell dobni, az attribútumokat a következıképpen kell kitölteni: ― Operation = ”AddAmount” ― AccountNumber = az accountNumber paraméter ― Problem = ”Insufficient funds.” Az adatbázis egyetlen táblát tartalmaz BankAccounts néven, mezıi és rekordjai a következık: AccountNumber 87654321-00000001 87654321-00000002 87654321-00000003 87654321-00000004 87654321-00000005

Amount 100000 20000000 100000000 5000000 6000000


Owner Alice Bob Charlie David Edward

Email [email protected] [email protected] [email protected] [email protected] [email protected]

80

BME IK

Az adatbázis elkészítésére és feltöltésére egy SQL script-et használjunk. WsBank SOAP 1.1 WsBank SOAP 1.2 WsAt SOAP 1.1

HTTP, SOAP 1.1 HTTP, SOAP 1.2 HTTP, SOAP 1.1, WS-Addressing 1.0, WS-AtomicTransaction HTTP, SOAP 1.2, WS-Addressing 1.0, WS-AtomicTransaction

WsAt SOAP 1.2

7.2.2.4.

Aszinkron hívás

28.ábra Aszinkron hívás UML modell

A szervernek az ICalculatorAsync szolgáltatást, a kliensnek pedig – az IPairTest-en kívül – az ICalculatorAsyncCallback szolgáltatást kell implementálnia. Az AddAsync függvényben össze kell adni a két bemenı paramétert, majd a kliens oldalán futó AddCallback függvényt meghívva vissza kell adni az eredményt. WsAsync SOAP 1.1 WsAsync SOAP 1.2

HTTP, SOAP 1.1, WS-Addressing 1.0 (2005/08) HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08)

7.2.3. Tesztelı keretprogram A keretprogrammal szemben támasztott követelmények: ― az egyes SOA termékekben elkészített megoldások végpontjainak címét csak egyszer kell regisztrálni. ― egyszerően lehessen az összes eszközzel egy vagy akár az összes feladatot tesztelni. ― ne „akadjon meg” tesztelés közben, azaz ha nem érkezik egy meghatározott idın belül válasz, akkor azt ne is várja tovább, hanem lépjen tovább. ― egyszerően lehessen két eszköz közötti tesztet végrehajtani.


81

BME IK

― a tesztet végrehajtva annak eredményét ellenırizni és dokumentálni kell. ― elégséges ha a program csak a feladatsorban specifikált IPairTest interfésszel rendelkezı web-szolgáltatások meghívására képes.

Az egyes keretrendszereket reprezentáló Tool osztály tartalmaz egy enumerációt a megoldandó feladatokról. Az összes binding szét van választva külön feladattá, hiszen meghívni csak az azonos bindinggal rendelkezı kliensek és szolgáltatások tudják helyesen egymást. Az osztály tartalmaz még két hash táblát, amelyekben a szolgáltatások és a kliensek címét tárolja. A testAll függvény bemeneti paramétere egy eszközöket tartalmazó Tool tömb. Ennek segítségével lehet végrehajtani egy teljes tesztelést. Ebben az esetben a program végigiterál az összes feladaton, majd ezekkel sorra meghívja a testFeladat függvényt. A testFeladat egy konkrét feladat tesztelését szolgálja. A program tartalmaz továbbá egy Main osztály, ennek main függvényében hozzuk létre az összes eszközt, a Tool osztály egy-egy példányaként. A Tester osztályból is készülegy példány, amelynek testAll függvényét meghívva a program képes arra, hogy az összes tesztet lefuttassa, és kimenetet készítsen. Minden egyes részfeladathoz tartozik egy táblázat. Ennek oszlopai jelzik, hogy melyik rendszerbıl hívódott meg a szolgáltatás (azaz melyik klienst használtuk), a sor jelzi, hogy melyik rendszer szolgáltatása lett meghívva. Az adott mezıkben található jelek: · „+”: A teszteset rendben lefutott. · „-”: A tesztesetre nincs szolgáltatás és/vagy kliens. · „{bető})”: Létezik kliens és szolgáltatás is, de hiba lépett fel. 7.2.4. Tesztelési eredmények A tesztelési folyamatok és azok eredményeinek részletes leírásai megtalálhatók a [8], [9], [10] dokumentumokban. Jelen Tanulmányban csak az egyes tesztesetek eredményeit összefoglaló – összesen 17 – táblázatokat adjuk közre.


82

BME IK

7.2.4.1.

WsHttp SOAP 1.1

A számológép alkalmazáshoz kell HTTP, SOAP 1.1 binding-gal szolgáltatást és klienst készíteni. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ + + + + a) + a) +

+ + + + + + + + +

+ + + + + + + + +

b) + + + + + + + +

b) + + + + + + + +

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere c) + d) + c) + + + c) + + + c) + + + c) + + + c) + + + c) + + + c) + + + c) + + +

Hibák: a) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” b) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. c) Az OracleWebLogic JAX-RPC-s kliense nem megfelelı névterő választ ad, így a választ a program null-ként értelmezi. d) Az Axis olyan választ ad, amiben engedélyezve van a MIME content.


83

BME IK

7.2.4.2.

WsHttp SOAP 1.2

A számológép alkalmazáshoz kell HTTP, SOAP 1.2 binding-gal szolgáltatást és klienst készíteni. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ + + + + a) + a) +

+ + + + + + + b) +

+ + + + + + + + +

c) + + + + + + + +

c) + + + + + + + +

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere d) + e) + d) + + + d) + + + d) + + + d) + + + d) + + + d) + + + d) + + + d) + + +

Hibák: a) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” b) Üres Action-t küld a kliens, erre a Wcf hibát dob. c) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. d) Az OracleWebLogic JAX-RPC-s kliense nem megfelelı névterő választ ad, így a választ a program null-ként értelmezi. e) Az Axis olyan választ ad, amiben engedélyezve van a MIME content.


84

BME IK

7.2.4.3.

WsHttps SOAP 1.2

A számológép alkalmazáshoz kell HTTPS, SOAP 1.2 binding-gal szolgáltatást és klienst készíteni. A kliensnek nem kell tanúsítványt megadni, és a szerver sem kér tıle tanúsítványt a hitelesítéshez. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

a) a) a)

-

+ + +

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + + + + + +

Hibák: a) Az Axis kliense hibát észlel, miközben az OutputStream-re ír.


85

BME IK

7.2.4.4.

WsAddr 1.0 SOAP 1.1

A számológép alkalmazáshoz kell HTTP, SOAP 1.1, WS-Addressing 1.0 (2005/08) binding-gal szolgáltatást és klienst készíteni. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ a) + a) + a) a)

b) b) b) b) b) b) b)

+ + + + + + +

c) + + + + + +

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + d) f) + e) + + + + + + + + + + + + + + + +

Hibák: a) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” b) A JBoss kliense java.lang.reflect.UndeclaredThrowableException-t dob. c) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. d) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. e) Rossz a válasz névtere. f) Nincs Addressing header az Axis által kapott üzenetben.


86

BME IK

7.2.4.5.

WsAddr 2004 SOAP 1.1

A számológép alkalmazáshoz kell HTTP, SOAP 1.1, WS-Addressing August 2004 (2004/08) binding-gal szolgáltatást és klienst készíteni. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ a) a) a) a)

-

+ + + + +

b) c) + c) +

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere d) e) + + + f) + + + +

Hibák: a) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” b) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. c) Hiányzik valamelyik Addressing-es fejléc (To, MessageID, Action) a kliens hívásában. d) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. e) A szolgáltatás válaszából hiányzik az Addressing. f) Nem találja a kívánt hálózati erıforrást (IOException).


87

BME IK

7.2.4.6.

WsAddr 1.0 SOAP 1.2

A számológép alkalmazáshoz kell HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08) binding-gal szolgáltatást és klienst készíteni. A kliens a következı tesztadatokkal hívja a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ a) + a) + a) a)

b) + c) c) c) c) c)

+ + + + + + +

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + d) f) + e) + + + + + + + + e) + + + + + + +

Hibák: a) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” b) NullPointerException-t kap a kliens. c) Hiányzik valamilyen Addressing-es fejléc (To) a kliens hívásában. d) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. e) Rossz a kliens által küldött üzenetben az „Action” névtere. f) Nincs Addressing header az Axis által kapott üzenetben.


88

BME IK

7.2.4.7.

WsRm SOAP 1.2

A számológép alkalmazáshoz kell WS-ReliableMessaging szabványt használni. Az üzenetek sorrendjét meg kell ırizni, és a felépített session-t rendesen le is kell zárnia a kliensnek. HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08), WS-ReliableMessaging binding-gal kell szolgáltatást és klienst készíteni. A kliensnek a következı tesztadatokkal kell hívnia a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

-

-

+ a) + b)

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere b) + e) c) d) f) b) + + b) + +

Hibák: a) A végpont nincs Reliable Messaging-re konfigurálva. b) Nem érkezik válasz idıben a klienstıl a tesztelı programhoz. c) Az OracleWebLogic JAX-RPC-s kliense nem megfelelı névterő választ ad, így a választ a program null-ként értelmezi. d) A kommunikációs csatorna hibás állapotba került. e) A kommunikációs folyamat nem lett lezárva. f) Reliable Messaging csak oneway aszinkron üznetekkel mőködik, üres reply-to-val. Az Oracle szerver nem így válaszolt. E-közigazgatás keretrendszer kialakítása

89

BME IK

7.2.4.8.

WsSc SOAP 1.2

Az eddigi számológép alkalmazást kell módosítani. Üzenetszintő XML titkosítást és digitális aláírást kell végezni (message level security), Basic256 kódolást használva. A szervernek és a kliensnek is tanúsítvánnyal kell hitelesítenie magát (Mutual Certificate authentication). A szerver tanúsítványa a kapott PilotService tanúsítvány, a kliensé a PilotClient. HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08), WsSecureConversation binding-hoz kellett szolgáltatást és klienst készíteni. A kliensnek a következı tesztadatokkal kell hívnia a szolgáltatást: Add(5,8) A teszt akkor sikeres, ha az eredmény helyes. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere


-

-

+ + -

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + + -

90

BME IK

7.2.4.9.

WsFault SOAP 1.2

A számológéphez a következı binding-gal kell egy-egy szolgáltatást és klienst készíteni: HTTP, SOAP 1.2, (nincs WS-Addressing) A kliensnek a következı tesztadatokkal kell hívnia a szolgáltatást: Divide(8,2) Divide(8,0) A teszt akkor sikeres, ha a fenti esetekre a kliens az elvárt eredményt kapja (elsı esetben 4, a második esetben MathFault kivétel). A kliens nem dob MathFault kivételt, ezt lekezeli belül! OracleWebL OracleWebLogi WebSph Axis2 JBoss OpenEsb OracleOc4j OracleSoa Wcf ogicJaxRpc cJaxWs ere Axis2 + c) + f) f) g) h) + JBoss + c) + + + g) + + OpenEsb + c) + + + g) + + OracleOc4j + c) + + + g) + + OracleSoa a) a) a) a) a) g) a) a) OracleWebLogicJaxRpc b) c) e) e) e) g) e) e) OracleWebLogicJaxWs b) c) + + + g) e) e) Wcf b) d) + + + g) + + WebSphere + c) + + + g) + + Hibák: a) Az Oracle Application Server nem tudja átalakítani a dobott Exception-t Fault-tá SOAP1.2 esetén, Internal Server Error-ral leáll. b) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” c) A kliens továbbdobja a MathFaultMessage-et. d) A kliens üres Action-nel hívja meg a szolgáltatást. e) A kivételt nem tudja az Oracle szerver lekezelni. f) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. g) Az OracleWebLogic JAX-RPC-s kliense nem megfelelı névterő választ ad, így a választ a program null-ként értelmezi. h) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. E-közigazgatás keretrendszer kialakítása

91

BME IK

7.2.4.10. WsMtom SOAP 1.1 Az MTOM kódolásos feladathoz HTTP, SOAP 1.1, MTOM kódolás binding-gal kell szolgáltatást és klienst készíteni. A kliens a következı paraméterekkel hívja a szolgáltatást: a name paraméter értéke: TestFile a content paraméterben egy 1048576 (1 MB) mérető byte-tömböt kell átadni A teszt akkor sikeres, ha az UploadBytes visszatérési értéke 1048576. Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ a) + + + + + +

+ + + + + + + +

+ a) + + + + + +

b) a) + + + + + +

b) a) + + + + c) +

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + + + a) a) a) + + + + + + + + + + + + + + + + + +

Hibák: a) Rossz visszatérési érték. b) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. c) Binding különbség miatt nem tudja a szerver feldolgozni a kapott üzenetet.


92

BME IK

7.2.4.11. WsMtom SOAP 1.2 Az MTOM kódolásos feladathoz HTTP, SOAP 1.2, MTOM kódolás binding-gal kell szolgáltatást és klienst készíteni. A kliens a következı paraméterekkel hívja a szolgáltatást: a name paraméter értéke: TestFile a content paraméterben egy 1048576 (1 MB) mérető byte-tömböt kell átadni A teszt akkor sikeres, ha az UploadBytes visszatérési értéke 1048576.

Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

+ a) + + + + + +

+ + + + + + + +

+ a) + + + + + +

b) a) + + + + c) +

b) a) + + + + c) +

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere + + + a) a) a) + + + + + + + + + + + + + + + + + +

Hibák: a) Rossz visszateresi ertek. b) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. c) A kliens által küldött üzenet Action mezıje üres.


93

BME IK

7.2.4.12. WsBank SOAP 1.1 Ezt a szolgáltatást kell tranzakció használata nélkül, HTTP, SOAP 1.1 binding-gal elérni. A kliens a következı paraméterekkel hívja a szolgáltatást és ellenırizze a következı feltételek teljesülését: GetAmount(“87654321-00000001”) == 100000 GetAmount(“87654321-00000000”) ---> BankFault kivétel a megfelelı attribútumokkal AddAmount(“87654321-00000002”, -1000000000) ---> BankFault kivétel,ellenırizni, hogy nem változott-e a számla összege AddAmount(“87654321-00000003”, 10000000): ezután ellenırizze le a kliens, hogy megváltozott-e a számla összege A tesz akkor sikeres, ha minden eset a fenti feltételeknek megfelel. A tesztfüggvény ne dobjon BankFault kivételt, ezt a kliens kezelje le. OracleWebL OracleWebLogi WebSph Axis2 JBoss OpenEsb OracleOc4j OracleSoa Wcf ogicJaxRpc cJaxWs ere Axis2 a) d) + f) f) g) h) i) + JBoss b) d) + + + g) h) + + OpenEsb c) d) + + + g) h) + + OracleOc4j c) d) + + + g) h) + + OracleSoa c) d) + + + g) h) + + OracleWebLogicJaxRpc c) d) e) e) e) g) h) e) + OracleWebLogicJaxWs c) d) e) e) e) g) + e) e) Wcf c) d) + + + g) h) + + WebSphere c) d) + + + g) h) + + Hibák: a) Nem érkezett válasz a klienstıl idıben. b) Hiba a második tesztben. c) A SOAP üzenet amit a kliens küld SOAP1.2-es d) A kliens NullPointerException-t ad vissza. e) A BankFaultMessage-et nem tudja kezelni az Oracle szerver. f) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. g) Az OracleWebLogic JAX-RPC-s kliense nem megfelelı névterő választ ad, így a választ a program null-ként értelmezi. h) arg0 a küldött paraméter accountNumber helyett. i) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. E-közigazgatás keretrendszer kialakítása

94

BME IK

7.2.4.13. WsBank SOAP 1.2 Ezt a szolgáltatást kell tranzakció használata nélkül, HTTP, SOAP 1.2 binding-gal elérni. A kliens a következı paraméterekkel hívja a szolgáltatást és ellenırizze a következı feltételek teljesülését: GetAmount(“87654321-00000001”) == 100000 GetAmount(“87654321-00000000”) ---> BankFault kivétel a megfelelı attribútumokkal AddAmount(“87654321-00000002”, -1000000000) ---> BankFault kivétel,ellenırizni, hogy nem változott-e a számla összege AddAmount(“87654321-00000003”, 10000000): ezután ellenırizze le a kliens, hogy megváltozott-e a számla összege A tesz akkor sikeres, ha minden eset a fenti feltételeknek megfelel. A tesztfüggvény ne dobjon BankFault kivételt, ezt a kliens kezelje le. OracleWebL OracleWebLogi WebSph Axis2 JBoss OpenEsb OracleOc4j OracleSoa Wcf ogicJaxRpc cJaxWs ere Axis2 a) f) + g) g) h) i) + JBoss b) f) + + + h) + + OpenEsb a) f) + + + h) + + OracleOc4j b) f) + + + h) + + OracleSoa c) f) c) c) c) h) c) c) OracleWebLogicJaxRpc OracleWebLogicJaxWs d) f) d) d) d) h) d) d) Wcf e) f) + + + h) + + WebSphere b) f) + + + h) + + Hibák: a) Nem érkezett válasz a klienstıl idıben. b) Hiba a második tesztben. c) Az Oracle Application Server nem tudja átalakítani a dobott Exception-t Fault-tá SOAP1.2 esetén, ekkor Internal Server Error-ral leáll. d) BankFaultMessage keletkezik, amit az Oracle szerver nem tud lekezelni. e) A kliens olyan üzenetet küldött, amiben engedélyezve van a MIME tartalom. f) A kliens NullPointerException-t ad vissza. g) Az Oracle-es virtuális gép valamiért nem tudja feloldani a pilot-slave2 nevet, és nem találja a szolgáltatást. h) Rossz a regisztrált kliens címe. i) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. E-közigazgatás keretrendszer kialakítása

95

BME IK

7.2.4.14. WsAt SOAP 1.1 A következı binding-okhoz kell egy-egy szolgáltatást és klienst készíteni: HTTP, SOAP 1.1, WS-Addressing 1.0, WS-AtomicTransaction Az AddAmount függvény csak tranzakción belülrıl hívható és a tranzakció kiterjed az adatbázisra is. A kliens egy-egy tranzakción belülrıl a következı paraméterekkel hívja a szolgáltatást és ellenırizze a következı feltételek teljesülését: GetAmount(“87654321-00000001”) == 100000 GetAmount(“87654321-00000000”) ---> BankFault kivétel a megfelelı attribútumokkal AddAmount(“87654321-00000002”, -1000000000) ---> BankFault kivétel,ellenırizni, hogy nem változott-e a számla összege AddAmount(“87654321-00000003”, 10000000), commit-tal a végén: ellenırizni, hogy nem változott-e a számla összeg AddAmount(“87654321-00000003”, 10000000), rollback-kel a végén: eellenırizni, hogy nem változott-e a számla összeg 1000000000 összeg átutalása a 87654321-00000004 számláról a 87654321-00000005 számlára (utána le kell ellenırizni, hogy BankFault kivétel keletkezett és nem változott a pénzösszeg egyik számlán sem) 1000000 összeg átutalása a 87654321-00000004 számláról a 87654321-00000005 számlára (ellenırizni, hogy a tranzakció megtörtént) 1000000 összeg átutalása a 87654321-00000005 számláról a 87654321-00000000 számlára (ellenırizni, hogy BankFault kivétel keletkezett és nem változott a 87654321-00000005 számla összege) 1000000 összeg átutalása a 87654321-00000005 számláról a 87654321-00000004 számlára (ellenırizni, hogy a tranzakció megtörtént) A tesz akkor sikeres, ha minden eset a fenti feltételeknek megfelel. A tesztfüggvény nem dob BankFault kivételt, ezt a kliens kezeli le. OracleWebL OracleWebLogi WebSph Wcf Axis2 JBoss OpenEsb OracleOc4j OracleSoa ogicJaxRpc cJaxWs ere Axis2 JBoss OpenEsb + a) OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf + WebSphere a) + Hibák: a) Hiba a második tesztben. E-közigazgatás keretrendszer kialakítása

96

BME IK

7.2.4.15. WsAt SOAP 1.2 A következı binding-okhoz kell egy-egy szolgáltatást és klienst készíteni: HTTP, SOAP 1.2, WS-Addressing 1.0, WS-AtomicTransaction Az AddAmount függvény csak tranzakción belülrıl hívható és a tranzakció kiterjed az adatbázisra is. A kliens egy-egy tranzakción belülrıl a következı paraméterekkel hívja a szolgáltatást és ellenırizze a következı feltételek teljesülését: GetAmount(“87654321-00000001”) == 100000 GetAmount(“87654321-00000000”) ---> BankFault kivétel a megfelelı attribútumokkal AddAmount(“87654321-00000002”, -1000000000) ---> BankFault kivétel,ellenırizni, hogy nem változott-e a számla összege AddAmount(“87654321-00000003”, 10000000), commit-tal a végén: ellenırizni, hogy nem változott-e a számla összeg AddAmount(“87654321-00000003”, 10000000), rollback-kel a végén: eellenırizni, hogy nem változott-e a számla összeg 1000000000 összeg átutalása a 87654321-00000004 számláról a 87654321-00000005 számlára (utána le kell ellenırizni, hogy BankFault kivétel keletkezett és nem változott a pénzösszeg egyik számlán sem) 1000000 összeg átutalása a 87654321-00000004 számláról a 87654321-00000005 számlára (ellenırizni, hogy a tranzakció megtörtént) 1000000 összeg átutalása a 87654321-00000005 számláról a 87654321-00000000 számlára (ellenırizni, hogy BankFault kivétel keletkezett és nem változott a 87654321-00000005 számla összege) 1000000 összeg átutalása a 87654321-00000005 számláról a 87654321-00000004 számlára (ellenırizni, hogy a tranzakció megtörtént) A tesz akkor sikeres, ha minden eset a fenti feltételeknek megfelel. A tesztfüggvény nem dob BankFault kivételt, ezt a kliens kezeli le. OracleWebL OracleWebLogi WebSph Wcf Axis2 JBoss OpenEsb OracleOc4j OracleSoa ogicJaxRpc cJaxWs ere Axis2 JBoss OpenEsb a) OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf + WebSphere + Hibák: a) Nincs Addressing property a kapott üzenetben. E-közigazgatás keretrendszer kialakítása

97

BME IK

7.2.4.16. WsAsync SOAP 1.1 A következı binding-okhoz kell egy-egy szolgáltatást és klienst készíteni: HTTP, SOAP 1.1, WS-Addressing 1.0 (2005/08) A kliensnek a következı tesztadatokkal kell hívnia a szolgáltatást: AddAsync(5,8) A teszt akkor sikeres, ha az eredmény helyes (13). (A kliens tehát várja be a választ! A hívás és a válasz szinkronizációját pl. statikus attribútumokkal lehet megoldani.) Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 JBoss OpenEsb OracleOc4j OracleSoa OracleWebLogicJaxRpc OracleWebLogicJaxWs Wcf WebSphere

-

-

a) + + +

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere b) + + c) + d) + +

Hibák: a) Nincs megfelelı visszatérési érték. b) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. c) Nem volt callback. d) Érvénytelen MessageID.


98

BME IK

7.2.4.17. WsAsync SOAP 1.2 A következı binding-okhoz kell egy-egy szolgáltatást és klienst készíteni: HTTP, SOAP 1.2, WS-Addressing 1.0 (2005/08) A kliensnek a következı tesztadatokkal kell hívnia a szolgáltatást: AddAsync(5,8) A teszt akkor sikeres, ha az eredmény helyes (13). Axis2 JBoss OpenEsb OracleOc4j OracleSoa Axis2 + JBoss a) OpenEsb a) OracleOc4j a) OracleSoa OracleWebLogicJaxRpc a) OracleWebLogicJaxWs Wcf b) WebSphere a)

a) c) c) c) c) c) c)

d) d) + d) d) + +

-

-

OracleWebL OracleWebLogi WebSph Wcf ogicJaxRpc cJaxWs ere e) f) h) e) + i) e) + j) e) g) h) a) + h) e) + + e) + +

Hibák: a) A kliens a következıt adja vissza: „AddCallback didn't work” b) Az Axis kliense a következı hibaüzenetet adja vissza: „ERROR: runPairTest not initalized” c) IOException ad vissza a kliens. d) A kliens a következıt adja vissza: „Return value not assigned” e) TEST Invalid message id f) Az Axis olyan választ ad, amiben engedélyezve van a MIME content. g) Az Action mezı üres. h) A kliens a következıt adja vissza: „No callback received” i) Internal Server Error keletkezik a JBoss szerverben. j) Rossz a visszaadott RelatesTo mezı. E-közigazgatás keretrendszer kialakítása

99

BME IK

8. Vizsgálati eredmények összesítése 8.1.

Vizsgálati szempontok alapján készült összesítés

A 6 fejezetben található kérdéssor összeállításával egyik célunk az volt, hogy felmérjük az adott szállító magyarországi képviseleténél átlátják-e a technológia hátterét, értik-e a SOA megvalósítással kapcsolatos lényeges kérdéseket, vagy pedig csak a szokásos „marketing” anyagokat küldik tovább. Egyik célunk ezzel a hazai szakmai kompetencia, illetve a humán kommunikációs készségük (mennyire képesek felmérni az ügyfél igényeit) felmérése volt. A kérdéssor kiírásakor másik célunk az volt, hogy teljes képet kapjunk arról, hogy mennyire tudnak és képesek együttmőködni a szállítók és termékeik egy nagy rendszerben. Az alábbiakban összefoglaljuk a szállítókkal, termékeikkel kapcsolatos észrevételeinket az alábbi szempontok alapján: ― ― ― ―

Hozzáállás, segítıkészség (magyarországi támogatottság) Küldött anyagok minısége, kérdésekre adott válaszok teljeskörősége Bemutatott termékek Egyéb szállítói specifikumok

Szeretnénk megemlíteni, hogy titoktartási okok miatt több szállító (IBM, SUN, Red Hat) nem tudta a referenciák teljes listáját átadni. BEA SYSTEMS (Magyarországon képviseli: Alerant Zrt., illetve kereskedelmi iroda) Többszöri kérésünk ellenére semmilyen anyagot, sem technológiai felvilágosítást nem kaptunk. Tudomásunk szerint Magyarországon bevezetett rendszere, referenciája nincsen. Tudomásunk szerint nincs Magyarországon számottevı szakmai támogató csapat. HP MAGYARORSZÁG Leginkább marketing jellegő anyagot kaptunk. A megvalósítás során csak mint hardver szállítót tudjuk elképzelni. IBM MAGYARORSZÁG Robosztus, technikailag fejlett sok termékbıl álló termékcsalád, skálázható megoldásokkal. Gyakorlott, tapasztalt szakemberekkel találkoztunk a prezentáció során. A kérdéseinkre nem kidolgozott válaszsort kaptunk, hanem elárasztottak bennünket komoly szakmai anyagokkal, amelyekbıl nekünk kellett kifejteni a lényeget. Kiemelkedı mennyiségő referenciával rendelkezik (100-ból 11 kormányzati), befejezett hazai SOA projekt még nincs. MICROSOFT MAGYARORSZÁG


100

BME IK

Rendkívüli segítıkészség és magas szakmai kompetenciát tapasztaltunk. A megoldásuk architektúrája eltér a többi megoldás szállító termékétıl ezért megoldásukat a mellékletben külön dokumentum tárgyalja. A kérdéseinkre adott válaszok mögött nagymértékő rendszerintegrációs tapasztalat és technológiai ismeret rejlik, felkészült szakmai csapatot találtunk náluk, akik gyakorlott SOA bevezetık. Biztonsági megoldások kidolgozása az egyik legjobb volt. Több kormányzati referencia szomszédos országokban. ORACLE MAGYARORSZÁG Segítıkészek voltak, minden kérdésre kaptunk szakmai választ. Nem minden kérdésre kaptunk azonos mélységő, részletezettségő választ. Jó magyarországi támogatottsággal rendelkeznek.

JBOSS / RED HAT (Magyarországon képviseli: ULX Kft.) Jelenleg nincs Magyarországi referenciája. Kissé megkésve, de tömör, velıs anyagot kaptunk. A gyártó felkészültsége alapos, azonban a magyarországi támogatottság mértékét nem tudjuk felmérni. SUN MICROSYSTEMS MAGYARORSZÁG A legjobb hozzáállást és támogatást a SUN nyújtotta. A kérdéssorokra kihegyezett prezentációt kaptunk. A magyarországi támogatottság, hozzáértési kompetencia kiemelkedınek látszik. Nagy számú referencia állami és pénzügyi szektorban.

A kérdéssorban szereplı tényezıkre kapott válaszokat a Kopint munkatársai független szakértık bevonásával értékelték. A pontozás 0-10-ig történı skálán történt. Az értékelık nem ismerték a súlyokat, azok elızetes ismerete nélkül pontoztak. Minden értékelı önállóan pontozott. A pontokat összesítettük, majd átlagoltuk, és így súlyoztuk az egyes kérdésekre adott válaszokat. Az alábbi táblázat összefoglalja az eredményeket.


101

BME IK

Tényezı

Súly

HP

IBM

MS

OR

Red

Sun

1.

SOA technológiai modell (blokk diagram)

30

150

246

198

246

210

294

2.

Többszörözött szolgáltatás tárak létrehozása

50

460

150

280

440

370

440

3.

Szolgáltatás publikáció módjai

80

688

512

544

672

640

768

4.

Magas szintő rétegzett „alkalmazásfejlesztı környezet” ismertetése

50

330

270

390

350

250

490

5.

Szolgáltatás leíró szerkesztése / modellezése (GUI fejlesztı környezet)

50

360

330

390

390

330

480

6.

Kérési sorok összeállításának lehetısége (GUI fejlesztı környezet)

50

410

460

400

430

460

490

7.

Összetett szolgáltatások létrehozása elemi szolgáltatásokból – workflow wizard

50

410

440

370

410

440

490

8.

Fejlesztı rendszer

50

370

430

370

460

250

470

9.

xml / soap /wdsl specifikumok

30

240

294

240

270

258

288

80

384

688

144

752

704

800

11. Workflow programozhatósága (nyelvek, BPEL, JAVA stb.)

100

420

900

580

400

660

960

12. Skálázhatóság / üzembiztonsági elemek / redundancia

150

510

1050

810

1380

1320

1500

13. Kommunikációs modell ismertetése (blokk diagram)

50

80

440

230

400

370

440

14. Szolgáltatás tárak meghajtási módja

30

48

108

204

276

258

282

100

620

540

720

860

500

1000

16. RSA / PKI / biometrikus azonosítási rendszerek támogatása

30

186

192

240

276

240

264

Szolgáltatás igénybevételéhez szükséges - Jogosultsági szintek deklarációja – mint 17. szolgáltatási attribútum (hitelesítési meta-adat)

80

48

224

640

608

592

768

18. Támogatott hitelesség ellenırzési módszerek

30

216

0

198

246

258

240

19. Támogatott elektronikus fizetési módok

50

240

0

440

400

410

390

20. A legfontosabb hazai, külföldi kormányzati, közigazgatási referenciák (nagy rendszerek)

200

1120

1920

1360

1440

360

1800

21. A legfontosabb hazai, külföldi további referenciák (nagy rendszerek)

100

240

980

520

840

220

1000

7530

10174

9268

11546

9100

13654

10. Kompatibilitás más gyártók termékeivel (adatbázis szerverek, operációs rendszerek)

Publikált szolgáltatások mérhetısége (igénybevétel, futásidı), szolgáltatások minıségi 15. paramétereinek mérése (állásidı, késleltetés)

Összesen


102

BME IK

8.2.

A keretrendszerek együttmőködésének összefoglalása

A második tesztágyon végzett tesztelés igazolta, hogy a keretrendszerek együtt tudnak mőködni, és sikeresen tudnak kommunikálni, amennyiben semmilyen WS-* szabványt nem alkalmazunk. A szabványok támogatását tekintve az egyes termékek változó színvonalúak. Csaknem az összes teszt lefutott az Open ESB, az IBM WebSphere és a Microsoft Windows Communication Foundation rendszerekben. Közöttük az interoperabilitás is jobb az egyes szabványok használata esetén. Az Axis2 tesztelésénél feltőnı hiba volt, hogy a hozzá tartozó szerveren csak egységesen lehet engedélyezni néhány szabványt, így például az MTOM kódolást és a WS-Addressing használatát is. Így a feladatok külön-külön tökéletesen megoldhatóak vele, viszont egyszerre nem lehet az összeset helyesen mőködtetni. A JBoss eszköz sajnos kevés szabványt támogat, így teljesen helyesen csupán az alap számológép mőködik, illetve a WS-Addressing 1.0-s verzióját használó változata. A szerveren nincs HTTPS port, az MTOM kódolással küldött üzenetek feldolgozása hibásan zajlik, illetve SOAP hiba esetén a hibát nem dolgozzák fel, hanem továbbdobják a kliensek. Open ESB használatával az összes feladat megoldható, leszámítva a tranzakciókezelést SOAP 1.2-es binding esetén. Ebben az esetben nem képes a GlassFish szerver a tranzakció koordinálásával kapcsolatos, WS-Coordination szerinti üzenetek küldésére és fogadására. Az Oracle 10g-vel ismételten csak az alap web-szolgáltatások mőködnek. A hibakezelés SOAP 1.2 esetén már nem mőködik, még WS-Addressing sincs, viszont a SOAP 1.1-es bankos alkalmazás, valamint az MTOM kódolással történı üzenetküldés helyesen mőködik. Az Oracle 11g-s verziójával készített web-szolgáltatások közül a WS-ReliableMessaging esetén a kommunikáció nem záródik le, WS-Security, HTTPS és tranzakciókezelés pedig nincs. A többi szolgáltatás, illetve kliens azonban tökéletesen mőködik másokkal együtt is. Az Oracle WebLogic-kal két fajta megoldás is rendelkezésre állt több tesztesethez, mivel a feladatsor itt elkészült JAX-WS és JAX-RPC használatával. A JAX-RPC-t használó megoldáshoz tartozó kliensek a teszteléskor hibásak voltak, mivel az általuk visszaadott válasz névtere nem volt a specifikációnak megfelelı. Az alap web-szolgáltatások képesek az együttmőködésre tökéletesen a többi keretrendszerrel, a WS-ReliableMessaging-et használó számológép azonban már nem tud kapcsolatot létrehozni, biztonságos üzenetküldés nincs, valamint az Oracle szerver miatt probléma van abban az esetben, ha SOAP 1.2 esetén kivétel keletkezik. Ezt ugyanis a szerver nem tudja átalakítani szabványos SOAP hibává. Emiatt a banki szolgáltatásból is csak a SOAP 1.1-es verzió mőködik, és tranzakciókezelés ebben a keretrendszerben sem áll rendelkezésre. A Microsoft Windows Communication Foundation sajátossága a többi rendszerhez képest, hogy ebben nem Java nyelven, hanem C#-ban íródtak a szolgáltatások. Ebben is megoldható BME IK

103

BME IK

az összes feladat, egyedül a tranzakciót használó banki szolgáltatás használja a szabvány egy másik verzióját, mint az Open ESB-s. A SUN web-szolgáltatás-keretrendszer implementációja a Metro kódnevő projekt, amelynek célja a web-szolgáltatások közötti kommunikáció optimalizációja, a megbízhatóság, valamint a biztonságos üzenetküldés biztosítása. A Metro része a WSIT projekt (Web Services Interoperability Technologies), amelyben szorosan kooperálva a Microsoft-tal folyamatos teszteknek vetik alá a két gyártó implementációját. Ennek köszönhetıen a WCF és az Open ESB közötti együttmőködés majdnem az összes WS-* szabvány esetén tökéletes, egyedül a tranzakciókezelést használó banki szolgáltatás nem mőködik együtt. Az IBM Rational Application Developer for WebSphere Software is alkalmas az összes feladat elvégzésére. Az Open ESB-vel és a WCF-fel majdnem teljesen képes együttmőködni. A biztonságos üzenetküldés megvalósítása hiányzik benne, illetve a WS-ReliableMessaging csak a WCF-fel mőködik együtt, Open ESB-t hívva nem lehet lezárni a kommunikációt. A tranzakciót használó bankos szolgáltatás pedig ennél a rendszernél is csak magával mőködik együtt. Összességében elmondható, hogy a tesztelés megmutatta az egyes rendszerek hibáit és korlátait. Valószínőleg egy-egy megoldást tökéletesíteni lehetne még több rendszerben is, mivel néhol csak apró problémák voltak az együttmőködés során.

8.3.

A keretrendszerek konfigurációinak megfeleltetése egymással

A vizsgált keretrendszerek telepítésére és a WS-* szabványok konfigurálására vonatkozó részletes leírások megtalálhatók a – harmadik munkaszakaszban – átadott [11] dokumentációban. A hivatkozott 391 oldalas anyag az alábbi táblázatban közreadott telepítési útmutatókat és konfigurálási leírásokat tartalmazza. Install-ActiveBpel Problems-ActiveBpel BpelCalculator-ActiveBpel BpelTransfer-ActiveBpel Install-Asix2 Problems-Axis2 WsHttp-Axis2 WsHttps-Axis2 WsAddr-Axis2 WsRm-Axis2 WsSc-Axis2 WsTrust-Axis2 WsFault-Axis2 WsAsync-Axis2 WsMtom-Axis2 WsBank-Axis2 BME IK

Install-OracleOc4j WsHttp-OracleOc4j WsHttps-OracleOc4j WsAddr-OracleOc4j WsRm-OracleOc4j WsSc-OracleOc4j WsTrust-OracleOc4j WsFault-OracleOc4j WsAsync-OracleOc4j WsMtom-OracleOc4j WsBank-OracleOc4j WsAt-OracleOc4j Admin-OracleOc4j Install-OracleSoa WsHttp-OracleSoa WsFault-OracleSoa 104

BME IK

WsAt- Axis2 Admin-Axis2 WsHttp-BeaWebLogic WsMtom-BeaWebLogic Install-JBoss WsHttp-JBoss WsAddr-JBoss WsRm-JBoss WsFault-JBoss WsAsync-JBoss WsMtom-JBoss WsBank-JBoss Install-OpenEsb Problems-OpenEsb WsHttp-OpenEsb WsHttps-OpenEsb WsAddr-OpenEsb WsRm-OpenEsb WsSc-OpenEsb WsTrust-OpenEsb WsFault-OpenEsb WsAsync-OpenEsb WsMtom-OpenEsb WsBank-OpenEsb WsAt-OpenEsb BpelCalculator-OpenEsb BpelTransfer-OpenEsb Admin-OpenEsb

WsMtom-OracleSoa WsBank-OracleSoa WsHttp-OracleWebLogic WsMtom-OracleWebLogic Install-Wcf Problems-Wcf WsHttp-Wcf WsHttps-ToolId WsAddr-Wcf WsRm-Wcf WsSc-Wcf WsFault-Wcf WsAsync-Wcf WsMtom-Wcf WsBank-Wcf WsAt-Wcf Admin-Wcf Install-WebSphere Problems-WebSphere WsHttp-WebSphere WsHttps-WebSphere WsAddr-WebSphere WsFault-WebSphere WsAsync-WebSphere WsMtom-WebSphere Install-Caps WsHttp-Caps WsBank-Caps

Általános tapasztalatunk, hogy a különbözı keretrendszerek konfigurálási lehetıségei lényegesen eltérnek egymástól. Az egyik keretrendszer konfigurációjából általános szabályok alapján nem nyerhetı ki egy másik keretrendszer konfigurációja. Pontosan ezen okból választottuk azt a megoldást, hogy az alkalmazások fejlesztés során egy egységes magasszintő UML modellbıl kiindulva a keretrendszertıl függı egyedi kódgenerátorokkal készíttetjük el a szükséges definíciókat és konfigurációs fájlokat. Meglátásunk szerint a keretrendszerek interoperabilitási gyengeségei és az egységes elvek alapján történı konfigurálás hiánya szorosan összefüggenek egymással. Várhatóan az interoperabilitás javulásával a konfigurálás nehézségei is csökkenni fognak.

BME IK

105

BME IK

9. SOA keretrendszerek az e-Közigazgatásban A vizsgált keretrendszereket a kormányzatokban és a közigazgatásban is alkalmazásba vették. A Red Hat és SUN biztonsági okokra hivatkozva nem adott meg referenciákat, de a többi szállító jelentıs referenciákkal rendelkezik. Az alábbi táblázatban összefoglaljuk ıket.

9.1.

HP

AGES (national agency for the management of the communal secretaries registry) Adaptive Enterprise Service-oriented Architecture (SOA),Public Sector (PUB), Enterprise Application Integration (EAI),Security HP External Reference Italy May 11, 2004 Capital & Coast District Health Board HP Services Healthcare, Service-oriented Architecture (SOA), Business Process Workflow HP External Reference New Zealand Jun 13, 2007 Cheshire Building Society Adaptive Enterprise, Service-oriented Architecture (SOA), Financial Industries (FIN) HP External Reference United Kingdom Jun 01, 2004 Defense Information Systems Agency (DISA) Adaptive Infrastructure, HP OpenView, HP Services, Service-oriented Architecture (SOA) HP External Reference United States Oct 31, 2006 Municipality of Rome Adaptive Enterprise, HP Services, Itanium Business Continuity & Availability, IT Consolidation, Service-oriented Architecture (SOA) HP External Reference Italy Apr 28, 2004 The Office of the Government Chief Information Officer (OGCIO) HP Services, Microsoft Enterprise Microsoft Architecture, Service-oriented Architecture (SOA), E-Commerce HP External Reference Hong Kong,Apr 28, 2007

9.2.

IBM

UK Government Gateway: az Egyesült Királyság kormányzatának egységes, központosított folyamatkezelı rendszere. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=51003 Bulgár Kormányzati online szolgáltatások: az EU csatlakozás elıtt Bulgáriának legalább 20 online szolgáltatás kellett nyújtani polgárai számára. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=52373 Egyiptomi elektronikus kormányzati szolgáltatások: a kormányzat legtöbb szolgáltatásának online kiszolgálása egységes belépéssel és felhasználó központú felülettel. http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=53349 Cseh Informatikai Minisztérium: három év alatt 50.000 felhasználó, 800.000 ügy és 1.000.000 őrlap. BME IK

106

BME IK

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201262 Integrált közszolgáltatások keretrendszer (Connected Government Framework) országos Nagy Britannia, Olaszország, Dánia, Portugália, Csehország, Szlovénia, Horvátország, Szlovákia, Litvánia, Málta, Románia, Bulgária, Egyiptom, Izrael, Kolumbia, India, Thaiföld regionális, Olaszország, Ausztria, Svájc, Németország, Spanyolország, India, önkormányzati Indonézia, Latin-Amerika, Svédország, Lettország, Egyesült Államok

9.3.

Oracle Hazai UKIG NHH Schengen BM

BME IK

Külföldi Helth Canada European Sapce Agency US Navy InterAccess Qfleet, City of Rotterdam Avue Technologies FAA NASA Norwegian Ministry of justice and Police NTIA OSM Philadelphia Housing Authority Shanghai Biotech Center Skat Denmark State of Iowa Toll Collect Korea Customer Service GeoScout Dutch Ministry of Agriculture AMF France

107

BME IK

10. Útmutató további SOA keretrendszerek vizsgálatához A második tesztágy, illetıleg a vele kapcsolatosan kidolgozott mintafeladatok és az elkészített tesztelı keret alkalmas arra, hogy a keretrendszerek új verzióinak és új szállító új termékének vizsgálatát is elvégezzük. Ennek oka az, hogy a tesztágy célja az együttmőködés, az interoperabilitás vizsgálata. Amennyiben az új keretrendszer a WS-* szabványok szerinti elemi mőködésre képes, http(s)-n tud kommunikálni, akkor az a vizsgálatba bevonható. A tesztelı keretprogram komponensei lecserélhetıek, és külön-külön használhatóak. Így a meghívott végpont kódját lecserélve ugyanúgy használható az eszközöket reprezentáló, valamint a kiíró osztály abban az esetben is, ha a meghívandó végpont WSDL-je más, vagy akár ha más feltételek esetén minısülne sikeresnek egy teszt. Az elkészített program jelen változata nem képes a szolgáltatások és kliensek közötti SOAP üzeneteket vizsgálni (ennek technikai korlátai vannak), így gyakorlatilag csak további felügyelettel lehet megállapítani, hogy valóban helyes protokollal kommunikáltak-e a felek. További javítási lehetıség lenne egy grafikus felhasználói felület készítése a tesztelı programhoz. Ezen keresztül lehetne kiválasztani a tesztelni kívánt rendszereket, a tesztelendı feladatokat. Így lehetne grafikus felületen új keretrendszert létrehozni, a végpontok címét módosítani, valamint új tesztelendı feladatot definiálni. Új keretrendszerek vizsgálata esetén mérlegelendı ez a bıvítés.

BME IK

108

BME IK

Irodalomjegyzék [1]

OASIS: SOA Reference Model http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm utolsó hozzáférés: 2008.04.20.

[2]

Simon B., Dr. László Z., Dr. Goldschmidt B.: SOA mintarendszer kialakításának tapasztalatai, Networkshop 2008, Dunaújváros, 2008. március 17-19.

[3]

B. Simon, Z. László, B. Goldschmidt: SOA Interoperability, a Case Study, Proceedings of the IADIS International Conference, Informatics 2008, Amsterdam, The Neatherlands, July 25-28, 2008. pp. 131-138.

[4]

Simon B.: Mintarendszer készítése szolgáltatás alapú architektúrán, MSc diplomaterv, BME VIK, 2008

[5]

.NET StockTrader Sample Application, http://msdn2.microsoft.com/huhu/netframework/bb499684(en-us).aspx

[6]

JAX-WS RI 2.1 benchmark details, http://weblogs.java.net/blog/kohsuke/archive/2007/02/jaxws_ri_21_ben.html

[7]

„Oktatási feladatok” dokumentáció EKK_Oktatasicsomag_OktatasiFeladatok_V1.doc

[8]

Kovács Gy.: BEA, OpenESB, Caps rendszerek WS-* szabványok szerinti megfelelıségének vizsgálata, BSc szakdolgozat, BME VIK, 2008

[9]

Hartung I.: BEA és OpenESB rendszerek WS-* szintő interoperabilitásának vizsgálata, BSc szakdolgozat, BME VIK, 2008

[10] Budai P.: IBM SOA rendszer WS-* szabványok szerinti megfelelıségének és BPEL kompatibilitásának vizsgálata, BSc szakdolgozat, BME VIK, 2008 [11] „SOA alapú tesztágy integrációs kísérletekre” szoftver dokumentáció EKK_ekozig_SOA_alapu_tesztagy_080922_V2.pdf

BME IK

109

SOA KERETRENDSZEREK ÖSSZEHASONLÍTÓ

Recommend Documents