(SOA) WSDL

Átírás

1 Tartalomjegyzék 1. Bevezetés Szolgáltatás-Orientált Architektúra (SOA) Webszolgáltatások WSDL (Web Services Description Language) Részei types natív (primitív) adattípusok saját (custom) adatípusok porttype message binding port service SOAP (Simple Object Access Protocol) Header mustunderstand attribútum actor attribútum Body Fault SOAP 1.1 With Attachments XOP és MTOM XOP (XML-Binary Optimized Packaging) MTOM (Message Transmission Optimization Mechanism) UDDI (Universal Description, Discovery, and Integration) WS-Security Biztonság a szállítási rétegben Message Level Security (WS-Security vagy WSS) Timestamp Username Token PasswordText PasswordDigest Signature WS-BPEL 2.0 (Web Services Business Process Execution Language) SOA Java EE platformon JBI (Java Business Integration)

2 Előzmények JBI komponensek Service Engine (SE) Binding Component (BC) Üzenetkezelés WSDL alapú üzenetmodell Normalizált Üzenet Normalizált üzenetcsere NMR (Normalized Message Router) Menedzsment OpenESB Komponensek Service Engine Binding Component GlassFish alkalmazásszerver Sun Java CAPS (Composite Application Platform Suite) Integrációs termékek Infrastruktúrát biztosító termékek Fejlesztőeszközök JAXP Java API for XML Processing SAX (Simple API for XML) StAX (Streaming API for XML) Iterator API Cursor API JAX-WS 2.0 (JSR 224) WS, mint web komponens WS, mint üzleti logika komponens Annotációk javax.jws.webservice...42 javax.jws.webmethod...42 javax.jws.webparam...42 javax.jws.webresult javax.jws.soapbinding WebServiceContext RequestContext Apache CXF WSS4J Kulcsgenerálás JAXB (Java Architecture for XML Binding) 2.0 (JSR 222)

3 4.9. NetBeans Modulok BPEL module Composite Application projekt (CAPS) SQL module XSLT module Request-Reply Service Service Bridge IEP (Intelligent Event Processing) module (OpenESB) Egyéb modulok File Binding Component SMTP Binding Component FTP Binding Component SOAP (HTTP) Binding Component JDBC Binding Component JMS Binding Component BPEL Designer BPEL nézetek BPEL Mapper Palette BPEL Navigator WSDL Editor XML Schema Editor Támogatott tervezési minták (Design Patterns): Russian Doll Salami Slice Venetian Blind Garden of Eden Mintaalkalmazások Apache CXF cxf-jaxws cxf-simple cxf-sec-un cxf-sec-sig OpenESB BPEL Előkészületek BPEL folyamat Kompozit alkalmazás Tesztelés, Ellenőrzés

4 soapui TCPmon

5 1. Bevezetés A Szolgáltatás-Orientált Architektúra (SOA), sokszor mint buzzword 1 él a köztudatban. Legtöbbször felkapott, kisarkított, valós tartalom nélküli marketing promóciókban találkozhatunk a koncepcióval, pedig jóval többről van szó. Az integrációs kényszer, az alkalmazások növekvő méretének és funkcionalitásának kezelése egyre több erőforrást, időt és pénzt emészt fel, ami hosszú távon megengedhetetlen. Ennek megoldását tűzte ki célul a SOA, de leginkább annak konkrét megvalósításai, implementációi. Egyetlen komoly informatikai cég sem mehet el ezen problémák mellett, és nem hagyhatja figyelmen kívül a SOA implementációk nyújtotta előnyöket. Jóval többről van szó, mint technológiai átszervezésről, itt a szemléletmódról, a kifejlesztett koncepcióról, és annak alkalmazásáról van szó. A diplomamunkámban bemutatom az elképzelés főbb irányvonalait, illetve a Java platform sokrétű, magas szintű képességeit. A második fejezet bepillantást enged a SOA alapfelvetésébe, főbb tulajdonságaiba, és előnyeibe. A harmadik fejezetben áttekintem a SOA legkézenfekvőbb megvalósítójaként számon tartott webszolgáltatásokat, és azok alappilléreit, kiegészítő,- és támogató technológiáit. A piacon elterjedt szabványos, platformfüggetlen megoldásokat foglaltam össze ebben a részben. Bemutatom továbbá a webszolgáltatások egyik legfontosabb tényezőjét, a különböző biztonsági eljárásokat, a későbbi fejezetekben pedig azok alkalmazásait is. A negyedik fejezet a Java platform által nyújtott lehetőségekről szól. A legmagasabb absztrakciós szinttől (Java Business Integration) haladva, a konkrétabb, utóbbi megvalósításán (OpenESB) át a webszolgáltatások, és azok alapját képező XML feldolgozásig bezárólag térképeztem fel a platform funkcióit. Ebben a fejezetben kapott helyet a NetBeans integrált fejlesztőeszköz (IDE) célspecifikus funkcióinak leírása is. Az ötödik fejezet a kifejlesztett (minta)alkalmazások bemutatásáról szól, ami a platform és a NetBeans által nyújtott lehetőségek egy szűk részhalmazát veszi górcső alá. 1 buzzword = divatszó, divatos/felkapott szakkifejezés 7

6 2. Szolgáltatás-Orientált Architektúra (SOA) [1], [2] és [3] alapján. A Szolgáltatás-Orientált Architektúra (Service Oriented Architecture), vagy röviden SOA mint újrahasznosítható tervezési mintát, architektúrális koncepciót lehetne legjobban jellemezni. Alapja a rendszerek közti laza csatolás, ezáltal elérhető az egymástól való függés minimalizálása, ami gyártófüggő megoldások között egy kritikus szempont. SOA jellemzői: Szabványok alkalmazása Lazán csatoltság Újrafelhasználhatóság és hozzáférhetőség Szolgáltatásleírás Interfészek Üzenetek, és üzenetcsere módja Folyamatok interakciója Szinkron/Aszinkron A gyorsan változó üzleti élethez gyors és költséghatékony alkalmazkodást kell biztosítania az IT-nek. Reagálnia, válaszolnia kell, akár a meglévő alkalmazások módosításával, licencelésével, akár újak kifejlesztésével. Az integrációs szükség robusztus nagyvállalati (enterprise) környezetben egyre több időt és pénzt emészt fel. Ezáltal a meglévő, sokszor kamra fejlesztések (silók), az egyedi integrációs megoldások, és az ezek járulékos következményeként az üzemeltetést/módosítást végző guruk leváltása egyre égetőbb szükséggé válik. A heterogén rendszerek kommunikációjának biztosítására egy megfelelő, közel minden részletre alkalmazkodó, de az eddigi megoldásoknál feltétlen jobb, általánosítottabb megoldásra próbál választ adni a SOA. SOA definíció: A Service Oriented Architecture (SOA) egy integrált szoftver infrastruktúra és tervezési megközelítés, amely eszközként használja fel a web technológia szabványokat üzleti funkcionalitás és megosztott szolgáltatások megvalósítására. [4] Különböző szolgáltatások összefogása a cél, az üzleti (külső) kényszer mentén. A szolgáltatások kommunikációja és összehangolása (orchestration) nem szállítófüggő (vendor lock-in), szabványos elemekből épül fel. 8

7 1. ábra. SOA előtt és SOA után Forrás: A SOA alkalmazások segítségével a megvalósítandó üzleti folyamatok költségének és komplexitásának csökkentésével egyszerűbbé válik azok menedzsmentje és újrafelhasználhatósága. A komponensek (legtöbbször heterogén alkalmazások) mint szolgáltatások, igénybe vehető üzleti folyamatokként jelennek meg. A SOA a teljes vállalati működésre hatással van, ami a szigetmegoldások teljes leváltásával ez törvényszerű. Szolgáltatásalapú rendszer bármi lehet, ami az alapelveket maradéktalanul teljesíti, például MoM, a legelterjedtebb mégis a webszolgáltatások (amik nyelvfüggetlenek, szabványokon alapulnak, valamint gyors fejlesztést tesznek elérhetővé). Szükséges továbbá egy kommunikációs busz (Enterprise Service Bus ESB), illetve a szolgáltatásösszehangoló karmester (orchestration) motor, aminek segítségével a komponensek egymás szolgáltatásait használhatják, kéz-a-kézben. Ezek (ahogy az összes többi is) elvek, koncepciók, architektúrák. Konkrét specifikáció például a JBI vagy a BPEL. Előnyök: Költségek csökkentése Meglévő alkalmazások funkcionalitásainak újrafelhasználása Fejlesztők termelékenységének növelése Üzemeltetési hatékonyság növelése Adatmegosztás divíziók, részlegek közt Gyakori üzleti folyamatok automatizálása Új üzleti lehetőségek kifejlesztése 9

8 Új és jobb szolgáltatások az ügyfél felé Gyorsabb reakció a piac változásaira Gartner: 2008-ig a vállalatok több, mint 60%-a a SOA elvei szerint építi majd üzletileg kritikus rendszereit és alkalmazásait. [5] Open Source SOA: Előnye az alacsony belépési költség, biztosítja az átlátszóságot. Közösségi innovációknak ad lehetőséget, de mégis ezek a rendszerek tipikusan a zárt, és nyílt forrású megoldások egyvelege. A kormányzati rendszerek nagy részében már most találhatók nyílt forrású megoldások (Apache, Sendmail, Linux, MySQL, Perl). SOP (Service Orchestration Point): üzleti folyamat hosztolása, ami közvetít a különböző, heterogén szolgáltatások között. SOA előnyök különböző nézőpontokból: Chief Financial Officer CFO (Pénzügyi igazgató) Gyorsabb befektetési megtérülés, ROI (Return of Investment). Developers (Fejlesztők) Kevesebb karbantartás, magasabb produktivitás. Business Analyst (Üzleti elemzők) Folyamatok és szolgáltatások újrafelhasználása. Chief Information Officer CIO (Informatikai vezető) Gyorsabb piacra lépés, kevesebb hátralévő munka. Line of Business LoB (Szervezeti üzletágrendszerek) Gyorsabb reagálás az üzleti igényekhez. Chief Technology Officer CTO (Technológiai igazgató) Meglévő infrastruktúra felhasználása, jövőbeli projektek alapjainak definiálása. A SOA segítségével az üzleti megközelítésből származó legfőbb cél, a meglévő infrastruktúrából származó integrációs költségek (Cost of Integration),- és az összes költség (TCO) csökkentése elérhetővé válik. Közelebb hozza az üzleti és technológiai folyamatokat. Üzleti folyamat: Az az út, ahogy a cég eléri a nagyobb üzleti célt. Megfelelő sorrendben végrehajtott egyedi task-ok sorozata. A SOA az IT természetes fejlődési útjának egy következő lépcsője. 10

9 3. Webszolgáltatások Hálózaton keresztül elérhető szolgáltatások, műveletek létrehozását teszi lehetővé, interfész alapokon, XML üzeneteken keresztül. Rugalmas, skálázható, módosítható alkalmazások készíthetők segítségével. Nyílt szabványokat és protokollokat alkalmaz, biztosítja az együttműködést (interoperability). A fekete doboz alapú tervezés elfedi megvalósításának részleteit, a metódusok meghívása interfészeken keresztül történik. Tipikusan állapotmentes, implementációs nyelvtől és platformtól független, lazán csatolt, komponens szemléletű, üzenetalapú. Ugyanúgy ahogy az igénybe vevő sem tud semmit a szolgáltatás konkrét implementációs részleteiről, úgy az igénybe vett szolgáltatásnak sem kell semmit tudni az őt igénybe vevőről. Így elérhető a lazán csatolt komponensekből felépülő alkalmazások kifejlesztése. 11

10 3.1. WSDL (Web Services Description Language) WSDL (Web Services Description Language) [6] és [7] alapján. Szolgáltatások leírás XML nyelven, platform,- és implementációs nyelvtől függetlenül, szabványos módon. Kommunikációs végpontokat (port) definiál, továbbá: műveletek és üzenetek absztrakt definiálása binding szállítási (hálózati) protokollokhoz és üzenetformátumhoz (SOAP over HTTP) Gépek által (is) olvasható, értelmezhető. A partnerek között automatikus a műveletleírás,- és hívás, a felderítés Részei A <definition> gyökérelem gyermekei types A felhasznált adattípusokat (XML schema elemek) definiálja natív (primitív) adattípusok Például: <element name="mystring" type="string" /> (A teljes lista megtalálható itt: saját (custom) adatípusok Például a Customer objektum leírása: <complextype name="customer"> <sequence> <element name="customerid" type="int" minoccurs="1" /> <element name="firstname" type="string" minoccurs="1" /> <element name="lastname" type="string" minoccurs="1" /> </sequence> </complextype> A minoccurs és a maxoccurs szabályozza az elemek számát a sequence-ben. (pl.: minoccurs = 0 opcionális az elem) Természetesen nem csak beágyazva lehet a sémákat definiálni, meglévőket a következő módszerrel lehet importálni: <import namespace="[névtér URI]" schemalocation= "[.XSD fájl elérési útvonala]" />

11 3.1. WSDL (Web Services Description Language) porttype A webszolgáltatás absztrakt interfészdefinícióját tartalmazza, például: <wsdl:porttype name="customerporttype"> <wsdl:operation name="findcustomer"> <wsdl:input message="tns:findcustomer" /> <wsdl:output message="tns:findcustomerresponse" /> <!-- lehet még fault üzenet is </wsdl:operation> </wsdl:porttype> message A kommunikáció során használt üzenetek absztrakt leírása (input, output, hiba). <wsdl:message name="getcustomerresponse"> <wsdl:part element="tns:getcustomerresponse" name="customer"/> </wsdl:message> Bevált szabály a műveletek nevének felhasználása: művelet_név+request/response binding Definiálja, hogy az absztrakt porttype hogyan képződik le konkrét megvalósításokra (adatformátumokra, protokollokra). A legelterjedtebb a HTTP feletti SOAP. <wsdl:binding name="customerservicesoap" type="tns:customerporttype"> <soap:binding style="document" transport=" /> <wsdl:operation name="findcustomer"> <soap:operation soapaction="" style="document" /> <wsdl:input> <soap:body parts="findcustomer" use="literal" /> </wsdl:input> <wsdl:output> <soap:body parts="findcustomerresponse" use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> port A szolgáltatás-végpont (endpoint) leírása. URL, ahol a szolgáltatás található. <wsdl:service name="customerservice"> <wsdl:port binding="tns:customerservicesoap" name="customerservicesoap"> <soap:address location=" /> <soap:address location=" /> </wsdl:port> </wsdl:service>

12 3.1. WSDL (Web Services Description Language) service Szolgáltatások, port-ok gyűjteménye, több elérhetőségi címet adhatunk meg azonos szolgáltatáshoz.

13 3.2. SOAP (Simple Object Access Protocol) SOAP (Simple Object Access Protocol) 1.1 [8] és [9] alapján. Lightweight 2, XML alapú kommunikációs protokoll, a strukturális adatcsere módját definiálja. Elosztott, decentralizált környezetben tesz lehetővé információcserét. Egyszerű és kiterjeszthető. Széles körben használható különböző szállítási protokollokkal (protocol binding), a HTTP-t kifejezetten támogatja. Az üzenetek általában egyutasak (one-way), de kiterjeszthetők akár kérés/válasz, vagy multicast alapúra is. Részei: (3) 1. SOAP Envelope XML gyökérelem, az üzenet tartalmáról,- és feldolgozásáról tartalmaz információkat.. SOAP-ENV névtér : Header (opcionális) Body Fault (opcionális) 2. SOAP RPC representation Konvenció távoli eljáráshívások és válaszok ábrázolására 3. SOAP encoding rules Szerializációs mechanizmus az alkalmazások által definiált adattípusokra. SOAP-ENC névtér: Lehet: egyszerű összetett Szerializáció: Az alkalmazás adattípusainak SOAP-XML-re fordítása. Visszaalakítása: deszerializáció Header Kiegészítő, vezérlő információkat tartalmaz. Az üzenettovábbítási láncon lévő nodeoknak szolgáltathat információkat (pl.: autentikáció, tranzakciókezelés, prioritáskezelés). Az üzenet a feladótól (origination) származik, a címzett (destination) részére közbülső csomópontokon is áthaladhat (intermediaries), amik a SOAP üzenet egyes részeit dolgozhatják fel (pl.: biztonság (trusted domains), értéknövelt szolgáltatások, skálázhatóság, ). 2 Lightweight = könnyűsúlyú

14 3.2. SOAP (Simple Object Access Protocol) mustunderstand attribútum Definiálja, hogy a fogadónak fel kell-e dolgoznia az elemet. Lehetséges értékei: true: kötelező feldolgozni a definiált séma alapján, vagy hiba generálása false: vagy nem szerepel: nem kötelező feldolgozni, de fel lehet actor attribútum Melyik közbülső csomópontnak szól, a header elem címzettje, értéke URI. A csomópontok a feldolgozás után törlik a rájuk vonatkozó bejegyzéseket, illetve további header bejegyzéseket helyezhetnek el az üzenetben. Speciális URI: Közvetlenül az első (következő) node-nak szól. Ha hiányzik, az elemet a végső címzett dolgozza fel Body A SOAP üzenet magja, maga a konkrétum (üzenet). Tartalma alkalmazásspecifikus. Bináris adatok szállítása base64 kódolással: xsi:type="soap-enc:base Fault A szolgáltatáshoz kapcsolódó hibákat reprezentálja. Alelemek: faultcode A hiba kódja, gépi feldolgozás számára. faultstring Értelmezhető hibaüzenet. faultactor A hiba forrása, tartalma URI. detail Alkalmazásspecifikus hibaüzenet (például hiba az üzenet tartalmának - body - feldolgozása közben). Ha a fejlécben van a hiba, az elem nem jelenik meg. Így különíthető el a hiba oka (header/body). Előre definiált hibakódok (prefixek): VersionMismatch Az envelope elem névtere érvénytelen. MustUnderstand A címzett nem tudja értelmezni a megfelelő (mustunderstand = 1 ) header blokkot. Client Kliensoldalon történt hiba. Server Hiba a szerver oldalon, formátumtól, tartalomtól független. Lehet, hogy ugyanaz az üzenet később sikeres lesz.

15 3.2. SOAP (Simple Object Access Protocol) SOAP 1.1 With Attachments Kiegészítés, lehetővé teszi bináris adatok, például képek továbbítását MIME Multipart/ Related struktúrában. Független a szállítási protokolltól. További információ:

16 3.3. XOP és MTOM XOP és MTOM [10] és [11] alapján. Két lehetőség bináris adat küldésére XML-ben: beágyazás (base64 kódolás) megnövekedett méret overhead hivatkozás (SOAP with Attachments) a dokumentumon kívül helyezkedik el, nem része az üzenetnek XOP (XML-Binary Optimized Packaging) Az XML információhalmaz (XML Infoset) szerializációja, W3C ajánlás, mely definiálja a bináris adatok tárolását XML tag-ekben. A bináris,- és szöveges információt tartalmazó konténer az XOP Infoset. További információ: MTOM (Message Transmission Optimization Mechanism) Az XOP alkalmazása SOAP/HTTP-re. További információ:

17 3.4. UDDI (Universal Description, Discovery, and Integration) UDDI (Universal Description, Discovery, and Integration) [12] alapján. Szolgáltatások felderítésének (discovery) és publikálásának (publish) szabványos leírására használható platformfüggetlenül, API-n keresztül programozhatóan. Alapja az XML, SOAP, HTTP. Kereshető, web alapú, megosztott, elérhetővé teszi a dinamikus szolgáltatásfelderítést. A tárolt információk a következő csoportokba tartozhatnak: business registrations (üzleti entitások) fehér oldalak: általános információk sárga oldalak: kategorizált zöld oldalak: technikai információk service type definitions (metainformációk) Java támogatás: JAXR (Java API for XML Registries)

18 3.5. WS-Security WS-Security [13], [14], [15], [16] és [17] alapján. OASIS specifikáció, a webszolgáltatásokra alkalmazható biztonsági lehetőségeket definiálja. A specifikáció megtekinthető a következő oldalon: Biztonság a szállítási rétegben Transport Level Security TLS. Tulajdonságok: Basic Authentication BASIC-AUTH böngésző bejelentkező ablak felhasználó:jelszó páros, base64 kódolás Secure Socket Layer SSL Az alkalmazás,- és szállítási réteg között helyezkedik el. HTTPS HTTP over SSL titkosított protokoll szerver, (kliens) autentikáció CA (Certificate Authority) segítségével SSL probléma: Az üzenetet közbülső csomópontok is feldolgozhatják, így nem működik SOAP környezetben, pont-pont kapcsolatra van felkészítve, illetve az egész üzenetet titkosítja Message Level Security (WS-Security vagy WSS) Fejlett biztonsági megoldás, használata független a TLS-től. Magát az üzenetet (SOAP envelope) védi, a különböző biztonsági információk a SOAP header-be kerülnek, ezáltal több csomópont is használhatja a header-ben található információkat. Lehetséges biztonsági megoldások:... Timestamp Username Token Signature Encryption Timestamp Az üzenet érvényességét definiálja. (A példában 60 másodperc.)

19 3.5. WS-Security 21 <wsse:security soapenv:mustunderstand="1" xmlns:wsse=" wss-wssecurity-secext-1.0.xsd"> <wsu:timestamp wsu:id="timestamp " xmlns:wsu=" <wsu:created> t13:34:15.902z</wsu:created> <wsu:expires> t13:35:15.902z</wsu:expires> </wsu:timestamp> </wsse:security> Username Token Név és jelszó párossal védi az üzenetet. A jelszó szállítása történhet nyílt, szöveges módon (PasswordText), vagy valamilyen hash függvénnyel (pl.: SHA1) kódolt (PasswordDigest) formában PasswordText <wsse:security soapenv:mustunderstand="1" xmlns:wsse=" wss-wssecurity-secext-1.0.xsd"> <wsse:usernametoken wsu:id="usernametoken " xmlns:wsu=" <wsse:username>czaki</wsse:username> <wsse:password Type=" <wsse:nonce>qzqtoqwm5vvgdpmtywwong==</wsse:nonce> <wsu:created> t13:33:09.418z</wsu:created> </wsse:usernametoken> </wsse:security> PasswordDigest <wsse:security soapenv:mustunderstand="1" xmlns:wsse=" wss-wssecurity-secext-1.0.xsd"> <wsse:usernametoken wsu:id="usernametoken " xmlns:wsu=" <wsse:username>czaki</wsse:username> <wsse:password Type=" word> <wsse:nonce>5tmolwbyzvo/jees0ej0mq==</wsse:nonce> <wsu:created> t13:33:56.230z</wsu:created> </wsse:usernametoken> </wsse:security> Signature A kliens titkos kulcsával generálja az üzenettartalom-függő aláírást. A szerver a kliens

20 3.5. WS-Security 22 publikus kulcsával dekódolja az információt. Az üzenet tartalmához csatolja a SOAP fejlécbe a titkosítási információkat, például.: <soap:envelope xmlns:soap=" <soap:header> <wsse:security xmlns:wsse=" soap:mustunderstand="1"> <ds:signature xmlns:ds=" Id="Signature "> <ds:signedinfo xmlns:ds=" <ds:canonicalizationmethod Algorithm=" xmlns:ds=" <ds:signaturemethod Algorithm=" xmlns:ds=" <ds:reference URI="#id " xmlns:ds=" <ds:transforms xmlns:ds=" <ds:transform Algorithm=" xmlns:ds=" </ds:transforms> <ds:digestmethod Algorithm=" xmlns:ds=" <ds:digestvalue xmlns:ds=" gvgufw=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue xmlns:ds=" ogv/w/qzaxd1qsb9u7mxu2kiiygihwkkfudi8up+ce+y4banbkwoodshhxvai1s2vo7 p4jyfebkx ygdygzkinaks+nxcc5x5kkqoklomcsi//blphwis0opdmskghuk673nh8u2smfwdrpz tmiitzk70 Py+QaEcs1JjEn2aBJKE= </ds:signaturevalue>

21 3.5. WS-Security 23 <ds:keyinfo Id="KeyId " xmlns:ds=" <wsse:securitytokenreference xmlns:wsu=" wss/2004/01/oasis wss-wssecurity-utility-1.0.xsd" wsu:id="strid " xmlns:wsse=" 2004/01/oasis wss-wssecurity-secext-1.0.xsd"><ds:X509Data xmlns:ds=" <ds:x509issuerserial xmlns:ds=" <ds:x509issuername xmlns:ds=" =Kliens,L=Budapest,ST=State,C=HU</ds:X509IssuerName> <ds:x509serialnumber xmlns:ds=" rialnumber> </ds:x509issuerserial> </ds:x509data></wsse:securitytokenreference> </ds:keyinfo> </ds:signature> </wsse:security> </soap:header> <soap:body xmlns:wsu=" wsu:id="id "><ns1:printstring xmlns:ns1=" World!</ns1:bemenet></ ns1:printstring></soap:body></soap:envelope>

22 3.6. WS-BPEL 2.0 (Web Services Business Process Execution Language) WS-BPEL 2.0 (Web Services Business Process Execution Language) [18], [19] és [20] alapján. Webszolgáltatás alapú folyamatok viselkedésének, végrehajtási módjának leírására szolgáló XML alapú folyamat/workflow technológia. Segítségével egyszerű, diszkrét folyamatok állíthatók össze komplex üzleti folyamatokká, amik mint end-to-end szolgáltatások üzemelhetnek. A WSDL egy szolgáltatás leírására használható, nem írja le az üzleti folyamatok mentén hívott (üzleti) szolgáltatás(ok) kezelését, amik mint egy új webszolgáltatások működhetnek. A hosszú lefutású folyamatok perzisztenciájáért a BPEL motor felelős. Egy vagy több külső webszolgáltatással tartja a kapcsolatot. A külső szolgáltatások és kliensek összefoglaló neve: partner szolgáltatások. A tipikus BPEL folyamat <receive> aktivitással (activity) kezdődik, utána külső szolgáltatásokat hív meg (<invoke>), és visszaküldi az eredményt a klienshez (<reply>). BPMN (Business Process Modeling Notation): vizuális megjelenítés (notation), jelölésrendszer Definíció: XML alapú folyamatleíró/vezénylő (orchestration) szabvány az OASIS gondozásában, alapja a BPML (Business Process Modeling Language), megvalósításának módja a webszolgáltatások. Részei: Orchestration (BPEL): üzleti folyamaton belüli webszolgáltatások együttműködésének logikájának definiálására, leírása XML alapú. Choreography (WSDL): Két vagy több végpont közötti publikus üzenetcseréje, a köztük lévő megállapodások és üzenetváltásának szabályai. Activities (Tevékenységek) Basic Activities (Általános tevékenységek) <invoke> A partner által kínált porttype meghívása one-way, vagy request/response módon. <receive> A folyamat blokkolódik, várakozik a megfelelő üzenet megérkezésére. <reply> A <receive> során kapott üzenetre küldhet választ. A <receive><reply> kombinációja request/response üzenetváltás jelent a porttype-on. Az érvényes BPEL folyamat az utóbb említett aktivitásokból csak egyet-egyet tartalmaz.

23 3.6. WS-BPEL 2.0 (Web Services Business Process Execution Language) 25 <assign> Változó értékének frissítése. <throw> Hibagenerálás az üzleti folyamatban. <wait> Várakozás bizonyos ideig. <empty> No-op instrukció beillesztése az üzleti folyamatban, például konkurens tevékenységek szinkronizációja végett. Structured Activities (Strukturált tevékenységek) <sequence> Aktivitások kollekciója, melyek meghívása szigorú egymásutánban történik. <while> Aktivitás ismétlése a megfelelő kritériumig. <pick> Megfelelő üzenet érkezéséig, vagy riasztás megszűnéséig várakozik (blokkol). Ha valamelyik trigger fellép, a megfelelő aktivitás meghívódik, és a <pick> befejeződik. <flow> Egy vagy több aktivitás végrehajtása konkurens módon. <scope> Lehetőséget ad beágyazott (nested) aktivitás és saját, társított változóinak, fault,- compensation handlereinek létrehozására. <compensate> Compensation meghívása belső scope-on, ami hibamentesen befejeződött. Csak fault, vagy más compensation handler-ből hívható. <switch> Feltételes viselkedés, switch támogatása. <link> Variables (változók) Kliensektől fogadott, és azokhoz intézett, WSDL-ben definiált (types, messages) üzenetek tárolása a folyamat részére. <assign> <copy> Partner Links (Partner Linkek)

24 3.6. WS-BPEL 2.0 (Web Services Business Process Execution Language) 26 Bármilyen olyan webszolgáltatás, ami kapcsolatba kerül a BPEL folyamattal, vagyis a résztvevő feleket azonosítja. Partnerszolgáltatások típusai: invoked partnerlink Más webszolgáltatás operation műveletének meghívása. client partnerlink Klienstől érkező művelethívás. Handlers <faulthandlers> Hibakezelést végez. Properties Colleration Sets

25 4. SOA Java EE platformon A Java platform gazdag funkciókat nyújt azon fejlesztők számára, akik SOA alapokra kívánják építeni új alkalmazásaikat, vagy átalakítani meglévő rendszereiket. Az átlátható és kidolgozott rendszerek, a sokoldalú implementációk garantálják a rendszerek közti együttműködést, a nyílt specifikációk, illetve a sok helyen megjelenő nyílt forráskódú (open source) alkalmazások pedig az átláthatóságot. A platform az XML feldolgozásától, a webszolgáltatásokon át egészen a SOA magját képező ESB-ig minden területre biztosít funkciókat, eszközöket. A kitűnő, nem hiába díjnyertes fejlesztőeszköz, a NetBeans beépített funkcionalitásainak köszönhetően még inkább színesíti a platform már így sokrétű és gazdag lehetőségeit. 27

26 4.1. JBI (Java Business Integration) JBI (Java Business Integration) [21], [22] alapján. A Java Community Process 3 keretén belül kidolgozott specifikáció (JSR 208). Célja a SOA megvalósíthatóságának kidolgozása Java platformon. Kiterjeszthető integrációs architektúrát definiál ami lehetővé teszi más gyártóktól származó ún. third party komponensek illesztését is. Az EAI és B2B rendszerek gyártóhoz kötöttségét, az általánosítás és szabványosítás hiányának kiküszöbölésére készült el az új specifikáció. A kidolgozott architektúra és a valós infrastruktúra lehetővé teszi más gyártóktól származó komponensek alkalmazását, ami az architektúra magját adja, így nem csak a segítségével készített alkalmazások,- hanem maga a keretrendszer is jellemezhető a SOA fő tulajdonságaival. A komponensek szolgáltatásokat (WSDL operation) nyújthatnak vagy/és vehetnek igénybe. A JBI szabványos módszert nyújt a Szerepek: komponensek telepítésére és a komponensek életciklusának kezelésére. Engine Developers Binding Developers JBI Environment Providers J2EE Platform Providers JBI Application Developers Előzmények A különböző, saját protokollokat, adatstruktúrákat használó rendszerek egészen addig megfelelőek, amíg saját, jól bebiztosított környezetükben külön-külön foglalkozunk velük. Viszont, ha integrációról van szó, ezek a rendszerek jelentik a rémálmot. Ezt a problémát felismerve a rendszerintegrációs csomagot biztosító cégek különböző gyártóspecifikus megoldásokat, API-kat készítettek. Ez nem jelentett különösebb problémát néhány rendszernél, de rendszerek számának növekedésével egyre több lett hozzájuk a rendszerspecifikus konnektor, és a helyzet egyre bonyolódott. A következő lépés az EAI (Enterprise Application Integration) szerver, mint központi hub biztosítása. A különböző gyártóspecifikus illesztőknek ezzel a rendszerrel kellett kommunikálni, így elég volt a szerver API-ját jól ismerni, de még ez is elég sok problémát tudott okozni, és hamar a központi hub lett a gyenge pont. 3 Java Community Process (JCP):

27 4.1. JBI (Java Business Integration) 29 ESB (Enterprise Service Bus): Szabványokon alapuló middleware architektúra, ami a csatolható (pluggable) komponensek közötti üzenetcserét biztosítja az üzenetkezelő alrendszeren keresztül JBI komponensek (röviden: komponensek) Service Engine (SE) Az üzleti logika, transzformációk nyújtása, vagy/és felhasználása. Üzemelhetnek mint konténer (pl.: EJB) is. Java alkalmazásokba integrálhatók. Például: XSLT BPEL EJB Binding Component (BC) A JBI keretrendszeren és a Java platformon kívüli szolgáltatások eléréséért felelnek, a JBI komponenseknek biztosítanak protokollfüggetlen szállítási szolgáltatást. Különböző protokollokat vehetnek igénybe, a külső szolgáltatások ezen keresztül vehetik igénybe a JBI funkcionalitásait. Integrálható különböző, nem Java platformon üzemelő, de távoli elérést biztosító alkalmazásokba. Egymással természetesen csak az NMR-en keresztül, normalizált üzenetek formájában folytathatnak kommunikációt. Például a BPEL Service Engine protokollfüggetlenül kaphatja a kéréseket az NMR-en keresztül különböző BC-ken (JMS, SOAP,...) keresztül. Például: HTTP (SOAP / REST) JMS/MOM Üzenetkezelés A komponensek közvetlenül nem kommunikálhatnak egymással, csak és kizárólag a JBI közvetítőn keresztül, ezáltal elérik a lazán csatoltság összes pozitív tulajdonságát. A szolgáltatást felhasználók a JBI interfésszel találják szembe magukat a komponensek használatakor. A komponensek összehangolása WSDL alapú (szintén SOA szemléletben), aszinkron WSDL alapú üzenetmodell A WSDL üzenet alapú szolgáltatások kétszintű modelljét határozza meg.

28 4.1. JBI (Java Business Integration) 30 Elemei: absztrakt csak egy keretet határoz meg üzenettípus normális hiba műveletek név Message Exchange Pattern (MEP) MEP üzenettípusai absztrakt szolgáltatástípus (absztrakt műveletek halmaza interface WSDL 2.0-ban, porttype WSDL 1.1-ben) interfész név kiterjesztett interfész(ek) konkrét az absztrakt implementációját definiálja binding típusok protokoll típusa, szolgáltatás mihez van kötve végpontok név binding típus szolgáltatás azonos szolgáltatásokat nyújtó végpontok halmaza név típus végpont(ok) A JBI az absztrakt szolgáltatásmodellre építkezik. A szolgáltatások interakciója során a komponensek a következők mindegyike, vagy csak egyike lehet: Service Provider Meghatározott szolgáltatást hajtanak végre. Service Consumer Szolgáltatást hív meg Normalizált Üzenet A JBI runtime belső üzenetkezelő rendszerének speciális formátumú üzenete. Részei: payload (az absztrakt WSDL típusnak megfelelő XML üzenet) üzenet metaadatok (context data), vagy tulajdonságok (properties) csatolmányok (attachments)

29 4.1. JBI (Java Business Integration) 31 A komponensek együttműködéséhez az üzeneteket a Normalized Message Router (NMR) továbbítja. A szolgáltatást felhasználók (consumer) képesek a szolgáltatás nevével (nem a végpont címével) hivatkozni a szolgáltatást nyújtóra (provider). De képesek Végpont Referencián (Endpoint Reference) keresztül is címezni, ami ún. callback eseményeknél fontos Normalizált üzenetcsere A BC-knek a protokollspecifikus üzeneteiket (bound messages) kötelezően át kell konvertálniuk normalizált üzenetté. A BC-k és SE-k az NMR-rel a kétirányú DeliveryChannel-eken (mindkét oldalon) keresztül kommunikálnak NMR (Normalized Message Router) Üzenetcserét végez a szolgáltatást nyújtók,- illetve azok felhasználói között. Az SE-k és BC-k nem folytathatnak közvetlen üzenetcserét, kizárólag az NMR-en keresztül (WSDL alapú normalizált üzenet). A szolgáltatás minősége 4 (binding és engine együttműködéssel) a következők szerint sorolható be: Best effort At least once Once and only once Kommunikációs minták: In-Only Robust In-Only In-Out In Optional-Out Menedzsment A JBI környezet JMX-en 5 keresztül menedzselhető. A JBI implementációnak kötelező JMX Management Bean-eket (MBeans) nyújtani, de a JBI komponenseknek is tartalmazniuk kell menedzsment interfészeket. Segítségével elérhetőek a következők: SE-k és BC-k (komponensek), és osztott könyvtárak (shared libraries) telepítése komponensek (BE, SE) életciklusának menedzselése (start/stop) component artifact-ok (Service Unit, SU) deploymentje monitorozás 4 QoS Quality of Service 5 JMX Java Management Extensions

30 4.2. OpenESB OpenESB [23] és a fejezet végén feltüntetett linkek alapján. Nyílt forráskódú Enterprise Service Bus (ESB) runtime, JBI implementáció. Glassfish/Sun Java Application Server-be integrálható. A project (OpenESB) magába foglalja a futtatókörnyezet (runtime) fejlesztését (OpenJBI project), illetve az OpenESB-től független komponensek (OpenJBI Components) fejlesztését is. 2. ábra. OpenESB architektúra Forrás: Az OpenESB, illetve komponenseinek menedzsmentjére több lehetséges út, eszköz kínálkozik (ahogy a GlassFish alkalmazásszervernek is): GlassFish adminisztrációs konzol (asadmin) JSF alapú adminisztrációs felület (localhost:4848) NetBeans IDE Komponensek Támogatott és implementált komponensek.

31 4.2. OpenESB 33 Az OpenESB projektben elérhető komponensek listája és részletes leírása elérhető a következő oldalról: Service Engine A teljesség igénye nélkül a következők: Aspect SE Java EE SE A JBI és a Java EE alkalmazások között teremt kapcsolatot, közvetlen EE WS 6 hívást tesz lehetővé a JBI konténerből. Nélküle távoli hívásokon keresztül valósulna meg a kommunikáció (szerializációs overhead). Servlet és EJB alapú WS-ek hívását is támogatja. BPEL SE WS-BPEL 2.0 üzleti folyamatok vezénylése Data Mashup Encoding SE ETL SE IEP SE Scripting SE SQL SE SQL utasítások feldolgozása, SQL lekérdezések futtatása és eljuttatása a klienshez vagy más SE-hez (például további feldolgozás céljából). Támogatja a következőket: SQL DDL (Data Definition Language) SQL DML (Data Manipulation Language) tárolt eljárások (stored procedures) WLM SE XSLT SE Binding Component A teljesség igénye nélkül a következők: CICS BC CORBA BC DCOM BC BC fájl BC FTP BC HL7 BC 6 WS Web Service (webszolgáltatás)

32 4.2. OpenESB 34 IMS BC JDBC BC JMS BC LDAP BC MQ Series BC MSMQ BC RSS BC SAP BC SIP BC SMTP BC SNMP BC SOAP (HTTP) BC SWIFT BC TCPIP BC UDDI BC XMPP BC GlassFish alkalmazásszerver A 2-es verziótól kezdve tartalmazza a JBI (OpenESB) runtime-ot, ami tartalmazza a Java EE Service Engine, illetve a HTTP Binding komponenseket. Csomag telepítése, mint addon[24]: 1. Alkalmazásszerver leállítása: asadmin stop-domain [domain-name] 2. jbi_components_installer.jar kicsomagolása és elhelyezése az alkalmazásszerver addons könyvtárába (<appserver-install-root>/addons) 3. Az alkalmazásszerver főkönyvtárából kell meghívni a következő parancsot: asadmin install-addon<appserver-installroot>/addons/jbi_components_installer.jar 4. A telepített komponensek itt találhatóak: <appserver-install-root>/addons/jbi_components/ 5. Alkalmazásszerver elindítása, ami a meghatározott domain-be telepíti a komponenseket: asadmin start-domain [domain-name] 6. A domain telepített komponensei: <appserver-install-root>/domains/<domain-name>/jbi/components

33 4.2. OpenESB 35 Komponens konfigurálásának eltávolítása (unconfigure): 1. Alkalmazásszerver leállítása: asadmin stop-domain [domain-name] 2. A <appserver-install-root>/domains/[domain-name]/config/domainregistry fájlban be kell állítani a következőt: jbi_components_configurator.configured=false 3. Komponens indítása: asadmin start-domain [domain-name] Komponens eltávolítása: 1. asadmin uninstall-addon jbi_components Ha egyben akarjuk a legnépszerűbb komponenseket telepíteni, akkor a csomagot (jbi-components.jar) a következő címről tudjuk letölteni: (OpenESB) A GlassFish adminisztrációs konzolja által támogatott JBI specifikus parancsok (részlet): uninstall-jbi-component uninstall-jbi-shared-library undeploy-jbi-service-assembly stop-jbi-component stop-jbi-service-assembly start-jbi-component start-jbi-service-assembly show-jbi-binding-component show-jbi-service-assembly show-jbi-service-engine show-jbi-shared-library shut-down-jbi-component shut-down-jbi-service-assembly list-jbi-binding-components list-jbi-service-assemblies list-jbi-service-engines list-jbi-shared-libraries install-jbi-component install-jbi-shared-library

34 4.2. OpenESB 36 Service Engine-ek életciklusa: Started/Stopped/Shutdown/Uninstalled Egy komponens telepítése: Amennyiben csak a számunkra szükséges komponenseket szeretnénk használni, különkülön is telepíthetjük őket. A példa a BPEL Service Engine telepítését mutatja be: 1. asadmin start-domain domain1 2. asadmin install-jbi-component../ bpelserviceengine.jar 3. list-jbi-service-engines 4. start-jbi-component sun-bpel-engine További komponenseket tölthetünk le a következő címről: Természetesen mindez sokkal egyszerűbben, parancsok gépelése nélkül grafikus felületen is véghezvihető, akár a webes adminisztrációs felületen (localhost:4848), akár NetBeans-ből. Nem telepített JBI komponens: Amennyiben olyan alkalmazást próbálunk deployolni, ami például File-Binding-ot használ, de azt nem telepítettük, a következőhöz hasonló hibaüzenetet kapunk (GlassFish log): run-jbi-deploy: [deploy-service-assembly] Deploying a service assembly... host=localhost port=4848 file=c:\users\czaki\documents\netbeansprojects\caflightplan/dist/ca FlightPlan.zip Failed execution of Deploy: C:\Users\Czaki\Documents\NetBeansProjects\caFlightPlan/dist/caFligh tplan.zip ERROR: (JBIMA1407) Required component sun-file-binding is not installed on target server. További információk:

35 4.3. Sun Java CAPS (Composite Application Platform Suite) Sun Java CAPS (Composite Application Platform Suite) [25], [26], [27], [28] és [29] alapján. Kompozit alkalmazások integrációját biztosító SOA platform. Alkalmazásával csökkenthető a meglévő IT infrastruktúrára szánt TCO (Toal Cost of Ownership). Egységes fejlesztési, telepítési, menedzsment, monitorozó környezetet biztosít mind a meglévő,- mind a kifejlesztendő alkalmazások számára. Kompozit alkalmazások (CASA Composite Application): Az adott üzleti problémára adnak megoldást, összefogják a különböző rendszerekből származó üzleti logikát, adatokat, adatforrásokat. Az EAI eszközöket gyártó SeeBeyond nevű céget 2005 augusztusában vásárolta fel a Sun, mintegy 387 millió dollárért. A Java CAPS alapja a SeeBeyond Integrated Composite Application Network (ICAN) szoftver, amit a Sun kiegészített saját megoldásaival. A tranzakcióval és az új brand létrehozásával a Sun betört a SOA megoldásokat kínáló gyártók piacára. Eredeti neve Sun Java Integration Suite. A későbbi verzióktól (5.2+) az eredeti SeeBeyond ESB-t lecserélik a JBI implementációt biztosító házon belüli, saját rendszerre, az OpenESB-re. Az integrációs területen továbbra is a Java CAPS a Sun kereskedelmi, licencelhető terméke. 3. ábra. Java CAPS architektúra Forrás: [29]