Technikai termékáttekintés

Átírás

1 WebSphere Integration Developer 7.0-ás változat Version 7 Release 0 Technikai termékáttekintés

2 Megjegyzés Mielőtt megkezdi a kiadvány és az általa támogatott termék használatát, olvassa el a Megjegyzések részben található információkat. Ez a kiadás a WebSphere Integration Developer 7-es változatának, 0. kiadására vonatkozik. Szerzői jog IBM Corporation 2005, Copyright IBM Corporation 2005, 2009.

3 Tartalom 1. fejezet A WebSphere üzletifolyamat-kezelési család WebSphere Integration Developer Szabványok Felhasználói szerepek a WebSphere Integration Developer rendszerben fejezet Szolgáltatásorientált architektúra fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) Szolgáltatásösszetevők Szolgáltatási adatobjektumok Szolgáltatásminősítők Modulok Importálások és exportálások Szolgáltatásimportálási és -exportálási kötések típusai 15 Megfelelő kötések kiválasztása A szolgáltatásmegvalósítás típusai Java objektumok BPEL folyamat Állapotgépek Üzleti szabályok Kiválasztók Emberi feladat Felületleképezés Közvetítő folyam Önálló hivatkozások fejezet Két irányban írt nyelvek támogatása Nyilatkozatok Felhasználási feltételek Szerzői jog IBM 2005, 2009 iii

4 iv WebSphere Integration Developer: Technikai termékáttekintés

5 1. fejezet A WebSphere üzletifolyamat-kezelési család A WebSphere Integration Developer egy üzletifolyamat-kezeléshez kapcsolódó termékcsalád tagja. Az üzleti folyamat kapcsolódó tevékenységek egy halmaza, ami olyan kimenetet állít elő, melyet egyedül egyetlen tevékenység sem lett volna képes létrehozni. Az üzleti folyamat fogalmát körülbelül száz évvel ezelőtt alkották meg. Adam Smith az elsők között volt, aki meghatározta az üzleti folyamat fogalmát, amikor azt tanulmányozta, hogy miként lehet egy termék előállítását felosztani a munkások egy halmaza között. Napjainkra a szoftverek beléptek az üzletifolyamat-kezelési környezetbe. A WebSphere üzletifolyamat-kezelő termékcsaládhoz hasonló szoftverek segítségével lehetőség van az üzleti folyamatok modellezésére. A modell ezt követően automatizálható az alkalmazások üzleti folyamatban való integrálása révén, mely a kézzel végzett munka helyett hajtható végre. A szoftverrel létrehozott üzleti folyamat működése futás közben is megfigyelhető, az üzleti folyamat modelljének hatékonysága pedig tovább javítható. A következő ábrán több kapcsolódó WebSphere termék látható, melyek az IBM szolgáltatásorientált architektúrához kötődő megközelítését meghatározó szakaszok szerint kerültek csoportosításra. Következzék most ezek rövid áttekintése annak bemutatása érdekében, hogy a WebSphere üzletifolyamat-kezelő termékcsalád elemei miként működnek együtt a hatékony üzleti folyamatok létrehozása és kezelése céljából. Model Assemble Deploy Manage Import services Import services External services Deployed services WebSphere Service Registry and Repository WebSphere Business Modeler WebSphere Integration Developer WebSphere Process Server WebSphere Business Monitor Export Monitor Model editor Deploy Events Monitor model Deploy WebSphere Enterprise Service Bus Events Monitor feedback A WebSphere Business Modeler a modellezési szakaszban az üzletifolyamat-kezelés egyik kiindulópontja. Ez a termék képes modellezni, szimulálni és elemezni az üzleti folyamatokat. Arra is lehetőséget ad, hogy magas szintű üzleti méréseket határozzon meg a folyamat számára, ha futás közben kívánja megfigyelni az üzleti folyamat tevékenységeit. A WebSphere Business Modeler terméket jellemzően a jelenlegi, valamint egy elképzeléseinek megfelelő jövőbeli üzleti folyamat modellezéséhez használja fel. A WebSphere Business Modeler elsődleges felhasználói az üzleti elemzők. A WebSphere Service Registry and Repository a felügyeleti szakaszban egy olyan lerakat, mely a WebSphere Business Modeler által importálható és felhasználható szolgáltatásokat tárolja és kezeli az üzleti folyamat fejlesztése során. Szerzői jog IBM 2005,

6 A WebSphere Integration Developer az összeállítási szakaszban átveszi az üzleti folyamat WebSphere Business Modeler termékből származó exportált modelljét, majd hozzáadja a modellhez a megvalósítás és az automatizálás elemeit. Ez a termék saját üzletifolyamat-modellt is képes előállítani. Az integrációs fejlesztők a WebSphere Integration Developer terméket használják az üzleti megoldások csatolókkal, üzleti folyamatokkal, kódkomponensekkel és közvetítő folyamokkal történő összeállításához. A csatolók az egyéb rendszerekhez, például az adatbázisokhoz, vállalati erőforrás-tervezési rendszerekhez (például: PeopleSoft) és nyilvántartásokhoz való csatlakozáshoz biztosítanak eszközöket. A közvetítő folyamok adatokat alakítanak át, továbbítanak és bővítenek ki. A WebSphere Service Registry and Repository képes integrált alkalmazások létrehozásához szükséges szolgáltatásokat biztosítani a WebSphere Integration Developer számára. A WebSphere Integration Developer rendszerben használható vizuális eszközök következtében az integrációs fejlesztőknek minimális jártasságra és ismertekre van szükségük az alapul szolgáló megvalósításokról. A tesztelési, hibakeresési és telepítési eszközök szintén megtalálhatók a termékben. A megfigyelési modell szerkesztővel hozzáadhatók azon üzleti mérőszámok megvalósításai, amelyeket kezdetben a WebSphere Business Modeler rendszerben adtak meg, majd ezt követően a napi üzletmenet megfigyelése érdekében átadnak a WebSphere Business Monitor alkalmazásnak. A WebSphere Integration Developer az integrált alkalmazások létrehozásának elsődleges IBM fejlesztői környezete. Ezek az alkalmazások a szolgáltatásösszetevő architektúrára épülnek, mely ezen termékáttekintés későbbi pontján kerül bemutatásra. A WebSphere Integration Developer rendszerben létrehozott alkalmazások a telepítési szakaszban két kiszolgálóra telepíthetők. A WebSphere Process Server kiszolgáló a WebSphere Integration Developer rendszerben létrehozott valamennyi alkalmazást képes futtatni, az üzleti folyamatokat tartalmazó és csatolókat használó alkalmazásokat is beleértve. Ez a kiszolgáló tekinthető a WebSphere Integration Developer rendszerben fejlesztett alkalmazások elsődleges kiszolgálójának. A WebSphere Enterprise Service Bus a közvetítő folyam összetevők kiszolgálója. A csatolók használatát is támogatja. Ez a kiszolgáló tekinthető az infrastruktúra szintjén működő kiszolgálónak. Közvetítő folyamokat használ az adatok átalakítására, továbbítására és kibővítésére a szolgáltatásösszetevő architektúra komponensei között és azoktól függetlenül. Mindkét kiszolgáló támogatja az alkalmazások megfigyelését a WebSphere Business Monitor felhasználásával. A felügyeleti szakaszban a korábban már említett WebSphere Service Registry and Repository rendszeren túl a WebSphere Business Monitor biztosítja az előzőekben meghatározott üzleti folyamat valós idejű megjelenítését. Egy műszereket és mutatószámokat tartalmazó műszerfal nézet olyan riasztásokat és értesítéseket állít elő, melyek pillanatról pillanatra lehetővé teszik az üzleti folyamat működésének követését. Ezek segítségével az erőforrások kiosztásában a szűk keresztmetszetek, a csökkent hatékonyságú elemek és a hibák gyorsan felfedezhetők - és javíthatók - a futó üzleti folyamatban. A munkafolyamat műszerfala részletes információkat biztosít az üzleti folyamatról, tájékoztatást nyújtva az üzleti egységek teljesítményéről és a határidők betartásáról. Az üzleti műszerfal statisztikai jelentésekkel szolgál, összehasonlítva a vállalat tényleges teljesítményét a kitűzött üzleti célokkal. A figyelő által összegyűjtött adatok az üzleti folyamatwebsphere Business Modeler rendszerben történt kezdeti meghatározásának felülvizsgálatához használhatók fel. Ezzel a módszerrel az üzleti folyamat tervezésével kezdődő, az üzleti folyamat futás közbeni eseményekre épülő visszajelzéséig tartó teljes ciklus lehetővé teszi az üzleti folyamat folytonos optimalizálását. A WebSphere termékcsalád egy másik áttekintése, amely a futásidejű tájékozódásról tartalmaz további adatokat, a termékcsalád áttekintése a WebSphere Process Server információs anyagaiban. 2 WebSphere Integration Developer: Technikai termékáttekintés

7 WebSphere Integration Developer A WebSphere Integration Developer jelenti a választ arra az integrációs kihívásra, mellyel a szervezeteknek napi rendszerességgel szembe kell nézniük. Teljes integrációs fejlesztői környezetként került kialakításra integrált alkalmazások összeállítása céljából. Az integrált alkalmazások fejlesztésének megkönnyítése és meggyorsítása érdekében ez a környezet olyan absztrakciós réteget biztosít, mely elválasztja a felhasználó által kezelt, vizuálisan ábrázolt összetevőket az alapul szolgáló megvalósítástól. Az integrált alkalmazások nem egyszerűek. Vállalati információs rendszerekben (EIS) működő alkalmazásokat hívnak meg, számos részleg és vállalat üzleti folyamatát foglalják magukban, továbbá helyi és távoli alkalmazásokat indítanak el, melyek különféle nyelveken íródtak és többféle operációs rendszeren futnak. Például az emerged vállalat a DOM bank és az M&M Diszkont Brókerház egyesítésével került létrehozásra. A fúzió a fenti elemek mindegyikére kiterjed: az elődvállalatok EIS rendszereiben működő alkalmazásokat, az üzleti folyamatokat, valamint egyéb alkalmazásokat is meg kell osztani a vállalatok között, továbbá zökkenőmentesen kell megjeleníteni azokat az ügyfelek új halmaza számára. Az emerged azonban sikeresen végrehajtotta a feladatot, és ahogy az a következő ábrán is látható, a két különálló elődvállalat ügyfelei egyaránt elérhetik online módon összes pénzügyi információikat. Az emerged a WebSphere Integration Developer eszközei segítségével állította össze saját maga és ügyfelei számára az integrált alkalmazásokat. Ezek az eszközök alkalmazásokat jelenítenek meg, a távoli EIS rendszereken már létező alkalmazásokat, valamint az összetevőkként megjelenő üzleti folyamatokat is beleértve. Az összetevők vizuális szerkesztők segítségével kerülnek létrehozásra és összeállításra más integrált alkalmazásokká (vagyis a komponensek egy halmazából felépülő alkalmazásokká). A vizuális szerkesztők az összetevők és az azok megvalósítása közötti absztrakciós réteget jelenítik meg. Az eszközöket használó fejlesztő anélkül állíthat össze egy integrált alkalmazást, hogy részletes ismeretei lennének az egyes összetevők alapjául szolgáló megvalósításról. A hibakeresési és tesztkörnyezet teljes tesztelést biztosít, mielőtt az alkalmazások telepítésre kerülnének az éles kiszolgálóra. A WebSphere Integration Developer eszközei egy szolgáltatásorientált architektúrára épülnek. Az összetevők szolgáltatások, a szolgáltatások pedig számos komponenst magukban foglaló integrált alkalmazások. A létrehozott szolgáltatások összhangban vannak az iparszerte elterjedt vezető szabványokkal. A szintén összetevőkké váló üzleti folyamatok hasonlóképpen könnyen használható vizuális eszközökkel kerülnek létrehozásra, melyek megfelelnek a Üzleti folyamat végrehajtási nyelv (BPEL) ipari szabványának. A WebSphere Integration Developer Windows és Linux platformon egyaránt elérhető. A WebSphere Integration Developer eszközeinek előnyei az alábbiakban foglalhatók össze: v Használatuk könnyen elsajátítható v Összetett integrációs helyzetekre alkalmazhatók 1. fejezet A WebSphere üzletifolyamat-kezelési család 3

8 v Gyorsan készíthet olyan alkalmazásokat, melyek megfelelnek az iparszerte elterjedt szabványoknak Szabványok A WebSphere Integration Developer által létrehozott alkalmazások megfelelnek a szolgáltatásorientált architektúrához tartozó, iparszerte elterjedt szabványoknak. Senki sem szeretne olyan szabadalomvédett kódhoz kötődő alkalmazásokat készíteni, melyek néhány éven belül elveszthetik támogatásukat, vagy költséges licencdíjakat kell utánuk fizetni. Ebből eredően a szabványalapú integráció a WebSphere Integration Developer lényeges szempontja. Az összekapcsolhatósághoz a J2EE kapcsolati architektúra szabványai kerülnek felhasználásra. Az aszinkron üzenetkezeléshez a garantált adatkézbesítést igénylő nagyobb alkalmazások esetében gyakran használt Java üzenetkezelési szolgáltatás (JMS) szabvány kerül alkalmazásra. A WebSphere Integration Developer könnyedén képes integrálni az Egyszerű objektumhozzáférési protokollra (SOAP) épülő webszolgáltatásokat. A szolgáltatások leírásához a jól megalapozott Webszolgáltatás leírónyelv (WSDL) szabványa kerül alkalmazásra. Az üzleti folyamatok meghatározásához az üzleti folyamat végrehajtási nyelv (BPEL) szabványa használatos. Ezek a szabványalapú felületek és összetevők egy nyíltvégű és csatlakoztatható architektúrát alkotnak. A zárt elemek azonban nincsenek kizárva; ezek szabványosított felületek használatán keresztül érhetők el. Ez azt jelenti, hogy a WebSphere Integration Developer rendszerben készített alkalmazások például.net alkalmazásokkal működhetnek együtt. Az architektúra fejezetben egy hivatkozás mutat a teljes Szolgáltatásösszetevő-architektúrára, mely megadja a számos támogatott szabvány átfogó felsorolását. Felhasználói szerepek a WebSphere Integration Developer rendszerben Az integrációs tervező, integrációs fejlesztő és integrátor jelenti a WebSphere Integration Developer felhasználóinak elsődleges típusait. Az integrációs tervező az architekturális szinten dolgozik, célja kiterjedt és összetett szolgáltatásorientált architektúrájú alkalmazások fejlesztése. Ezek az alkalmazások számos lazán kapcsolódó szolgáltatásból tevődnek össze, melyek önmagukban a Webszolgáltatás leírónyelv (WSDL) és az Üzleti folyamat végrehajtási nyelv (BPEL) szabványára épülnek. Ezek a szabványokra épülő szolgáltatások képesek együttműködni más szállítók szolgáltatásaival, így azok más szállítóktól, vagy a WebSphere Service Registry and Repository termékből kerülhetnek importálásra, ahol a szolgáltatásokat a teljes vállalaton belül meg lehet osztani. A szolgáltatások a megvalósítást is elválasztják a szolgáltatásként való ábrázolástól, függetlenek az elhelyezkedéstől, továbbá ezek gyakran más szolgáltatásorientált alkalmazásokból származó újrahasznosítható összetevők, ami azt jelenti, hogy az integrációs tervező a már meglévő, vagy még megvalósítandó szolgáltatások felhasználásával gyorsan létre tudja hozni alkalmazásait. Az integrációs tervező átfogó tudással rendelkezik az általa összeállított alkalmazás minden szempontjáról. A vállalattal és az iparággal kapcsolatos ismeretein túl rendkívül gyakorlott az üzletifolyamat-kezelésben és a szolgáltatásorientált architektúra használatában. Az összeállítás szintjén tevékenykedik, melynek során megszerkeszti az üzleti folyamat teljes folyamát. A szolgáltatások sorrendjén túl kulcsfontosságú döntéseket hoz a máshonnan újból felhasznált szolgáltatások típusára, valamint arra vonatkozóan, hogy mely szolgáltatások járhatnak nagy, összetett alkalmazások vállalati információs rendszerekben (EIS) való meghívásával. Részletesen ismerhet minden szolgáltatást, melyeket vagy saját maga hoz létre, vagy másokkal, például az integrációs fejlesztővel készíttet el. Az integrációs fejlesztő az integrációs tervező által létrehozott keretrendszerben dolgozik. Az integrációs tervező jellemzően a szolgáltatásorientált architektúrával rendelkező alkalmazás teljes architektúrájának néhány modulját birtokolja. Az integrációs fejlesztő alapos ismeretekkel rendelkezik saját moduljairól, azok adott programozási nyelven készült megvalósítását is beleértve. Az integrációs fejlesztő finomíthatja az integrációs tervező által létrehozott tervet, melynek teljesítéséhez megtalálhatja az újra felhasználható szolgáltatásokat, vagy a nulláról is összeállíthat saját modulokat. Az integrációs tervező által létrehozott nagyobb alkalmazásokon számos integrációs fejlesztő is dolgozhat. Az integrációs fejlesztő gyakorlattal rendelkezik a WebSphere Integration Developer összes varázslójának és szerkesztőjének használatában. Jártas a WSDL szolgáltatásfelületek és azon üzleti objektumok alkalmazásában is, melyek a saját és más integrációs fejlesztők összetevői közötti adatátadáshoz kerülnek felhasználásra. 4 WebSphere Integration Developer: Technikai termékáttekintés

9 Az integrátor elsődlegesen a kötések konfigurálása terén tevékenykedik, különösen a csatolókat magában foglaló importálási és exportálási kötésekkel foglalkozik. A leképezési felület alacsony szintű részletei, az adatdefiníciók és azok a biztonsági szempontok érintik, melyek az EIS háttérrendszerek eléréséhez kapcsolódnak. Tekintélyes tudással rendelkezik a külső EIS rendszerek és a szolgáltatásorientált alkalmazások integrálásával kapcsolatban. Az integrátor továbbá ezen külső EIS rendszerek, így például a CICS, IMS, PeopleSoft rendszerek és relációs adatbázisok technikai részleteit is ismeri. Előállítja a háttérrendszerek formátumai, így például a COBOL adatszerkezetek és a szolgáltatásorientált architektúra XML ábrázolása közötti leképezéseket. Az integrátor elsődlegesen az integrációs fejlesztővel dolgozik együtt, aki a háttérrendszereket elérő szolgáltatások hozzáadását hajtja végre. 1. fejezet A WebSphere üzletifolyamat-kezelési család 5

10 6 WebSphere Integration Developer: Technikai termékáttekintés

11 2. fejezet Szolgáltatásorientált architektúra A gyakran csak SOA néven említett Szolgáltatásorientált architektúra egy lazán meghatározott ipari szabvány, mely az összes üzleti folyamatot - a webszolgáltatásokat, Vállalati információs rendszer (EIS) szolgáltatási erőforrásokat, munkafolyamatokat, adatbázisokat stb. - szolgáltatásorientált módon jeleníti meg. Ez azt jelenti, hogy a szolgáltatások közötti függőségek minimalizáltak, és valamennyi szolgáltatás megvalósítása rejtett. A szolgáltatásorientált architektúra célja az üzleti integráció működési logikájának szétválasztása a megvalósítástól, hogy az integrációs fejlesztő a megvalósítás részletei helyett az integrált alkalmazás összeállítására koncentrálhasson. Ezen cél elérése érdekében olyan szolgáltatásösszetevők kerülnek létrehozásra, melyek az üzleti folyamatokhoz szükséges egyes szolgáltatások megvalósítását tartalmazzák. Az eredmény - ahogy az alábbi ábrán is megfigyelhető - egy háromrétegű, az üzleti integráció működési logikájából, a szolgáltatásösszetevőkből és a megvalósításból álló architektúra lesz. Mivel a szolgáltatásösszetevők tartalmazzák a megvalósítást, az integrációs fejlesztő által grafikus módon, a megvalósítási részletek ismerete nélkül állíthatók össze. A szolgáltatásösszetevők arra is lehetőséget biztosítanak, hogy az integrációs fejlesztő, vagy egyik munkatársa később adja hozzá a megvalósításukat. Ahogy a WebSphere Integration Developer rendszerben is megfigyelhető, az összetevők vizuális módon kerülnek összeállításra. Más szóval a felhasználó nem szembesül az összetevőkön belüli kóddal. Az üzleti funkció következő ábrán látható szintjén az összetevők megvalósításuktól függetlenül kerülnek összeállításra. A szolgáltatásorientált architektúra ezt követően lehetőséget ad arra, hogy az összetevők felhasználásával és újbóli felhasználásával az üzleti problémák megoldására koncentrálhasson, ahelyett, hogy a használt szolgáltatásokat megvalósító technológia terelné el figyelmét. Szerzői jog IBM 2005,

12 Melyek a szolgáltatásorientált architektúra kulcsfontosságú előnyei? A modern üzleti élet felfokozott tempója és kiszámíthatatlan jellege mellett a szolgáltatásorientált architektúra biztosítja a változó üzleti feltételekre való gyors reagálás és a változások hasznosításának képességét. Arra is lehetőséget ad, hogy szoftverét hosszú időn keresztül fenntarthatóvá tegye. Ezeket a célokat a következő módszerekkel éri el: v Az üzleti funkciók és az üzleti adatok egyesítése. A vállalat különféle csoportjai, vagy a vállalatok egy halmaza által megosztva használt összetevőket mindenki alkalmazhatja, mivel az összetevők megfelelnek olyan ipari szabványoknak, mint például a Webszolgáltatás leírónyelv (WSDL) és az Üzleti folyamatok végrehajtási nyelve (BPEL), melyek platform- és szállítófüggetlen szabványok. Az adatok következetesen ugyanolyan módon kerülnek ábrázolásra, lehetővé téve a szolgáltatásorientált architektúrájú alkalmazást alkotó összetevők közötti adatmegosztást. v Már meglévő alkalmazások és rendszerek hasznosítása. Az alkalmazások és rendszerek WSDL kód belsejébe helyezésével azok általánosan elérhetővé válnak a vállalat valamennyi alkalmazásfejlesztője számára, akik a jelenlegi alkalmazás fejlesztésén dolgoznak. Melyek a szolgáltatásorientált architektúra alapvető tervezési kérdései? v Az összetevők lazán kapcsolódnak egymáshoz. Ahhoz, hogy az egyik összetevő elérjen egy másikat, nincs szükség a másik összetevő adatszerkezeteinek, az egyéb összetevők meghívási módjának, a tranzakciók kezelésének stb. ismeretére. v Az összetevők konfigurálhatók. Az előző ábrán láthatóhoz hasonló szolgáltatásorientált architektúrájú alkalmazások megjelenítése emlékeztet a konfigurációs diagramok megjelenésére. Az új alkalmazások készítése során az összetevők számos különféle módon adhatók hozzá, távolíthatók el vagy állíthatók be az alkalmazásban. v Az összetevők képesek az együttműködésre. Bármely összetevő együtt tud működni egy másikkal, azokat a komponenseket is beleértve, melyek egy másik szállító fejlesztői környezetében kerültek létrehozásra. v Az összetevők helyfüggetlenek. Ahogy egy összetevő nem ismeri, vagy nem törődik egy másik összetevő megvalósítási részleteivel, úgy saját elhelyezkedését sem ismeri, és nem is foglalkoztatják ezek a részletek. Ezek a tervezési alapelvek együttesen egy olyan rugalmas architektúrát hoznak létre, mely képes alkalmazkodni a környezethez és ki is aknázni a gyorsan változó üzleti feltételeket. 8 WebSphere Integration Developer: Technikai termékáttekintés

13 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) A szolgáltatásösszetevő-alapú architektúra szolgáltatásorientált architektúrát biztosít, amelyet számos vállalat támogat, beleértve az IBM -et is. A szolgáltatásösszetevő-alapú architektúra (SCA) olyan platform- és szállítófüggetlen programozási modell, amely egyszerű és konzisztens eszközöket biztosít üzleti funkciók és adatok kifejezésére SOA szolgáltatások segítségével, függetlenül a részletek technikai megvalósításától. Ebben a részben megvizsgáljuk, hogy a WebSphere Integration Developer szoftverben az SCA szolgáltatások és szolgáltatási adatobjektumok hogyan valósulnak meg. A Szolgáltatás-összetevő architektúra specifikációja további részletekkel és a legújabb frissítésekkel szolgál e népszerű architektúrával kapcsolatban. Bár ez a szakasz a fejlesztéskor használt SCA komponensekre helyezi a hangsúlyt, a WebSphere Process Server architekturális áttekintése, amely a futásidejű dokumentációban érhető el, ezt a képet az architektúra futásidejű komponenseinek áttekintésével egészíti ki. Szolgáltatásösszetevők A szolgáltatásösszetevő egy szolgáltatás megvalósítását konfigurálja. A szolgáltatásösszetevőket szabványos blokkdiagrammal lehet ábrázolni. Az összetevők a következőkből tevődnek össze: egy megvalósítás, mely a WebSphere Integration Developer eszközeinek használata során rejtetve marad, néhány felület, melyek az összetevő bemeneteit, kimeneteit és hibát határozzák meg, továbbá nulla vagy több hivatkozás. A hivatkozás egy másik szolgáltatás vagy összetevő felületét azonosítja, melyet ez az összetevő megkövetel vagy felhasznál. A felületet két nyelv egyikén lehet megadni: WSDL porttípusként vagy Java nyelven. A felület szinkron és aszinkron együttműködési stílust támogat. Az összetevő megvalósítása különféle nyelveken készülhet el. Az ajánlott felülettípus a WSDL, így az ismertetők és példák is következetesen a WSDL felülettípust alkalmazzák. Azonban a Java felület támogatott és alkalmazott a legtöbb esetben, amikor egy állapotnélküli munkamenet EJB komponens kerül importálásra (melyet később a következő témakör mutat be: Importálások és exportálások oldalszám: 15). Ha egy felülről lefelé épülő Java komponenst fejleszt, vagyis meghatározza a komponenst és később adja hozzá a Java megvalósítást, akkor is WSDL felületet kell használnia. Nem keverheti a WSDL felület alapú komponenseket a Java felület alapú komponensekkel. Szerzői jog IBM 2005,

14 Component Java Implementation Java Interface Reference WSDL Port Type WSDL Port Type Java BPEL State Machine Business Rule Selector Human Task Interface Map Mediation Flow Implementation Types Az alábbi képen egy összetevő látható középen. SajátÉrtékMegval nevű megvalósítása, az összetevő felületéhez hasonlóan Java nyelven íródott. Két hivatkozással rendelkezik: egy másik Java, valamint egy WSDL felülettel. Amikor ezt az összetevőt kezeli, akkor gyakorlatilag csak magát az összetevőt látja, ahogy az az alábbiakban is megfigyelhető. Az összetevőre egy másik összetevőből mutató hivatkozást vizuálisan az összetevő felületéhez vezető vonalként lehet megjeleníteni. Az ezen összetevőtől egy másik összetevőre mutató hivatkozást a hivatkozási pontból a másik összetevő felületéhez vezető vonalként lehet megjeleníteni. A hivatkozás egy olyan szolgáltatást képvisel, melyet ez az összetevő használ fel. A hivatkozás megnevezése, és csupán felületének kijelölése lehetővé teszi, hogy az alkotórész- megvalósítását meghatározó fejlesztő későbbre halassza a hivatkozás összerendelését egy tényleges szolgáltatáshoz. Ez a laza kapcsolódás, mely lehetőséget biztosít a késleltetett kötésre, valamint a megvalósítások újbóli felhasználására, jelenti az egyik kulcsfontosságú okot a WebSphere Integration Developer Szolgáltatásösszetevőarchitektúrájának felhasználására. Az összetevők tulajdonságokkal és minősítőkkel is rendelkezhetnek. A minősítő nem más, mint a felületekre és hivatkozásokra futás közben vonatkozó Szolgáltatási minőség (QoS) direktíva. 10 WebSphere Integration Developer: Technikai termékáttekintés

15 Szolgáltatási adatobjektumok A szolgáltatási adatobjektumok kiegészítik a Szolgáltatásösszetevő-architektúrát. A Szolgáltatásösszetevő-architektúra komponensekként meghatározza a szolgáltatásokat, valamint megadja a köztük lévő kapcsolatokat. A szolgáltatási adatobjektumok az összetevők közötti adatfolyamot határozzák meg. Minden összetevő bemenetként és kimenetként ad át információkat. Amikor egy szolgáltatás meghívásra kerül, akkor az adatobjektumok XML dokumentumként kerülnek átadásra, WSDL porttípus esetén literál dokumentumkódolással, Java felület esetén pedig Java objektumként. A Szolgáltatásösszetevő-architektúra szolgáltatásaiban az adatobjektumok jelentik az adatok és metaadatok előnyben részesített formátumát. Az összetevőkhöz hasonlóan a szolgáltatási adatobjektumok is elválasztják az adatobjektumot annak megvalósításától. Míg például egy összetevő együttműködik a vásárlási megrendelésekkel, addig maga a megrendelés a JDBC, EJB stb. használatával hajtja végre a frissítéseket az adatokon. A szolgáltatási adatobjektumok lehetővé teszik az integráció fejlesztője számára, hogy a köztes üzleti termékek kezelésére koncentráljon. A szolgáltatási adatobjektumok valójában átlátszóak az integráció fejlesztője számára. Ezeket egy szolgáltatási adatobjektumok Java specifikációkérés (JSR) határozza meg. Az alábbi ábrán a szolgáltatási adatobjektumok egy külső szolgáltatástól kerülnek átadásra egy exportálásnak, az exportálástól egy összetevőnek, az összetevőtől egy másik összetevőnek, a második összetevőtől egy importálásnak, majd az importálástól egy szolgáltatásnak. Az importálások és exportálások egy ezt követő, Importálások és exportálások című fejezetben kerülnek bemutatásra. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 11

16 Other Application Modules Service Data Object SCA Customerinfo Service Data Object Export MyValue Service Data Object SCA MyValue Service Data Object Import stockquote Other Application Modules Service Data Object Szolgáltatásminősítők A szolgáltatási minőségüket (QoS) közlő alkalmazásoknak futási környezetre van szükségük szolgáltatásminősítők meghatározásával. Ezek a szolgáltatás ügyfele és a célszolgáltatás közötti együttműködést irányítják. Minősítőket szolgáltatásösszetevő-hivatkozásokra, felületekre és megvalósításokra vonatkozóan is meg lehet határozni. Mivel a QoS értékek deklarációja a megvalósításra nézve külsőnek számít, ezeket az értékeket a megvalósítás módosítása nélkül megváltoztathatja, vagy különbözőképpen állíthatja be őket akkor, ha ugyanannak a megvalósításnak több példánya kerül felhasználásra különböző kontextusokban. A minősítők kategóriái a következők: v Tranzakció - szabályok a tranzakció típusára vonatkozóan v Tevékenység munkamenet - szabályok az aktív munkamenet csatlakoztatására vonatkozóan v Biztonság - szabályok a jogosultságokra vonatkozóan v Aszinkron megbízhatóság - szabályok az aszinkron üzenetkézbesítésre vonatkozóan 12 WebSphere Integration Developer: Technikai termékáttekintés

17 Modulok A modul nem más, mint egy olyan telepítési egység, mely meghatározza, hogy a köztes termékek mely együttese kerüljön csomagba egy vállalati archívum (EAR) fájlban. A modulon belüli összetevők teljesítményfokozás céljából kerülnek összeállításra, és adataikat referencia szerint adhatják át. A modul hatókör-kezelési mechanizmusnak tekinthető; vagyis a modul szervezeti határvonalat állít be a köztes termékek számára. A modul szolgáltatásösszetevők, importálások és exportálások együttese. A szolgáltatásösszetevők, importálások és exportálások ugyanabban a projektben és gyökérmappában helyezkednek el, mely az összetevők kapcsolatait megteremtő összeköttetéseket, valamint az importálásokhoz és exportálásokhoz szükséges kötéseket is tartalmazza. A modul az összetevői, valamint az importálások és exportálások által hivatkozott megvalósításokat és felületeket is tartalmazhatja, de ezeket más projektben, például egy könyvtár projektben is el lehet helyezni. A moduloknak két típusa létezik. Az első típus (a néha üzleti integrációs modulnak is nevezett) modul, mely számos olyan összetevőtípus választékát tartalmazza, melyek gyakran felhasználásra kerülnek az üzleti folyamatok támogatásához. A második típus a közvetítő modul nevet viseli, amely egy vagy több közvetítő folyam összetevőt, valamint nulla vagy több Java összetevőt tartalmaz, amely kiterjeszti a közvetítő folyam összetevőt. A modulok egy vagy több közvetítő folyam összetevőt tartalmazhatnak. Miért létezik két modultípus? Az első modultípus elsődlegesen üzleti folyamatok számára került kialakításra. A közvetítő modul olyan, mint egy átjáró a meglévő külső szolgáltatásokhoz, melyek általánosak a vállalati szolgáltatásbusz architektúrákban. Ezeket a külső szolgáltatásokat vagy exportálásokat az importálások vagy szolgáltatók egy közvetítő modulon keresztül érik el. A szolgáltatáskérő ügyfelek és a szolgáltatók közvetítő folyam segítségével történő szétválasztása rugalmasságot és hibatűrést kölcsönöz az alkalmazások számára, mely a szolgáltatásorientált architektúra célja is egyben. Például a közvetítő folyam naplózhatja a bejövő üzeneteket, továbbíthatja őket egy futás közben meghatározott adott szolgáltatásnak, vagy átalakíthatja az adatokat, hogy azok megfelelőképpen átadásra kerülhessenek egy másik szolgáltatásnak. Ezek a funkciók az idő előrehaladtával a kérő vagy a szolgáltatást nyújtó szolgáltatások módosítása nélkül vehetők fel, illetve változtathatók meg. A modul egy olyan szolgáltató alkalmazást eredményez, mely a WebSphere Process Server kiszolgálón kerül tesztelésre és telepítésre. A közvetítő modul által eredményezett szolgáltató alkalmazás a WebSphere Process Server, vagy a WebSphere Enterprise Service Bus kiszolgálón kerül tesztelésre és telepítésre. Mindkét modultípus támogatja az importálásokat és exportálásokat. Gyakran szükséges a megvalósítások, felületek, üzleti objektumok, üzleti objektumleképezések, szerepek, kapcsolatok és egyéb köztes termékek megosztása az egyes modulok között. A könyvtár egy olyan projekt, mely ezen megosztott erőforrások tárolására szolgál. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 13

18 Export Service Component Service Component Implementation Java R R Implementation Java R R Standalone Reference R Import A következő ábrán a modul egy exportálást, két importálást, és egy ezeket használó szolgáltatásösszetevőt tartalmaz. Az összeköttetés a felületek és hivatkozások összekapcsolásával kerül ábrázolásra. Service Import customerinfo Service Export myvalue WebService Service Component MyValueInst1 Service Import stockquote WebService A modul és közvetítő modul köztes termékei a következőket tartalmazzák: v Moduldefiníció - meghatározza a modult. v Szolgáltatásösszetevők - a modulban lévő szolgáltatások meghatározásai. A szolgáltatásösszetevő neve a modulon belül egyedi. A szolgáltatásösszetevő azonban tetszőleges megjelenő névvel rendelkezhet, ami jellemzően egy olyan nevet jelent, mely a felhasználó számára hasznosabb megnevezést biztosít. v Importálások - ezek az importálások definíciói, melyek a modul számára külső szolgáltatásokra vonatkozó hívások. Az importálások kötésekkel rendelkeznek, melyek az Importálások és exportálások fejezetben kerülnek bemutatásra. v Exportálások - ezek az exportálások definíciói, melyek az összetevők felfedéséhez kerülnek felhasználásra a modul szempontjából külső hívó felek számára. Az exportálások kötésekkel rendelkeznek, melyek az Importálások és exportálások fejezetben kerülnek bemutatásra. v Hivatkozások - ezek az egyik összetevőtől egy másikra mutató hivatkozások a modulon belül. 14 WebSphere Integration Developer: Technikai termékáttekintés

19 v Önálló hivatkozások - olyan alkalmazásokra mutató hivatkozások, melyek nincsenek Szolgáltatásösszetevőarchitektúra komponensekként meghatározva (például JavaServer oldalak), melyek lehetővé teszik ezen alkalmazások számára a Szolgáltatásösszetevő architektúra komponenseivel való együttműködést. Modulonként csak egy önálló hivatkozási köztes termék létezhet. v Egyéb köztes termékek - ezek közé WSDL fájlok, Java osztályok, XSD fájlok, BPEL folyamatok stb. tartoznak. Importálások és exportálások Az importálások és exportálások a modul külső felületeit vagy hozzáférési pontjait határozzák meg. Az importálások modulon kívüli szolgáltatásokat azonosítanak, melyeket így a modulon belülről lehet meghívni. Az exportálások lehetővé teszik az összetevők számára, hogy szolgáltatásokat biztosítsanak külső ügyfeleiknek. Az importáláshoz és exportáláshoz kötési információkra van szükség. Számos kötés áll rendelkezésére, és tanácsok segítik abban, hogy mely típus lehet megfelelő alkalmazása számára. Szolgáltatásimportálási és -exportálási kötések típusai Az importálások és exportálások kötési információkat igényelnek, melyek meghatározzák a moduloktól származó adatok átvitelének módját. Az importálási kötés azt az adott módot írja le, melynek révén a külső szolgáltatás összekapcsolásra kerül az importálási összetevővel. Az exportálási kötés azt az adott módot határozza meg, mellyel a modul szolgáltatásai elérhetővé válnak az ügyfelek számára. Az SCA vagy alapértelmezett kötés lehetővé teszi a szolgáltatás számára a többi modulban található szolgáltatásokkal folytatott kommunikációt. Egy importálás az SCA kötéssel együtt módot ad egy másik modulban lévő szolgáltatás elérésére. Egy exportálás az SCA kötéssel együtt lehetővé teszi egy szolgáltatás felajánlását az egyéb modulok számára. Egy webszolgáltatás-importálási kötés egy külső webszolgáltatást köt egy importáláshoz. Egy webszolgáltatás-exportálási kötés a külső ügyfelek számára webszolgáltatás formájában biztosít szolgáltatást. A webszolgáltatás kötés SOAP/HTTP (HTTP feletti SOAP) vagy SOAP/JMS (JMS feletti SOAP) szállítási protokollt használhat. Megjegyzés: A WebSphere Integration Developer több típusú JMS adatkötést támogat: JMS, MQ JMS és általános JMS. A webszolgáltatások kötéssel csak a JMS adatkötés típus támogatott. Ezért csak a SOAP/JMS szállítási protokoll támogatott. A következő szállítási protokollok nem támogatottak: SOAP/MQ JMS és SOAP/általános JMS. A SOAP/MQ (natív) szállítási protokoll szintén nem támogatott. A Hiperszöveg átviteli protokoll (HTTP) kötés, az előbbi webszolgáltatás-kötéssel ellentétben azt feltételezi, hogy a kötés natív HTTP alkalmazásokat kezel, és egy ezen közönség számára ismerősebb modellt biztosít. A külső szolgáltatás varázsló EIS rendszerbeli szolgáltatást képviselő importálásokat és exportálásokat hoz létre. A létrehozott kötések EIS típusúak. Egy EIS kötés szinkron kommunikációt biztosít az EIS rendszerben lévő szolgáltatással. A Java üzenetkezelési szolgáltatás (JMS), általános JMS, WebSphere MQSeries (MQ) és WebSphere MQSeries JMS (MQ JMS) kötések az üzenetkezelési rendszerekkel való együttműködéshez kerülnek felhasználásra, ahol az üzenetsorokon keresztül végzett aszinkron kommunikáció kritikus fontosságú a megbízhatóság szempontjából. Egy importálás állapotnélküli munkamenet EJB kötéssel is rendelkezhet (egy exportálás azonban nem). A szerelvény szerkesztő felsorolja a támogatott kötéseket és megkönnyíti elkészítésüket egy importálás vagy exportálás létrehozása során. A szerelvény szerkesztő tulajdonságok nézete minden importálás és exportálás információit megjeleníti. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 15

20 binding = "<SCA>" binding = "<WebService>" binding = "<EIS>" binding = "<HTTP>" binding = "<JMS>" binding = "<Generic JMS>" binding = "<MQ>" binding = "<MQ JMS>" binding = "<SCA>" binding = "<S-SEJB>" binding = "<WebService>" binding = "<EIS>" binding = "<HTTP>" binding = "<JMS>" binding = "<Generic JMS>" binding = "<MQ>" binding = "<MQ JMS>" Module Export MyService1 Service Component MyService1 Import AService Service Component MyService2 Megfelelő kötések kiválasztása Ebben a fejezetben az az eset kerül bemutatásra, amikor egy adott kötés jobban megfelel az alkalmazás igényeinek, mint egy másik. A WebSphere Integration Developer rendszerben elérhető kötések lehetőségek széles választékát biztosítják. Ez a lista segít felismerni, hogy egy adott kötéstípus jobban megfelel-e az alkalmazás igényeinek, mint egy másik típusú kötés. Az alábbi tényezők fennállása esetén fontolja meg egy SCA kötés használatát: v Minden szolgáltatás WebSphere Integration Developer modulokban található; vagyis nincsenek külső szolgáltatások v A különböző funkciókat különböző modulokba szeretné elkülöníteni, amelyek közvetlenül működhetnek együtt. v A modulok szorosan kapcsolódnak egymáshoz. A következő tényezők fennállása esetén fontolja meg egy webszolgáltatás kötés alkalmazását: v Az interneten keresztül egy külső szolgáltatást kell elérnie, vagy ugyanígy egy szolgáltatást kell biztosítania v A szolgáltatások lazán kapcsolódnak egymáshoz v Szinkron kommunikáció használata javasolt, tehát az egyik szolgáltatástól érkező kérés meg tudja várni a másik válaszát. v Az elért külső, vagy a nyújtani kívánt belső szolgáltatás protokollja SOAP/HTTP vagy SOAP/JMS. Az alábbi tényezők fennállása esetén fontolja meg egy HTTP kötés használatát: 16 WebSphere Integration Developer: Technikai termékáttekintés

21 v Egy külső szolgáltatást kell elérnie vagy egy szolgáltatást kell biztosítania az Interneten keresztül, és a HTTP modellen alapuló más webszolgáltatásokat használ, azaz olyan ismert HTTP műveleteket használ, mint például a GET, PUT, DELETE stb. v A szolgáltatások lazán kapcsolódnak egymáshoz v Szinkron kommunikáció használata javasolt, tehát az egyik szolgáltatástól érkező kérés meg tudja várni a másik válaszát. Az alábbi tényezők fennállása esetén fontolja meg egy EIS kötés használatát: v Egy EIS rendszeren lévő szolgáltatást kell erőforrás-csatoló segítségével elérnie v A teljesítmény fontosabb a megbízhatóságnál. A következő tényezők fennállása esetén fontolja meg egy JMS kötés alkalmazását: v Egy üzenetkezelési rendszert kell elérnie v A szolgáltatások lazán kapcsolódnak egymáshoz v A megbízhatóság fontosabb, mint a teljesítmény; vagyis a szinkron adatátvitellel szemben az aszinkron adatátvitel részesített előnyben. v Megjegyzés: Különböző típusú JMS kötések léteznek. Ha várhatóan SOAP-üzenetekkel valósít meg adatcserét a JMS használatával, fontolja meg a webszolgáltatás összerendelések használatát a SOAP/JMS protokollal. Lásd: Szolgáltatásimportálási és -exportálási kötések típusai oldalszám: 15. A következő tényezők fennállása esetén fontolja meg egy általános JMS kötés alkalmazását: v Nem az IBM-től származó üzenetkezelési rendszert kell elérnie v A szolgáltatások lazán kapcsolódnak egymáshoz v A megbízhatóság fontosabb, mint a teljesítmény; vagyis a szinkron adatátvitellel szemben az aszinkron adatátvitel részesített előnyben. v Megjegyzés: Különböző típusú JMS kötések léteznek. Ha várhatóan SOAP-üzenetekkel valósít meg adatcserét a JMS használatával, fontolja meg a webszolgáltatás összerendelések használatát a SOAP/JMS protokollal. Lásd: Szolgáltatásimportálási és -exportálási kötések típusai oldalszám: 15. Az alábbi tényezők fennállása esetén fontolja meg egy MQ kötés használatát: v Egy WebSphere MQ üzenetkezelési rendszert kell elérnie, és az MQ natív funkcióit kell használnia v A szolgáltatások lazán kapcsolódnak egymáshoz v A megbízhatóság fontosabb, mint a teljesítmény; vagyis a szinkron adatátvitellel szemben az aszinkron adatátvitel részesített előnyben. Az alábbi tényezők fennállása esetén fontolja meg egy MQ JMS kötés használatát: v Egy WebSphere MQ üzenetkezelési rendszert kell elérnie, de azt meg tudja tenni JMS környezetben, azaz a funkciók JMS részhalmaza elegendő az alkalmazás számára v A szolgáltatások lazán kapcsolódnak egymáshoz v A megbízhatóság fontosabb, mint a teljesítmény; vagyis a szinkron adatátvitellel szemben az aszinkron adatátvitel részesített előnyben. Az alábbi tényezők fennállása esetén fontolja meg egy EJB összerendelés használatát: v Az összerendelés egy importált szolgáltatáshoz tartozik, mely önmagában egy EJB, vagy az EJB ügyfelek számára hozzáférhetőnek kell lennie. v Az importált szolgáltatás lazán kapcsolódik. v Nincs szükség állapotnyilvántartó EJB együttműködésre. v Szinkron kommunikáció használata javasolt, tehát az egyik szolgáltatástól érkező kérés meg tudja várni a másik válaszát. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 17

22 A szolgáltatásmegvalósítás típusai A szolgáltatásmegvalósítás típusai a szolgáltatásösszetevők megvalósításait jelentik. Ebben a szakaszban a szolgáltatások általános megvalósításai kerülnek bemutatásra. Ezek a megvalósítások a szerelvény szerkesztőbeli szolgáltatásokban és/vagy a BPEL folyamatokon belül jelennek meg. Java objektumok Az összetevők Java megvalósítására Java objektumként szokás hivatkozni. Az egyik általános megvalósítás egy Java nyelven írt összetevő. Ezt a megvalósítást néha "egyszerű Java objektumnak" (POJO) szokás becézni. Általában ez a megvalósítás WSDL felülettípusú lesz, bár a megvalósítás Java felülettel is rendelkezhet. Ha több felület került megadásra, akkor nem keverheti a WSDL felületeket a Java felületekkel. Azt azonban megteheti, hogy "egyesít" egy WSDL felületek készletével létrehozott alkalmazást egy Java felületek halmazával rendelkező alkalmazással. Az Üdvözlő nézet példák galériája tartalmaz egy olyan példát, mely bemutatja, hogyan történik mindez. A Java objektum kezelése során a kód rejtett marad a felhasználó elől a szerkesztők környezetén belül. A Java objektum használható közvetítő modulban. WebSphere Process Server vagy WebSphere Enterprise Service Bus kiszolgálóra telepíthető. BPEL folyamat A BPEL folyamat összetevő egy üzleti folyamatot valósít meg. Megvalósítási nyelve az Üzleti folyamat végrehajtási nyelv webszolgáltatások számára (BPEL4WS) ipari szabvány, és annak IBM kiterjesztései. A BPEL folyamat több elemi szolgáltatás használatán keresztül egy potenciálisan hosszan futó folyamatot valósít meg. A folyamatszerkesztőben létrehozott BPEL folyamat az alábbiakra képes: v Vezérlésifolyam-diagramok segítségével leírja az egyéb szolgáltatások finomhangolását v Változók használatával fenntartja a folyamat állapotát v Kifinomult hibakezelést használ v Támogatja az aszinkron eseményeket v A bejövő kéréseket megfeleltetési halmazok segítségével összefüggésbe hozza az adott folyamatok megfelelő példányával, hogy megjelölje a kérésen belüli, példányt azonosító üzleti adatokat (például egy ügyfélazonosítót) v Kifinomult kompenzációtámogatás révén kiterjesztett tranzakciókat biztosít Ezen általános BPEL elemeken kívül a WebSphere Integration Developer ki is terjeszti a BPEL folyamatokat, hogy bevonja az embereket az emberi feladat támogatással rendelkező folyamatokba. Például ez a kiterjesztés kiegészítheti a folyamatot azzal a követelménnyel, hogy a hitelkérelmet egy személynek kell jóváhagynia. A folyamatszerkesztő a BPEL szerkezetek vizuális ábrázolását használja az üzleti folyamatok gyors és egyszerű összeállításához. 18 WebSphere Integration Developer: Technikai termékáttekintés

23 A BPEL folyamat közvetítő modulban nem használható. Azt csak WebSphere Process Server kiszolgálón lehet telepíteni. Állapotgépek Az állapotgép alternatív módszert biztosít az üzleti folyamatok létrehozásához. Az állapotgép inkább változó állapotokhoz, és nem egy vezérlésfolyamhoz kapcsolódó folyamatok számára megfelelő megoldás. Az egyes állapotok meghatározzák, hogy a köztes termékek mit tehetnek az adott időpillanatban. Az állapotgép az állapotok ezen halmazának megvalósítása. Az állapotgépek általános módszert nyújtanak az egymással összefüggő állapotok adott folyamaton belüli megjelenítéséhez. Ismerős állapotgép például egy italadagoló automata. Bedob néhány érmét a gépbe, és a remélhetőleg kiadott itallal együtt megkapja a pontos visszajáró összeget, ahogy az állapotgép a bedobott érmék alapján mechanikusan meghatározza a visszaadandó pénzérméket. Az alábbi ábrán egy állapotgép szerkesztővel létrehozott tipikus állapotgép figyelhető meg. Az állapotgépben egy elem megvásárlása és az ügyfélnek való kiszállítása zajlik le. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 19

24 Állapotgép közvetítő modulban nem használható. Azt csak WebSphere Process Server kiszolgálón lehet telepíteni. Üzleti szabályok Az üzleti szabályok az üzleti folyamatokat és az állapotgépeket egészítik ki. Ha létezik például egy változót tartalmazó feltétel, akkor egy üzleti szabály futás közben módosíthatja a kérdéses változó értékét. A vizuális programozási nyelv segítségével létrehozott üzleti szabályok a kontextus alapján hoznak döntéseket. A döntések egyszerűek vagy összetettek lehetnek. Az üzleti szabályok nem procedurálisak, és a szabályok az alkalmazástól függetlenül módosíthatók. Az üzleti szabályok a kontextus alapján egy folyamat kimenetelét határozzák meg. Az üzleti szabályok a mindennapos üzleti helyzetekben döntések meghozatalához kerülnek felhasználásra körülmények egy adott halmaza alapján. Ehhez a döntéshez számos szabályra lehet szükség az összes körülmény lefedése céljából. Az üzleti folyamaton belüli üzleti szabályok lehetővé teszik az alkalmazások számára a változó üzleti feltételekre való gyors válaszadást. Például egy biztosítótársaság esetében egy autóbiztosítást a kérelmező számára jóváhagyó üzleti szabály a következőképpen állítható össze: Ha a kérelmező egy 25 évesnél idősebb férfi, és az autó a sportautók kategóriájába tartozik, továbbá a kérelmező már több, mint 5 éve a társaság biztosított ügyfele, akkor 100 dolláros havi biztosítási díj mellett jóvá lehet hagyni a biztosítási kérelmet. A WebSphere Integration Developer számos megközelítési módot kínál az üzleti szabályok létrehozásához. Ha-akkor szabályokat vagy döntési táblákat állíthat össze, melyek egyformán a folyamat kimenetelét alakítják ki. Vegye figyelembe, hogy ezek a szabályok függetlenek magától a folyamattól, ami azt jelenti, hogy a szabályokat bármikor megváltoztathatja, anélkül, hogy a folyamatot is újból létre kellene hoznia. Például a vállalat elhelyezkedésétől függően rendelkezhet egy olyan szabállyal, mely a következőket mondja ki: Ha a dátum december 26. és január 1. közé esik, akkor fel kell kínálni egy 20%-os ünnepek utáni kiárusítási kedvezményt. Ha azonban az eladások nem elég eredményesek, akkor bármikor 40%-ra módosíthatja a kedvezményt. 20 WebSphere Integration Developer: Technikai termékáttekintés

25 Üzleti szabályok közvetítő modulban nem használhatók. Azokat csak WebSphere Process Server kiszolgálón lehet telepíteni. Kiválasztók Az integrált alkalmazások számos együttműködési módot tartalmaznak. A kiválasztó egy ügyfélalkalmazástól származó művelet továbbítására szolgál néhány lehetséges összetevő egyikéhez, megvalósítás céljából. Az összetevőhöz való továbbítás dátumok alapján történik. Például következzen egy dátumon alapuló továbbítás: Az iskola kezdete előtt két héttel fel kell ajánlani egy speciális iskolakezdési árengedményt az iskolával kapcsolatos árukra. Az üzletek számos ilyen dátum alapú továbbítással rendelkezhetnek. A kiválasztó egy dátum alapján futás közben hozza meg az egyik továbbítás kiválasztásához kapcsolódó döntést. Ha például csaknem elérkezik az iskolakezdés ideje, akkor az előző iskolakezdési ajánlat kerül meghívásra. Ha azonban épp az iskola vége előtti időszak jött el, akkor a gyerekeket a nyárra felkészítő ajánlatot lehet felkínálni. A kiválasztó közvetítő modulban nem használható. Azt csak WebSphere Process Server kiszolgálón lehet telepíteni. Emberi feladat Az emberi feladat összetevő egy személy által végrehajtott feladatot valósít meg. Emberi közreműködő bevonását ábrázolja az üzleti folyamatban. Alkalomadtán embereknek kell beavatkozniuk az üzleti folyamatba. Például egy ügyfél olyan árucikket kíván megvásárolni, mely meghaladja hitelkeretét. Az emberi feladat lehetőséget ad arra, hogy közbeavatkozzon és hatálytalanítsa azt az üzleti szabályt, mely megakadályozza, hogy az ügyfél lebonyolítsa a vásárlást. Az emberi feladat attribútumokkal is rendelkezhet, mely például a feladat tulajdonosának beállítása, vagy egy kiterjesztési folyamat biztosítása lehet abban az esetben, amikor a megadott személy nem érhető el. Az emberi feladat összetevő felismeri annak realitását, hogy számos folyamat igényel emberi beavatkozást az áttekintési, vizsgálati és jóváhagyási feladatok esetén. 3. fejezet Szolgáltatásösszetevő-alapú architektúra (SCA) 21