Békési Gábor * SZERVIZKÖZPONTÚ ARCHITEKTÚRÁK ÉS WEBSZOLGÁLTATÁSOK

Békési Gábor* SZERVIZKÖZPONTÚ ARCHITEKTÚRÁK ÉS WEBSZOLGÁLTATÁSOK Az ezredfordulót megelõzõ évek nagy felismerése, hogy az informatikai erõforrások (alkalmazások, rendszerelemek, kapcsolódó rendszerek) szolgáltatásként is felhasználhatók. Erõforrás-pazarlók a monolitikus, minden funkciót programkódjukba integráló hatalmas célrendszerek. Ha az egyes tevékenységeket szolgáltatásként valósítjuk meg, ezek másutt is beépíthetõk lesznek, tehát újrafelhasználhatók. A szolgáltatásokra építve alkalmas hálózati technológia mellett néhány sor programozással kiválthatjuk régi, méretük miatt is lassú, nehezen karbantartható rendszereinket. Mi több, a korábbi nagy program értékes részei szolgáltatásként tovább élhetnek az új alkalmazásban. A szervizközpontú architektúra (Service Oriented Architectures, SOA) osztott rendszerek tervezési paradigmája. Erre a koncepcióra jellemzõ, hogy az így tervezett rendszer:

• • • •

gyengén kapcsolódó üzleti alkalmazások együttese, független az IT-infrastruktúrától, dinamikus (kompozit1 ) alkalmazások jellemzik, több információ áll rendelkezésre, igaz, hogy programozott (vastag) ügyfelet használ, platform- és hálózatfüggetlen megoldásokat eredményez.

A rendszerelemek közti kapcsolatok interfészeken (rögzített tartalmú csatoló felületeken) keresztül valósulnak meg, így az összekapcsolt részek eltérhetnek operációs rendszerükben, kommunikációs protokolljaikban, hiszen az együttmûködésük szigorúan szabályozott. Ezek a megoldások jellemzõen nyílt szabványú protokollokat2 használnak. (Az ilyen protokollok általában a szállítási réteg felettiek, az alkalmazási tartományba tartoznak.) Mivel a szolgáltatások interfészeiken keresztül szabványosítottak, egyszerû új szolgáltatástartalmakat bekapcsolni, másokat kiváltani. Az szervizalapú alkalmazásokban megtestesült üzleti logika folyamatokba szervezett. A SOAelvû rendszerek létrehozására nem alkalmas a komponenstechnológia (a komponenseknek saját vezérlése, kapcsolati rendszere van), ugyanis itt az összetevõk együttmûködését egy feldolgozó folyamat szabályozza. Mivel ezek objektumorientált alkalmazások, felhasználják az eseménykezelést. Üzleti objektumok esetén gyakorta üzleti események okozzák az állapotváltozásokat, és az így kiváltott reakciók is a feldolgozó folyamat hatókörébe esnek. A fenti kritériumokat (nyílt szabványok, hálózatfüggetlenség) ma leginkább a webszolgáltatások teljesítik.

*

fõiskolai tanár, Általános Vállalkozási Fõiskola

Új információs technológiák

159

1. ábra A SOA megvalósítása

Új szolgáltatási igény Üzleti folyamatok Szolgáltatás integrálása

Új igények

A szolgáltatás közrebocsátása

Az 1. ábrán látható sémában például új igény lehet a megrendelések fogadása, az ezt kiváltó üzleti esemény egy rendelés beérkezése. (Fontos megjegyezni, hogy egy üzleti objektum az eseményre nem feltétlenül reagál üzenettel.) A SOA elõnyei: - meglévõ erõforrások, rendszerek összekapcsolása, - újrafelhasználható szolgáltatások, - platformfüggetlenség, - több információ, hatékonyabb döntéshozatal, - gyorsabb piacra jutás (time-to-market), - a számító háló (grid computing) lehetõsége. A SOA rendszerekre jellemzõ, hogy a rendszer mûködése mérhetõ. A szolgáltatásalapú rendszerek üzleti folyamatait speciális környezetek futtatják. Az ismertebbek a JVM3 és .NET. Ezek valójában alkalmazásszerverek, szabványos interfészekkel és kommunikációs technológiával szolgáltatásokat publikálnak.

A WEBSZOLGÁLTATÁSOK Az alapséma szerint a kliens üzenetet küld a szolgáltatónak és a szolgáltatást ugyancsak üzenet formájában kapja. Minden szerviz egy (vagy több) végponton érhetõ el. Minden végpontnak címe, kapcsolatleírása van, és egy megállapodás (contract) rögzíti mindkét fél számára, mit is tartalmazzanak az üzenetek. Ezeket az információkat a szolgáltató teszi közzé egy WSDL4 specifikáció formájában. A webszolgáltatás jellemzõi:

• hálózatokat (web) használó, osztott alkalmazások, • implementációs technológiát jelentenek (a SOA-t valósítják meg), 160

XXI. Század – Tudományos Közlemények 2008/19

• nyílt szabványokat, XML-t használnak (platformfüggetlenek), • szabványos szolgáltatásleírást használnak (WSDL), • biztonságosak (általában az új WS-* szabványokat alkalmazzák5 ). Fontos kritériumuk, hogy a szolgáltatások felkutathatók. Ma a Microsoft és az IBM a webszolgáltatás-technológia vezérhajói. A SOA-t termékeikben megvalósító szoftvergyártók közül most röviden csak a Microsoft és az Oracle koncepcióját vázoljuk. A Microsoftnál is vannak információrendszer jellegû megoldások (Microsoft Dynamics Nav, AX). A következõkben inkább a fejlesztési lehetõségeket, az ehhez kínált eszköztárat mutatjuk be. Ez a szuperplatform így aposztrofálták a Vista, illetve Longhorn szerverrel megjelenõ környezetet6 . A WSE7 és a WCF8 olyan fejlesztési támogatás, amely leegyszerûsíti SOA-rendszerek készítését, biztonságossá (adatbiztonság!) teszi a használatukat. Robosztus, megbízható szoftverkörnyezetek. A WSE üzenetei karakteres állományok (SOAP9 -üzenetek), a Microsoft webszerverén futó feldolgozó folyamattal. Ezzel szemben a WCF tetszõleges állományokat mozgat a hálózati protokollok széles skáláján és a szolgáltatást egy alkalmazás is befogadhatja.

A WSE A biztonságos webszolgáltatások tervezésének, fejlesztésének jó lehetõségét kínálja a SOAPüzenetek kezelésének munkafolyamatba ágyazása. Ha a szolgáltató az IIS10 -en fut, máris adott az ASP.NET munkafolyamat, amely a webkiszolgálóhoz befutó igényeket mintegy kicsomagolja, becsomagolja, míg az ügyfélnél ugyanezt a WSE-motor teszi. Bár a SOAP-üzenetek több protokoll szerint is továbbíthatók, a webszolgáltató használata miatt jelenleg csak a HTTP terjedt el. A WSE 3.0 a korábbi sikeres verziók bõvítése az újabb WS-* szabványokkal. Ezek a WSEüzenetek WCF-alkalmazásokkal is kommunikálni tudnak. Ennek oka, hogy azok a webszolgáltatások, amelyek a Basic Profile 1.1 szabvány szerint készültek, technológiai platformoktól függetlenül igénybe vehetõk. A WSE egy osztálygyûjtemény, egy API, a Microsoft Visual Studio 2005 fejlesztõi környezetbe integrálható, és mivel ebben a környezetben a fenti szabvány szerinti szolgáltatásokat hozhatunk létre, természetes a WCF-konformitás. A WSE használata miatt ilyenkor az ügyfél programját is Visual Studio-ban készítjük. A biztonság elõtérbe helyezéséhez a WSE 3.0 stratégiasablonok felkínálásával járul hozzá. Ezek:

• UsernameOverTransport a felhasználó user-nevet használ azonosításra, a szállítási szint titkosított,

• AnonymousOverCertficate a szolgáltató tanúsítványt használ, a felhasználó anonim, • UsernameOverCertificate a felhasználó user-nevet, a szerver tanúsítványt használ, • Kerberos csak Active Directory-t használó, egy (virtuális) hálózatba tartozó Windows-felek között.

• MutualCertificate mindkét fél tanúsítványt használ aláíráshoz, titkosításhoz (kétféle protokoll között választhatunk).

A biztonsági stratégiát sem a szolgáltatás, sem a kliens oldalán nem szükséges programozni. A leírások konfigurációs állományokba helyezhetõk, ami egyszerûsíti a késõbbi változtatásokat. Használhatunk egyedi biztonsági stratégiákat is. Ez azonban komoly tervezési és programozói jártasságot igényel, mivel az üzenetkezelés sztenderd osztályait felül kell írnunk a felhasználói stratégiát végrehajtó osztályokkal. Ezek a SoapFilter osztályból származtathatók és elsõdlegesen a ProcessMessage metódusuk igényli a változtatást. A SOAP-üzeneteket használó kommunikáció karakteres tartalmú. A bináris állományokat küldéskor 64 bites, látható kódokból álló formára kell átalakítani és fogadáskor ugyanezt fordítva. Nagy fájlok cseréjekor (pl. multimédiás alkalmazásoknál ez a helyzet) ez rendkívül erõforrás-igényes mûvelet. A WSE további hátrányaként említhetõ, hogy a szolgáltatás mindig webszerveren fut. Az itt általánosan használt http-protokoll miatt az interoperabilitás korlátozott.


161

WCF A WCF lehetõvé teszi, hogy komponensek, alkalmazások egymással kommunikáljanak. Fõ kategóriái a szolgáltatás és az üzenet. A kommunikáció alapja a szervizhez tartozó WSDL-leírás (2. ábra). A programozási modellt Szervizmodellnek hívják. A WCF a .NET Framework 3.0-t igényli, és a fejlesztéshez a Microsoft Visual Studio 2005 ajánlható.

2. ábra Webszolgáltatás és igénybevétele

A kliens (Üzenetet küld és fogad.)

Végpont 1 Cím, Kapcsolat, Egyezmény WSDL

Kiszolgáló

Végpont n Cím, Kapcsolat, Egyezmény

A webszolgáltatások készítéséhez elõször a szolgáltatást kell megadnunk. Ez egy interfészdefinícióval kezdõdik, melyet késõbb a szervizre vonatkozó megállapodásként használunk. A megállapodás-interfészünket egy .NET osztályban implementáljuk. Ez a program típusa, és ez írja le a szolgáltatásunk viselkedését. A kifejtés a végpontok specifikációjával történik. A végpontok tartalmazzák a címet, a lehetséges kapcsolatokat és egyezményeket a mûveletekre és paramétereik adataira. Az elõbbi programozási elemek elõtt kulcsszavakat találunk. Ezeket jellemzõknek, attribútumoknak nevezik és általában contract postfixszel végzõdnek. Az utánuk álló elemekhez társulnak, funkcióikat, tulajdonságaikat bõvítik. Például a metódusok paramétereihez tartozó DataContract jellemzõ az adattagok szerializációjához és deszerializációjához (az üzenetben található XML-adattartalomnak a neki megfeleltetett programobjektumba való átvitelére és fordítva) tartalmaz információt11 . Az elõbbi megállapodások mindegyikének helyi jellemzõit a behavior végzõdésû attribútumokban adhatjuk meg. Tipikus eset, hogy a szerviz lehet egyetlen példányos, de a hozzáférést több szálon biztosítjuk. A viselkedés saját felhasználói osztállyal is felülírható. Végül szolgáltatóhoz rendeljük a szervizt (hosztoljuk), ami az IIS-t kivéve, egy applikációba történõ beillesztést jelent. Ebben az esetben a létrehozott ServiceHost példányhoz adjuk a végpontok példányait. Ezen példányok konstruktorai a szolgáltatás típusán kívül az aktuális kapcsolatot (ez kiválasztható egy elõre definiált listából) és a szállítási szintet konkretizáló URI12 -t (címet) kérnek. Egy végpont egy kapcsolati, kommunikációs protokollt kezel (pl. bináris üzenetek forgalmazása MSMQ13 -n keresztül), de a választék igen bõ, és felhasználói osztályokkal is bõvíthetõ. Ezután a hosztolt példány Open-metódusát meghívva, az szolgáltatóként kezd mûködni. Nagyon fontos, hogy a végpontleírásokkal és szolgáltatáshoz történõ hozzáféréssel kapcsolatosan ha csak nem akarunk egyetlen sor kódot sem kell írnunk. Ezeket a jellemzõket konfigurációs állományokban is megadhatjuk, növelve ezzel az alkalmazás rugalmasságát.

162


Egy szolgáltatás használatához szükségünk van a webszolgáltatást nyújtó végpontok leírására az ügyfél oldalon is. Ha ügyfelünk is .NET alkalmazást használ, ehhez elég a felhasználó programjában egy ServiceEndpoint objektumot létrehozni, amely konstruktorában ugyanazokat a paramétereket várja, mint amit a szolgáltatás hosztolásakor megadtunk. A szolgáltatás interfészének ismeretében a ChannelFactory segítõosztályból legyárthatjuk a közvetítõ felületet (proxy-t). Hasonlóan a szerviznél látottakhoz, most is választhatjuk a konfigurációs fájllal történõ megoldást. Probléma akkor van, ha ügyfelünk nem .NET Framework alatt fut, vagy nincs hozzáférésünk a webszolgáltatás kapcsolódási felületéhez. Mivel a szolgáltatás interfésze közvetlenül nem látható, szükségünk van annak WSDL leírására. Felkutatásához a WS-MetadataExchange specifikáció ad lehetõséget, ami a gyakorlatban egy alkalmas segédprogram (WCF-platformon az svcutil.exe) használatával rögtön megadja a szolgáltatás kapcsolódási felületét és a szükséges konfigurációs fájlokat.

AZ ORACLE VERZIÓJA A SOA TÁMOGATÁSÁRA Az Oracle megoldása zárt, saját eszközökre alapozott, de nyitott más rendszerek szolgáltatásai felé. Ennek alapelemei: Oracle Fusion Middleware (köztes szoftver) SOA-alapú keretrendszer

• Oracle Data Hub törzsadatkezelõ a köztes szoftver alatt (szinkronizált központi adatkezelést biztosít)

• Oracle Application Server 10g (J2EE14 -n alapszik) • Oracle BPEL Process Manager folyamatkezelõ a webszolgáltatások összehangolására. A BPEL betûszó a Business Process Execution Language for Web Services elsõ négy szavának kezdõbetûibõl jött létre. XML-formátumú szkript nyelv, amellyel a fejlesztõk a többszörösen összetett webszolgáltatásokat egyetlen üzleti folyamatban állíthatják össze. Támogatja a folyamat vezérlését, az üzleti tranzakciók aszinkron végrehajtása mellett. Az XML-adatkezelés kiterjed az XMLbõvítmények15 feldolgozására is. Oracle E-Business Suite üzleti alkalmazások integrált rendszere. Moduláris felépítésû. Különbözõ vállalatméretekre szabott változatai vannak. Oracle Enterprise Manager az Oracle-technológián alapuló rendszerek felügyelõje. Feladata a rendszermonitorozás, osztott adatbázis- és alkalmazáskezelés és a grid computing támogatása. Az Oracle E-Business Suite lehetõvé teszi adaptív (alkalmazkodó) üzleti folyamatok SOA alatti létrehozását (a Release 11i-tõl kezdõdõen). Az üzleti folyamatok alkalmazások sorozatán keresztül valósulnak meg. Az alkalmazások átjárhatóvá tétele drága (feltételei pl. a közös platform, közös szoftvergyártó, befagyasztott interfészek). Megoldást a SOA kínál. A szerviz egy diszkrét üzleti funkció. A rendelési azonosító ismeretében például megkapjuk a rendelés jelenlegi állapotát, akár telefonon, akár az információs központon, akár az interneten (böngészõn) keresztül. Webszolgáltatásnak hívjuk, mert az internet protokolljait használja. Üzleti esemény: állapotváltozás, ami emberi vagy rendszerbeli reakciót igényel. A SOA-elemek között gyenge kötés van. Ez a kapcsolódó felületek magas absztrakciós szintjének köszönhetõ (Az adattípusokat XML-ben írjuk le). Eredményeként az elemek mûködése, a protokollok változhatnak, az interfészek maradnak. A tényleges mûködést nem is fontos ismerni. Az OO technológia ezt elrejtésnek (encapsulation) nevezi. Az interfészeket sztenderdek szabályozzák. A legfontosabbakról, ilyen a SOAP, a WSDL, már történt említés. Az üzleti események és azok reakciói kapcsolják össze az üzleti funkciókat üzleti folyamatokká. Az E-Business Suite több mint ezer üzleti eseményt használ. Az Oracle Workflow kezeli ezeket. Ha állapotváltozás történt, a Workflow egy eseményt generál a folyamat soron következõ üzleti tevékenysége számára. Ezt XML-be formattálva kapja meg az üzenetkezelõ rendszer, ami akár külsõ sorkezelõ is lehet, pl. az IBM MQSeries. Az események és az üzenetek definíciója verziófüggetlen.


163

Az E-Business Suite minden üzleti funkcionalitást vállalati szervizként valósít meg. Ezek hibatûrõk, biztonságosak, méretezhetõk, monitorozhatók, és a rendszer támogatja kezelésüket. Üzleti szabályok adhatók meg hozzájuk, melyek környezethez és feltételekhez köthetõk. (Például egységár kiszámításakor figyelembe veszi, ki a vásárló, mikor vásárol (szezonár), mennyit vásárol és milyen minõségû az áru.) Ezek a szolgáltatások rendelkeznek szabványos WSDL-leírással és SOAP-üzenetekkel kommunikálnak. Az üzleti funkciókhoz egy metaszótár több mint 150 üzleti objektum dokumetumával ad segítséget. Az elõre definiált objektumok száma folyamatosan bõvül. A sztenderdizált üzenetek száma jelenleg 167. Az üzleti folyamatok egyes lépéseit az Oracle BPEL Process Manager hivatott kezelni. Ezzel az eszközzel hozhatunk létre üzleti funkciókat, kapcsolhatjuk a munkamenethez és követhetjük nyomon, akár automatikusan is. Az üzleti funkciók platformfüggetlenek, más rendszerekbõl átvehetõk (pl. a Microsofttól) és transzformációk révén átadhatók. A BPEL Manager valójában üzletifolyamatkezelõ. Az E-Business Suite-ból származó üzleti események automatikusan generálják saját üzleti folyamatukat a BPEL Process Manager-ben, amely elindítja és felügyeli a szükséges lépéseket. Az Oracle JDeveloper lehetõvé teszi, hogy a fejlesztõk az üzleti logikát J2EE-komponensekként írják le, melyeket az E-Business Suite szolgáltatásokként kezel. Az E-Business Suite számos fejlesztõi platformot támogat. Így írhatunk szolgáltatást PL/SQL tárolt eljárások formájában is. A szervizek egyik jellemzõje, hogy felkutathatók. Az E-Business Suite egy online metakatalógust használ a webszolgáltatások tárolására, mely az említetteken túl üzleti eseményeket, valamennyi ismert interfészt, protokollt és API-t is tartalmaz. Alkalmas képernyõkkel és keresõ funkciókkal nagyon megkönnyíti a fejlesztést. Az elemek külsõ programokból is hívhatók, ezek aztán webszolgáltatásként funkcionálnak. A SOA fontos jellemzõje az üzleti foyamatok hatékonyságának ellenõrzése, mérése. Az Oracle Fusion Middleware egyik komponense, az Orcale Business Activity Monitoring segítségével a folyamatba ellenõrzési pontokat állíthatunk be. Elsõsorban az üzleti események kiváltotta állapotváltozások észlelése alkalmas erre. Részletes listát készíthetünk az üzleti objektum tulajdonságértékeirõl, amely összevethetõ a tervezett vagy elvárt értékekkel. A SOA-rendszerek méretezhetõségének és megbízhatóságának alapja a számítási háló. Ebben a kiesõ erõforrásokat azonnal mások pótolják. Valójában sosem tudhatjuk elõre, hogy egy eljárás melyik gépen fut le. A hálózaton belüli adatbiztonság lényeges kritériuma ezen megoldásnak. A szolgáltatásokhoz csak arra jogosult igények juthatnak hozzá. Az ezt biztosító házirendek kialakításáért és betartatásáért az Oracle Web Services Manager felelõs. Az Oracle lehetõséget ad a SOA keretrendszerét adó Fusion Middleware kiváltására, más, webszolgáltatásokat kezelõ rendszerekkel, például az IBM, a webMethods vagy a BEA integrációs szervereivel. Természetesen ezek szolgáltatásai eltérnek a fent ismertetettõl.

FELHASZNÁLT IRODALOM Enabling Adaptive Business Processes (2005): Oracle E-Business Suite and Service-Oriented Architecture (White Paper, Aug.) Michele Leroux Bustamante (2007): Learning WCF. OReilly Media Inc. Microsoft WS-I Basic Security Profile 1.0 Sample Application, (20062007), Microsoft, Patterns & Practices. Web Service Security Scenarios, Patterns and Implementation Guidance for Web Services Enhancements 3.0, (2005), Microsoft, Patterns & Practices.

164


JEGYZETEK 1

A kompozit (összeépített) alkalmazások üzleti eseményekbõl és szolgáltatásokból épülnek fel.

2

A nyílt szabványú protokollok intézmények, szervezetek konszenzusán alapszanak. Ezeket (legalábbis kezdetben) nem állami szervek bocsátják ki.

3

Java virtuális gép.

4

Web Services Description Language.

5

A WS-* szabványok második generációs szabványok. A webszolgáltatások biztonságára, az üzenetekre, a címzési elõírásokra vonatkoznak.

6

http://searchsoa.techtarget.com/originalContent/0,289142,sid26_gci1120886,00.html

7

Web Services Enhancements.

8

Windows Communication Foundation.

9

Simple Object Access Protocol.

10

Microsoft Internet Information Services.

11

Az ASMX (webszolgáltatásokat tartalmazó) állományok alapértelmezett sorosítója az XmlSerializer osztály példánya.

12

Universal Resource Identifier.

13

Microsoft Message Queuing.

14

Java 2 Enterprise Edition.

15

Az Xpath, XSLT és XQuery specifikációkról van szó.


165

166


Békési Gábor * SZERVIZKÖZPONTÚ ARCHITEKTÚRÁK ÉS WEBSZOLGÁLTATÁSOK

Recommend Documents