1. SZERVEZETI ARCHITEKTÚRA FOGALMA A az architektúra kifejezés mögött meghúzódó különböző jelentésekkel találkozhatunk – jellemzően az informatikai alkalmazásokkal és rendszerekkel kapcsolatban. Az architektúra kifejezésnek több mellékjelentése van a szervezeti stratégia szintjén. Az általános architektúra tervezési elvek alkalmazhatók az informatika olyan felépítése és kialakítása céljára, amely a szervezeti, üzleti stratégiához történő illeszkedést valósítja meg. ▪
Azoknak a stratégiai és architekturális tervezési elveknek a gyűjteménye. Amely magában foglalja az információ, szervezeti (vállalati) információrendszer és a műszaki, informatikai architektúrát.
Az információrendszer vagy informatikai stratégiai tervezés (IS/IST Strategic Planning, ISSP) és a szervezeti informatikai architektúra tervezés bensőséges kapcsolatban áll egymással (Ld. 1. ábra). A szervezeti informatikai architektúra készítés sok területen segíteni tudja a stratégiai tervezést, az informatikai fejlesztések, a projekt portfolió alapjait tudja megteremteni. Szervezeti architektúra (Ld.[3]) két formában jelenik meg, egyrészt az informatikai stratégiai tervezés folyamatának kísérője, másrészt mint egy élő organizmus, amelyik ésszerű módon alkalmazkodik a környezetéhez. Az informatikai stratégiai tervezés fekteti le a ciklikus szervezeti architektúra tervezés alapelveit. Az információ, a szervezeti és a műszaki, informatika architektúra az informatikai környezet és annak irányítási folyamatainak egészén átívelő, a részek közötti együttműködést megteremtő szinten létezik, és ezek az architektúra szintek kölcsönösen támogatják egymást. Az alkalmazási (szoftver) architektúra akkor lép működésbe, amikor egy egyedi információrendszer beszerzéséről vagy kifejlesztéséről van szó. A szervezet folyamatos irányítási, igazgatási tevékenység
Szervezeti (üzleti) tervezés
Szervezeti (üzleti) célok, kritikus sikertényezők, szervezeti funkciók, szervezeti felépítés, korlátok, perem feltételek stb.
Informatikai stratégiai tervezés
Információrendszer célok, kritikus sikertényezők, struktúra, korlátok, perem feltételek stb.
Információ architektúra
Szervezeti (vállalati) információrendszer architektúra
Műszaki, informatikai architektúra
Megoldások, alkalmazási rendszer, architektúra
1. ábra Stratégiai tervezés és a szervezeti informatikai architektúra tervezés folyamata 1.1. Információ architektúra Az információ architektúra nézőpont a szervezet által végzett tevékenységekkel és a hozzájuk szükséges információkkal. Az adatok és tevékenységek magas szintű nézete teremti meg a szervezeti szintű követelményelemzés alapjait a szervezeti (vállalati) információrendszer architektúra kialakítása során.
▪
A szervezet által igényelt és használatban lévő információ szerkezete.
Az információ architektúra kialakításával kapcsolatos leglényegesebb tevékenységek: – A szervezet információ szükségleteinek feltárása. A legfontosabb szervezeti (vállalati, üzleti) tények, adatok felismerése és ezeknek megfogalmazása a szervezet (vállalati, üzleti) információ szükségleteinek formájában. – Az információ architektúra meghatározása. Az architektúra meghatározása a következő módszereket használja: párhuzamos lebontás (dekompozíció), értéklánc elemzés, és eseményelemzés. – A funkciók közötti függőségek elemzése. A funkciók részekre bontása (dekompozíció) érvényességének ellenőrzése, továbbfinomítása, és a függőségek feltárása. – Az entitások és köztük fennálló kapcsolatok meghatározása. Az információ architektúra adat oldalát pontosítja – lényegében ez egy szervezeti szintű adatmodellezési tevékenység. – Az információ szükségletek leképezése. Az entitás típusok teljes listáján szereplő elemek és a feltárt információ szükségletek listáján szereplő elemek összerendelése. – Az entitás típusok használatának elemzése. A szervezeti (vállalati, üzleti) funkciók által az entitás típusokon kiváltott hatások feltárása, helyességének ellenőrzése, a tevékenység hierarchia és entitás kapcsolat diagram tovább finomítása, pontosítása. – A szervezeti funkciók és az entitás típusok leképezése a szervezeti egységekre. A szervezeti egységek és az adatok összekapcsolása, a szervezeti tevékenység hierarchia elemzésével és annak feltárásával, hogy az információ architektúra hogyan használja az adatelemeket. 1.2. Szervezeti (vállalati, üzleti) információrendszer architektúra Szervezeti (vállalati, üzleti) információrendszer architektúra leírja szervezeti (vállalati, üzleti) információrendszereket és azokat az információkat, amelyeket a rendszerek elsődlegesen tárolnak az információ architektúra támogatása érdekében. Szervezeti (vállalati, üzleti) információrendszer architektúra tudja jelezni a kezdetekben, hogy vajon a jelenlegi rendszerek (gyakran megörökölt, elavult vagy régi rendszerek – legacy systems) újra hasznosítására, továbbfejlesztésére, illetve új szervezeti (vállalati, üzleti) információrendszerek kifejlesztésére van szükség. Szervezeti (vállalati, üzleti) információrendszer architektúra kialakítása vezérli általában a jelenlegi információrendszerek és a szervezeti tevékenységek, a szervezeti információrendszerek és a kapcsolófelületek közötti összerendelést. A szervezet és az informatika irányítása szempontjából a szervezeti (vállalati, üzleti) információrendszer architektúra adja meg azt a környezet, amelyben az új rendszerek kialakítására irányuló kezdeményezések mérlegelhetők. ▪
A szervezet összes információrendszerének struktúráját és tartalmát (információ és funkció értelmében) definiálja.
1.3. Műszaki, informatikai architektúra A műszaki, informatikai architektúra elsősorban azt a platformot írja le, amely szervezeti (vállalati, üzleti) információrendszer architektúra és az információ architektúra
támogatásához szükséges hardver, szoftver és infrastruktúra elemeket tartalmazza. Ezen kívül a műszaki, informatikai architektúra a platform elemeinek integritását, összhangját tartja fenn. Az információ-technológia megoldások kivitelezése, a műszaki, technológiai környezet tervezése, az információ-technológia világának változására adandó reagálások nagy mértékben függnek műszaki, informatikai architektúra definíciójától. A műszaki, informatikai architektúra kialakítása nemcsak azért felelős, hogy a technológiai környezet korrekt módon működjön, hanem a működéshez szükséges funkciók struktúráját is meghatározza. ▪
Az architektúra központi fogalma a platform, amely a szervezet stratégiai vagyona. A platform magában foglalja az architektúrában definiált összes olyan kulcs fontosságú szolgáltatást, amely rendelkezésre áll az egyes szervezeti (vállalati, üzleti) információrendszerek számára az infrastruktúrán belül.
1.4. Az alkalmazási architektúra Az alkalmazási architektúra az egyes alkalmazásokkal és rendszerekkel foglalkozik. Természetesen átfedés van általában a műszaki, informatikai architektúra és az alkalmazási architektúra között. A műszaki, informatikai architektúra a szabványokkal, technikákkal és az alkalmazási architektúra szabályozási és irányelvekkel kapcsolatos oldalaival foglalkozik. Az alkalmazási architektúra koncepcionális megalapozását és keretrendszereit a műszaki, informatikai architektúra szolgáltatja.
Szervezeti architektúra Funkcionális architektúra
Információs architektúra
Alkalmazási architektúra
Műszaki architektúra Termék architektúra Szervezeti biztonsági architektúra 2. ábra A szervezeti célkitűzések teljesítése ▪
A szoftver rendszer szerkezetére, szervezésére vonatkozó lényeges döntések halmaza, valamint azoknak az architektúra tervezési elveknek a gyűjteménye, amely irányítja a szoftver szerkezet kialakítását.
1.5. A szervezet (vállalati, üzleti) architektúra alternatív definíciói Az előbbiekben láttuk, hogy miután az informatikában megjelent az architektúra fogalma az 1960-as években, fokozatosan alakultak ki részletesebb architektúra fogalmak és azok definíciós kísérletei az informatika, az információ-technológia fejlődésével párhuzamosan. A szervezet (vállalati, üzleti) architektúra fogalma is több mint 20 éves múltra tekint vissza, de ennek ellenére nem mondható el az, hogy a fogalom kikristályosodott volna. A különböző definíciók segítenek körül járni és megérteni a probléma kört. Néhány létező és szakmai közösségekben forgalomban levő definíció : IEEEarchitektúra ▪ Architektúra (Ld. [4]) Az architektúra egy rendszer alapvető szervezése, amely az alkotó elemeiben, azok egymáshoz és a környezethez való viszonyában, valamint a tervezését és evolúciós továbbfejlődését irányító elvekben testesül meg. TOGAFarchitektúra ▪ Open Group’s Architectural Framework (TOGAF) meghatározása: Az architektúrának két jelentése van a szövegkörnyezettől függően: (1) egy rendszer formális leírása, vagy az alkotó elemeinek szintjéig kibontott részletes kivitelezési terv; (2) Az alkotó elemek struktúrája, egymáshoz való kapcsolatuk, és a tervezésüket és evolúciós tovább fejlesztésüket vezérlő elvek és útmutatók összessége. [6] 1. táblázat A jelentősebb architektúra megközelítések és szintjeik Architektúra rétegek
Számítógép architektúra
OSI modell Hálózati szoftver architektúra
Elosztott rendszerek architektúrája
Szervezeti (vállalati) architektúra
0. szint
Digitális logika
Fizikai
Fizikai réteg / hardvererőforrások
Műszaki, informatikai, technológiai architektúra (hardver, szoftver, ICT kommunikáció )
1. szint
Mikro-architektúra
Adatkapcsolati réteg
2. szint
Utasításrendszer architektúra
Hálózati réteg
3. szint
Operációs rendszer
Szállítási réteg
Operációs rendszer
Alkalmazási rendszer (szoftver) architektúra
4. szint
Assembly
Viszony réteg (Session)
Hálózati réteg
Információrendszer architektúra
5. szint
Magas szintű programozási nyelvek
Megjelenítési réteg
Köztes réteg (Middleware)
Információ architektúra
Alkalmazási réteg
Alkalmazási réteg
Szervezeti (vállalati, üzleti) architektúra
6. szint
A szervezeti (vállalati, üzleti) architektúrával kapcsolatos tevékenység a szervezet átalakítás, transzformáció irányítása részének tekinthető. A Hiba! A hivatkozási forrás nem található. a szervezet átalakítás folyamat irányításának e gy olyan részletezett képét mutatja, amely három részterületet tartalmaz: a stratégát, az
architektúrát és a szervezeti (vállalati, üzleti) programok irányítását, amely bizonyos projektek egye-egy programba történő csoportosítását jelenti.
2. SZERVEZETI ARCHITEKTÚRA MÓDSZEREK, MEGKÖZELÍTÉSEK A szervezeti (vállalati) működés egyre komplexebbé válásával egyre fontosabbá vált az architekturális megközelítés, mely egyfajta rendszerezett, strukturált gondolkodásmódot jelent. Ez a fajta megközelítés alapot nyújt – ahogy azt korábban már láttuk (1.5) - a szervezet átalakításánál informatikai rendszerfejlesztési programok és projektek irányítására és megszervezésére. A gazdaság és társadalom fejlődésével, a globalizációval párhuzamosan a szervezeteknek (vállalatoknak) egyre komplexebb és szerteágazóbb feladatokat kellett megoldani, a hatékonyabb vállalaton belüli és vállalatok közötti együttműködés érdekében. Az architektúra alapú megközelítése először a műszaki, információtechnológiai, informatikai területeken nyert létjogosultságot, de lassan a szervezetek (vállalatok) vezetésével foglalkozó szakemberek is felismerték előnyeit. Fokozatosan a szervezeti (vállalati, üzleti) stratégia alkotás, és szervezet fejlesztés integráns részévé vált a szervezeti (vállalati, üzleti) architektúra alapú megközelítés. A gyakorlati megoldások, a műszaki-tudományos megközelítések, valamint a szervezés-vezetés tudomány fejlődése során nemcsak különböző definíciók és meghatározások, hanem különböző megközelítések, módszerek, keretrendszerek jöttek létre. Az alábbiakban nem teljes körű ismertetését adjuk a legjelentősebb megközelítéseknek, röviden összefoglalva a jellemzőiket. Egy szélesebb körű feldolgozást a következő munkában lehet találni [1]. 2.1. Zachman féle szervezeti architektúra keretrendszer (The Zachman Enterprise Framework) A keretrendszer valójában egy olyan ontológia a szervezeti architektúra leírására, fejlesztésére, amely az idők folyamán (pontosan 1987 óta, [7,5]) komoly evolúción ment keresztül. A keretrendszer nem módszertan, mivel nem ad folyamat leírást, előírást a szervezeti architektúra kialakítására, hanem egy deklaratív leírása a szervezetnek (vállalatnak, üzletnek), egy struktúra a szervezeti (vállalati, üzleti) információrendszerek fejlesztésére. A későbbiekben több szervezet, több iparágban– a szerzők és a keretrendszer eredeti szándékai szerint - egy szervezeti szintű architektúra szemléletben a szervezetek folyamatainak fejlesztésére, javítására kezdték el széles körben használni. A keretrendszer tehát nem módszer, nem módszertan, nem tartalmaz architektúra kialakítására lépéseket, technikákat, nyelveket és folyamat leírást, folyamat-központú megközelítést. (Ld. [24]). Más informatikai terminológiát használva: meta-modellként szolgál, a szervezeti (vállalati, üzleti) architektúra kialakításához. 2.1.1. A keretrendszer oszlopainak jelentése A szervezeti (vállalati, üzleti) architektúra kertrendszer elemeit, egy két-dimenziós mátrixban, táblázatban adta meg Zachman. A táblázat oszlopainak megfelelő első dimenzió elemei, a vizsgált dolog egy-egy oldalának („aspect”) felelnek meg. Rudyard Kipling egy versében ezt a hat kérdést „ A hat derék szolgaként” fogalmazta meg 1. Az oszlopok fejlécében a következő kérdések találhatóak: Mit?, Hogyan?, Hol?, Ki?, Mikor? és Miért?. (Ld.3. ábra). A másik dimenzió, a táblázat sorainak megfelelő dimenzió, bizonyos szempontokat, perspektívát („perspective”), a keretrendszer egy-egy nézőpontját testesíti meg. Nevezetesen a következőket: a szervezeti (vállalati, üzleti) tervező („planner”), a tulajdonos („owner”), a tervező („designer”), a kivitelező / építő („builder”), alvállalkozó / 1
http://www.kipling.org.uk/poems_serving.htm . „Hat derék szolgát tartok. Ők tanítottak meg engem mindenre, amit csak tudok.”
beszállító, készítő („subcontractor”), és végül a működő szervezet („functioning enterprise”). A Zachman féle keretrendszer általános ábrázolása egy 6x6-os mátrix, aminek oszlopait a kérdések és sorait a nézőpontok határozzák meg. A keretrendszer elemeinek ábrázolása a táblázat celláival történik, amik a kérdő szavak és a nézőpontok metszéspontjai. Amióta John A. Zachman publikálta módszertanát, azóta az épületek, repülőgépek, és más komplex ipari termékek leíró ábrázolásának, architektúrájának metamodellezéséhez is felhasználják ezt a megközelítést. Ez bizonyítéka a Zachman féle keretrendszer létjogosultságának. A keretrendszer segítséget ad a szervezet céljainak, működésének feltételeinek, környezetének vizsgálatára, a szervezet és az informatikai funkció vezetési szintjein elhelyezkedő vezetőkkel, kezdve a felső vezetéssel a stratégiai szinten. 1. oszlop: Adat (mit) : Ez az oszlop a szervezet (vállalat, üzlet) működéséhez szükséges adatokkal foglalkozik, az adatok szerkezetével, hogyan tárolják az adatokat stb. 2. oszlop Funkció (hogyan): Ez az oszlop a szervezet (vállalat, üzlet) működésével foglalkozik. A szervezet stratégiai célkitűzéseit, „küldetését” fordítja le a szervezeti működés egyre részletesebb leírásaira. 3. oszlop Hálózat (hol): Ez az oszlop a szervezet (vállalat, üzlet) elemeinek, tevékenységeinek földrajzi elhelyezkedésével, szétosztottságával foglalkozik. 4. oszlop Személyek (ki): Ebben az oszlopban a szervezetben munkát végzőkkel, a munkafeladatok személyekhez rendelésével, az emberek közötti kapcsolatokkal foglalkoznak. 5. oszlop Idő (mikor): A valóságos idő egy absztrakciójával foglalkozik azért, hogy az események közötti kapcsolatokat meg lehessen tervezni, amelyek meghatározzák a teljesítmény kritériumokat és számszerűsíthető szolgáltatási szinteket szabnak meg a szervezet erőforrásai tekintetében. 6. oszlop Motiváció (miért): A szervezet (vállalat, üzlet) motivációjának meghatározásával leíró formában foglalkozik, és általában célok és elérésükhöz szükséges eszközök megfogalmazásán keresztül jeleníti meg a szervezet motivációit. Az eszközök itt általában a cél eléréséhez használt módszert jelentik. 2.1.2. A keretrendszer sorainak jelentése: 1. sor: Kiterjedés, terjedelem : Az első architektúra vázlatot jelenti, amely egy olyan „gombócokat” tartalmazó ábra, amely nagyvonalakban leírja az elképzelt végső struktúrának a kiterjedését, határait, nagyságát, körvonalait, térbeli kapcsolatrendszerét és alapvető céljait. Tulajdonképpen egy szervezeti (vállalati, üzleti) tervező vagy befektető számára szóló vezetői összefoglalónak felel meg, akinek a leendő rendszer kiterjedéséről, a várható költségekről és a nyújtandó szolgáltatásokról kellene egy előzetes képet kapnia. 2. sor: Szervezeti (vállalati) modell : A következő ábrázolás, az architektúra tervezőé, aki a rendszer végső felépítését annak a tulajdonosnak a szemszögéből, perspektívájából írja le, akinek majd naponta együtt kell élnie ezzel a szervezeti (vállalati, üzleti) környezettel. Megfelel a szervezeti (vállalati, üzleti) modellnek, amely a szervezeti (vállalati, üzleti) működés tervét testesíti meg és a legfontosabb szervezeti (vállalati, üzleti) egységeket, elemeket, folyamatokat és köztük fennálló kölcsönhatásokat jeleníti meg.
3. sor: Rendszer modell: Ez az architektúra tervkészítő tervezete, amely az eddigi modell ábrázolásokat lefordítja a rendszertervező szemszögének, perspektívájának megfelelő részletes műszaki leírásokra, specifikációkra. 4. sor: Technológia modell: (műszaki, informatikai modell) A szállítónak általában az architektúra tervkészítő tervezetét át kell dolgoznia azért, hogy a kivitelező szemszögéből, perspektívájából értelmezhető legyen, visszatükrözze azokat a korlátokat és peremfeltételeket, amelyek a rendelkezésre álló eszközökből, technológiákból, műszaki lehetőségekből, anyagokból állnak. A kivitelező (rendszerkészítő) tervezete a technológiai modellnek felel meg, amelynek a feladata az , hogy az információrendszer modellt a programozási nyelvek, a számítógép perifériák és más technológiai elemekhez illessze, adaptálja. 5. sor: Részletes specifikáció: Ez a modell megfelel annak a részletes specifikációnak, amelyet azoknak a programozóknak adnak át, akik egyes egyedi modulok programozását végzik el tekintet nélkül arra a környezetre illetve annak szerkezetére, amiben dolgoznak, és / vagy a folyamat tervezők kapják meg ezeket a terveket azért, hogy a munkafolyamatok részletes tervét elkészítsék. (a rendszer tényleges megvalósítása, telepítés, üzembe helyezés). 6. sor: Működő szervezet (vállalat) : Végül, a rendszert elkészítik és a szervezet részévé válik. Ebből a szemszögből a program listák, az adatbázis specifikációk, a hálózatok és így tovább jelennek meg, amelyek mindegyike egy bizonyos rendszert alkot. Ezeket a leírásokat az adott rendszerhez illeszkedő, specifikus műszaki, informatikai terminológiával írják le. J. A. Zachman S. H. Spewak
Entitások = mit? adatot, adat architektúra
Tervez ő A szervezeti célkit űzések/ feladatok listája kiterjedés
Tevékenységek = hogyan? funkciót alkalmazási architektúra A szervezeti folyamtok listája
Helyek = hol? hálózatban m űszaki architektúra A szervezet telephelyeinek listája
Tulajdonos Szervezeti modell
Sematikus modell Szervezeti folyamatmodell
Fejleszt ő Információs rendszer modell Kivitelez ő Technológiai modell
Logikai adat modell
Végrehajtó (alvállalkozó) Részletes specifikáció M űködő vállalat/intézmény
Adat definíció szótár vagy könyvtár
A rendszer földrajzi elhelyezkedésének architektúrája Rendszerterv Rendszerarchitektúra /technológiai architektúra Programok Hálózati támogató szoftver architektúra elemek
Adatok
Funkciók
Fizikai adatmodell.
Szervezeti logisztikai rendszer
Alkalmazási architektúra
Hálózat
Személyek = ki?
Id ő = mikor?
A szervezet legfontosabb egységeinek listája Munkafolyamat modell
A szervezetnek A szervezeti fontos események célok/stratégiák listája listája
Kiterjedés
Központi munkaterv
Üzleti, szervezeti terv
Szervezeti modell
Ember-gép kapcsolati architektúra
Feldolgozási struktúra
Szervezeti szabályok
Rendszer modell
Megjelenítési architektúra
Ellen őrzési struktúra
Szabályzat tervezés
Technológiai modell
Biztonságtechnikai architektúra
Id őzítés definiálása
Szabályzat meghatározása
Elemek
Szervezet
Munkaterv
Stratégia
Motiváció =miért?
3. ábra Szervezeti (üzleti vállalkozás) architektúra Zachman. 2.2. ISO/IEC 42010 (IEEE Std 1471-2000) szabvány Ez a szabvány elsősorban a szoftver architektúra fogalmi szintű megragadása érdekében készült. Ezért az un. szoftverintenzív rendszerekre tekintettel dolgozták ki ISO/IEC 42010 szabványt, de a szoftverfejlesztés és a komplex rendszerek integrációjának kérdéseit is figyelembe vették. A nagy bonyolult rendszerek körébe értendők a beágyazott rendszerek, a rendszerek rendszerei, valamint az információrendszerek. A szabvány célja az előbbiekben felsorolt rendszerek szabványos formátumú leírására az alapok megteremtése. Ez a keretrendszer egy architektúra leírás tartalmát szabványosítja két fő szemszögből történő megközelítést használ fel erre a célra, a nézetet („view”) illetve a
nézőpontot („viewpoint”). A nézet azt jeleníti meg, amit a kiválasztott nézőpontból látni lehet.
1
Rendszer
1
1..n 1..n
Érintett fél 1..n
Architektúra
Architektúra
leírás
1..n Probléma
1..n
1..n 1..n
1..n
1..n Nézőpont
Nézet
1..n 1..n
1..n
Modell
4. ábra IEEE 1471 szabvány szerint a szoftver architektúra kulcs fontosságú fogalmai A modell legfontosabb alkotórészeinek leírása: — Rendszer – Alkotórészek, komponensek halmaza, amelyeket egy adott cél elérésére szerveztek meg. — Architektúra – Egy rendszer alapvető szervezési módja, amely megtestesül az alkotórészeiben, a köztük és a környezettel fennálló kapcsolataiban, továbbá a tervezését és továbbfejlesztését irányító elvekben. — Architektúra leírása – Az architektúra dokumentálására szolgáló termékek halmaza, amelyeket különböző nézetekbe vannak szervezve. — Nézet – Egy előre definiált nézőponttal összhangban, azaz bizonyos problémák, kérdések és ügyek perspektívájából a teljes rendszer ábrázolása, reprezentációja. — Nézőpont – Azoknak a konvencióknak a specifikációja (műszaki leírása), amelyeket egy nézet felépítésére és annak a felhasználására alakítanak ki. Olyan mintázat vagy sablon, amelyből az egyedi nézetek kifejleszthetők, meghatározva a nézetre vonatkozó célokat és a célközönséget (az érintett feleket), továbbá a nézet létrehozásához és elemzéséhez szükséges technikákat. — Modell – A nézet ábrázolása, reprezentációja., megjelenítése . — Érintett fél (Stakeholder) – Egyének, csoportok vagy szervezetek, akiknek valamilyen érdeke fűződik a rendszerhez vagy valamilyen közös ügye van a rendszerrel. Az érdekeket illetve a kapcsolatos ügyeket egy vagy esetleg több nézettel lehet reprezentálni.
3. A SZOLGÁLTATÁS ORIENTÁLT ARCHITEKTÚRA FOGALMA (SZOA) A Szolgáltatás Orientált Architektúra (Service Oriented Architecture – SOA) vállalati környezetben alkalmazott megoldás az információ architektúra. Ebben az architektúrában szolgáltatásnak nevezünk minden olyan logikai egységet, mely egy-egy specifikus részfeladatát oldja meg aaz összetett vállalati/szervezeti feladatoknak. Ezek a logikai egységek autonóm elemek, azonban mégsem teljesen különállóak, ugyanis szoros együttműködésükre van szükség az összetett feladatok megoldásához ([13]).
3.1. Az architektúra legfőbb jellemzői Az a tény, hogy külön kezelhetők ezek az elemek, a szolgáltatások, elősegítik egyúttal azok kézben tarthatóságát, mellékhatásoktól mentes programozásukat, napra készen tartásukat és skálázhatóságukat. Továbbá fontos kiemelni, hogy a már meglévő szolgáltatásokat nem csak egy rendszer képes használni, a szolgáltatások újrafelhasználhatóságát is elősegíti, mivel képesek ugyanazt a részfeladatot ellátni más-más környezetben is. Azonban nem csak ez az egyetlen pozitív hozadéka ennek a megközelítésnek. Mivel az internet szerepe egyre növekszik vállalati működés minden területén, így kiemelendő a SOA szerepe a szervezetek és rendszerek közötti kooperáció költségeinek csökkentésében is, mivel ez a technológia alapvetően hálózati erőforrásokra épít. Az egyes modulok, melyek az egész szoftverarchitektúrát alkotják, erőforrásaikat elérhetővé teszik a hálózat különböző kiszolgáló gépein, erőforrásain (szerverein) és a leendő felhasználó ezen keresztül tudja igénybe venni azokat. Tehát független, mégis egymással együttműködésre képes szolgáltatás egységekről beszélünk ([13]). Fontos a SzoA-val kapcsolatban platformfüggetlenség fogalmát megemlíteni, mint ennek a megközelítésnek az egyik alapvető tulajdonságát. A szolgáltatást igénybe vevő fél egy előre meghatározott csatlakozó felületen keresztül képes elérni a kívánt modult, függetlenül attól a rendszertől, mely a saját környezetében fut. Természetesen létrejöttek azok a szabványok, melyek biztosítják az egységes hozzáférést. Ilyenek az előre jól definiált kapcsoló felületek („interface”), valamint a kommunikációs és adatcsere protokollok, melyek függetlenítik a szolgáltatást a származási helyétől, azaz a fejlesztői környezettől ([11].). Kiemelendő, hogy a rendszert alkotó komponensek között úgynevezett „formális szerződések” vannak ([13]). Ez azt jelenti, hogy az egyes szolgáltatások ismerik egymás leíró dokumentumait, melyek az egyes alkotóelemek alapvető működési körülményeit, használati
feltételeit és további tulajdonságait írják le. Ennek a következményeként az elemek között ún. „laza csatolás” jön létre, ami azt jelent, hogy bár a szolgáltatások tudnak egymásról, ismerik egymást, mégis csak minimális függések léteznek az adatok és a funkcionális szolgáltatások tekintetében egyaránt – a szoftver modulok tervezésének alapelveivel összhangban. A szolgáltatások, szolgáltatási elemek autonómiájaazt jelent, hogy léteznek olyan elemek, melyek működésük felett teljes mértékben „egyeduralkodónak” számítanak, azaz működésükbe nem szól bele semmilyen külső rendszer, azonban elfordulhat az, hogy más szolgáltatásokkal együtt közös erőforrásokat használnak. Ezt a helyzetet az autonómia szolgáltatási szintjén megvalósuló autonómiának nevezzük ([10]). Azonban létezik egy teljesebb formája ennek a különállásnak, amikor az egység saját erőforrásait és működését is kizárólagosan felügyeli. Ez az úgynevezett „magasabb szintű autonómia” ([10]). Azonban mindenképpen szükséges hangsúlyozni, hogy ezek az önmagukban monolit, lényegében független és autonóm egységek együttműködve mégis komplex üzleti funkcionalitást tudnak létrehozni. Sajnos az utóbbi időben a szolgáltatásorientált architektúrát az egymással interakciót folytató elemek közvetett kommunikációjával azonosítják, ahol egy köztes elem – a szolgáltatási sín, az Enterprise Seervice Bus, ESB közbeiktatása segíti a szolgáltatás kliens és kiszolgáló oldalát egymás kölcsönös elérésében. Ez természetesen nem igaz. A szolgáltatásorientáltság megvalósulása nem csak egy közvetítő beiktatásáról szól, mivel léteznek pont-pont kapcsolattal megvalósuló megoldások is, ahol az összes rendszerelem kapcsolódik egymáshoz. Ahhoz, hogy valóban SOA-ról beszélhessünk, a fenti kritériumok mindegyikének teljesülnie kell.
4. A SOA ELEMEI Vállalati környezetben jellemzően az alábbi ábrán bemutatott logikai architektúra megvalósulása terjedt el, vagy ennek kiépítése lett a cél. A rendszer részeinek/rétegeinek bemutatása e ábra segítségével történik:
5. ábra: SzOA megvalósítása nagyvállalati környezetben ([14]) 4.1. Háttér (Back-end)rendszerek Azokat a rendszereket sorolhatjuk ide, melyek mindegyike egy-egy üzleti funkciót hajt végre. Azonban ezek a funkciók sokszor nem csak egy adott rendszeren belül valósulhatnak meg, hanem más rendszerek is meghívhatják azokat. Így megkülönböztethetünk nyílt, illetve zárt funkciókat aszerint, hogy ki érheti el azokat. Mivel back-end rendszer lehet akár kész ún. dobozos termék, de akár saját fejlesztésű eszköz is, így elengedhetetlen a különböző kapcsoló felületek használata ezeknek az üzleti funkcionalitással rendelkező rendszereknek a felhasználásához ([12]).
4.2. Szolgáltatás komponensek A szolgáltatás komponenseit alkotó (SCA, más néven Service Component Architecture) réteg célja, hogy a szolgáltatási szintek számára - a SzOA elveknek megfelelően – segítse elő a meglévő funkciók elérését a nyilvános kapcsoló felületeken („interfészeken”) keresztül. Ebben a rétegben találhatók azok az elemi egységek, melyek önmagukban értelmezhető funkcionalitást valósítanak meg ([8]). Ezek kompozíciójából állnak össze a szolgáltatások.
5. SZOLGÁLTATÁSOK RÉTEGE Ebben a rétegben találhatók az elemi komponensekből felépülő egyszerű, vagy összetett szolgáltatások, melyek különböző funkcionalitást hordoznak magukban. A SOA egyik lényege az újrafelhasználhatóság. Ennek jegyében a back-end rendszerek komponensei - melyek a funkcionalitást magukban hordozzák - alakítják ki az úgynevezett szolgáltatáslogikát, a szolgáltatás logika rendezi össze különböző elemi szolgáltatásokat, egyséégeket, összetettebb szolgáltatásokká. Tulajdonképpen ezek a funkciók egy ún. middleware rétegen, köztes rendszeren keresztül válnak elérhetővé. Ezek alapján két csoportot különíthetünk el a szolgáltatásokon belül ([9]). Üzleti szolgáltatásoknak nevezzük az „üzletileg értelmezhető funkcionalitást megvalósító szolgáltatást”. Ilyenek lehet pl. a különböző lekérdezési metódusok (O-O értelemben véve), melyek ügyféladatokat hívnak meg, vagy egy új ügyfél felvétele egy számlanyitási folyamat részeként. Másik csoportot képezik a technológiai szolgáltatások, melyek nehezen foghatók meg üzleti oldalról, inkább az üzleti folyamatok támogatásában van jelentős szerepük.
5.1. Üzleti folyamatok és a front-end alkalmazások rétege A tevékenységek kisebb-nagyobb együttesét akkor tekinthetjük üzleti folyamatnak, ha azok túlmutatnak a funkciókon és támogatják vállalati célokat. Itt már több folyamatlépésként megjelenő, más-más funkciókat biztosító rendszerek szolgáltatásai jelennek meg összerendezve. Ez jelentheti pl. egy ügyfél számlamódosításának teljes folyamatát, amely nem csak az adatok lekérését, hanem módosító műveleteket és dokumentumkezelést is magában foglal. Azok a sok ablakos alkalmazások, melyek a front-office oldalon találhatók tehát, melyet az ügyfélkezelő személyek használnak - magukban kell, hogy hordozzák a teljes ügyfélkezelési folyamat elvégzéséhez szükséges szolgáltatáscsomag hívásának képességét. Ezeket nevezzük front-end rendszereknek. Azonban ez nem azt jelenti, hogy front-end szinten megy végbe a feldolgozás, hanem, amikor egy kérés érkezik a front-end rendszer felől, akkor az a back-end felé továbbítódik, mely elvégzi a megfelelő funkció kiválasztását és végrehajtja a feldolgozást, majd az eredményeket visszaküldi az azt megjelenítő felület számára. 5.2. A szolgáltatási sín (ESB) A SzOA egyik potenciálisan fontos, habár nem elengedhetetlenül kötelező alkotó eleme az ESB (Enterprise Service Bus), azaz szolgáltatási sín, melynek elsődleges célja az
alkalmazásintegráció megvalósítása. Lényege, hogy a szolgáltatást nyújtók, és azt igénybe vevők nem állnak közvetlen kapcsolatban egymással, hanem mindketten ezen a köztes rendszeren, middleware rétegen keresztül kommunikálnak. A dobozos, vagy akár saját fejlesztésű back-end rendszerek interfészei változatos képet mutatnak a valóságban, így a SOA architektúra kiépítéséhez szükséges egy olyan elem megléte, mely függetlenné teszi a szolgáltatás elérésének és nyújtásának módját attól, hogy mely rendszerkomponens szolgáltatását vesszük igénybe. Ezt a környezetet kívánja megteremteni az ESB, mint köztes réteg azáltal, hogy ún. mediációs folyamatokat hajt végre a szolgáltatások, illetve a back-end rendszerek interfészei között .
Vé gpontok
Kapcsoló felület (interface)
Mediáció – üzenet áramlások
Implementáció Rendszer komponensek
6. ábra: Szolgáltatások logikai és fizikai felépítése A fenti ábrán a végpontok a szolgáltatások igénybevevőit ábrázolják, akik az ESB által megvalósított, ún. logikai interfészen keresztül érik el a szükséges funkciókat. Azonban a logikai interfész megvalósulásához az ESB számos feladatot hajt végre, hogy elfedje a rendszerek - tényleges fizikai interfészek - közti különbségeket ezáltal lehetővé téve, hogy minden front-end alkalmazás azonos módón legyen képes meghívni a szolgáltatásokat. Az ábra jobb oldalán található „mediációs réteg” jelképezi ezen feladatok összességét. Ide tartoznak olyan folyamatok, mint pl. a protokollok közötti váltások, különböző üzenetek útvonalirányítása (rout), adatformátumok közötti transzformációk ([9]). A szolgáltatási sínnek az is a szerepe, hogy különböző biztonsági protokollok használatával képes
megvalósítani a biztonságos kommunikációt és ezeket a mechanizmusokat nem kell a sokféle szoftverben külön kialakítani, hanem az ESB vállalja a felelősséget az üzenetek továbbításának sikeréért. Tehát fizikai interfésznek hívjuk azokat az interfésztípusokat, amelyek konkrétan meghatározzák, hogy valamely rendszerkomponens milyen protokollon keresztül érhető el és definiálja az eléréshez szükséges végpontokat is. Az ESB fent említett mediációs tevékenységei azok, mellyel képes megvalósítani a - SzOA szabványnak megfelelően - a fizikai és logikai interfész elkülönítését és a különbözőségek elfedését. Ennek köszönhető, az ún. implementációs réteg létrejötte, mely egyrészt tartalmazza az egyes rendszerek meghívható elemeit, másrészt a szolgáltatás hívók számára lehetővé teszi ezeknek a komponensek elérését. Annak köszönhetően, hogy az ESB elfedi az alkalmazások közti különbségeket és biztosítja a különböző platformok számára ugyanazokat a szolgáltatásokat - vagy szolgáltatás komponenseket - teljes mértékben megvalósul a SzOA egyik alapelve, az újrafelhasználhatóság és platformfüggetlenség. Ugyanis ezeket a szolgáltatásokat tetszőlegesen hívhatják meg az egyes rendszerek, azzal összhangban, hogy az üzleti logika mit kíván ().
7. ábra: Rendszerek egymás közti kapcsolata ESB nélkül és ESB-vel 5.3. SzOA-t támogató szabványok 5.3.1. Szolgáltatás kapcsolófelületek( interfészek) szabványai Mileff szerint a két fő kritérium, amitől a SOA-ban szolgáltatásnak nevezhetünk valamit, az a meghatározott funkcionalitás, és a laza csatolás. Azonban a hálózati technológiák fejlődésével létrejöttek az ún. webszolgáltatások (webservice) is, melyek különböző szabványosított internetes és XML (Extensible Markup Language, Kiterjeszthető Leíró Nyelv) megoldásokkal válnak elérhetővé. A legelterjedtebb módja egy szolgáltatás leírásának az ún. WSDL (WebService Description Language, Webszolgáltatás leíró) segítségével történik. Ez egy XML-ből létrejött szabvány, mely tökéletes az adott szolgáltatás interfészének,
adattípusának, és a kapcsolódási pontjainak leírására. Ez a formátum teszi lehetővé a kommunikáció során, hogy a hívó fél tudja, hol és milyen címen kapcsolódjon a szolgáltatáshoz, valamint az milyen formában/formátumban fog válaszolni. Tehát a leíró nyelv által feltétlenül tartalmazandó információk a következők : •
A logikai interfész definiálása: a leírónak ez az a része, amely meghatározza, hogy mely műveletek hajthatók végre az egyes meghívható komponensek interfészein, továbbá megadja az üzenetek formátumát, melyekkel a hívási folyamat végbemegy.
•
Az üzenetek további tulajdonságainak leírása: Itt kerül definiálásra, milyen konkrét adattartalma lesz az üzeneteknek. Milyen adatelemek/változók szükségesek az igénylés és a válasz üzenetekben.
•
Az adattípusok további tulajdonságainak leírása: A korábban meghatározott adatelemek konkrét típusát és egyéb tulajdonságait (, mint pl. max. érték, min. érték, max. hossz, stb.) tartalmazza a leíró ide vonatkozó része.
Ahogy az alábbi ábrából is kiderül a WSDL alapvetően a szolgáltatás megismerését szolgálja, de ettől még az igénylő fél nem képes megtalálni a megfelelő komponenseket. Ezért szükséges volt egy publikációs szabvány kialakítása. A szolgáltatások tárolására létrejött registry, vagy repository feladata az egyes szolgáltatási elemek „kiajánlása”. Az erre létrejött szabvány az ún. UDDI (Universal Description, Discovery, and Integration, Univerzális leírás, felfedezés és integrálás) nyelve, mely szintén egy XML alapú komponensként jelenik meg és elsődleges célja, hogy a meghirdetett szolgáltatások metaadatainak (pl. elérési helyének) a tárolását biztosítsa. Az igénylő felek ebben a tárolóban képesek kereséseket végrehajtani az általuk legmegfelelőbbnek ítélt szolgáltatásokra.
8. ábra: SOA szolgáltatás működésének alapmodellje 5.3.2. Kommunikációs szabványok a kliensek és szolgáltatások nyújtói között Természetesen a szolgáltatások megtalálása után szükséges azok - illetve azok nyújtóinak elérése is, melyhez a rendszerek közti kommunikációra van szükség. A SzOA megközelítés terjedésével egyre több szabvány alakult ki, mely ezt a fajta „párbeszédet” támogatja igénylő és back-end között. A legelterjedtebb kommunikációs forma egy ún. SOAP (Simple Object Access Protocol, Egyszerű Objektum Elérési Protokoll) - szintén XML alapokon nyugvó protokoll - segítségével valósul meg. Ez biztosítja az alkalmazások számára a kölcsönös információcserét azáltal, hogy az üzeneteknek ad egy előre definiált platformtól független keretet. Ennek megfelelően ez a protokoll nincs átviteli réteghez kötve, de alapvetően Internetes és web szolgáltatásoknak a kommunikációjához hozták létre, ezért is alkalmas a hálózati megoldásokat használó SzOA igények kielégítésére. Azon túl, hogy biztosítja a kommunikációt, ez az állomány határozza meg az üzenetek (szükséges és nem szükséges) összetevőit. A SOAP-os üzenetek rendelkezhetnek egy fejléccel, amely szabadon definiálható és szinte minden információt tartalmaz, amivel egy üzenetet el kell látni, tehát egy autentikációs résszel - amely gyakorlatilag egy felhasználónevet jelent - egy azonosítóval mely a meghívandó rendszert jelöli ki. De ehhez még szükséges egy további azonosító is, mely a rendszer egy szolgáltatását jelöli meg. Ezek az információk még kiegészülnek egy dátumot és egy tranzakció azonosítót tartalmazó mezővel, melyek a későbbi nyomon követéshez elengedhetetlenek. Elmondható, hogy ez a fejléc a metaadatok helye, viszont a konkrét adattartalom az ún. body részben, az üzenet testében helyezkedik el. Ez jelenti az
üzletileg értelmezhető adatokat, míg a fejlécben az adatokat leíró metaadatok szerepelnek. Azonban meg kell jegyezni, hogy a SOAP leírása is WSDL segítségével valósul meg.
5.3.3. Üzenetek átviteli rétege általánosságban A fizikai sokféleség jellemzi a szolgáltatásokhoz tartozó interfészeket, protokollokat, és egyéb technológiákat, melyeket a SzOA-ban a logikai interfész fed el. Ennek megfelelően a szolgáltatások végpontjaihoz különböző átviteli eljárások tartozhatnak, melyek az üzenet átviteli módját határozzák meg. Ennek megfelelően alkalmazhatóak az alábbi átviteli rétegek. 5.3.3.1. HTTP A legegyszerűbb és legáltalánosabb átviteli csatorna (protokoll), melyen keresztül a SOAP üzenetek futhatnak, a HTTP (HyperText Transfer Protocol), mint információátviteli protokoll. Mivel ez a legelterjedtebb átviteli protokoll, így nyílván ennek a legnagyobb a támogatottsága az újrafelhasználhatóság szempontjából. Egyik részről, minden szerveren megtalálható, másrészt pedig sok féle rendszer képes használni - beleértve olyan eszközöket is, mint a PDA-k, okostelefonok, a különböző mobil eszközök. További előnyként jegyezhetjük meg, hogy tűzfalakon keresztül is használható, ezzel biztosítva az egyszerűbb kezelhetőséget. Azonban nem biztonságos, így nem alkalmazható banki környezetben éles rendszerek közötti kommunikáció biztosítására.
5.3.3.2. HTTPS Az előző pontban a HTTP hátrányaként említett biztonsági hiányosságok kezelésére jött létre a HTTPS. Ugyanazokat az előnyöket lehet megfogalmazni, mint a HTTP kapcsán, azaz a HTTPS-re is vonatkozik az elterjedtségen túl az egyszerű kezelhetőség és tűzfalakon, proxykon keresztüli kommunikáció lehetősége. A HTTPS esetében azonban a http-től eltérően, azonban itt létrejön SSL protokoll segítségével egy algoritmikus, kriptográfiai védelem, az üzenetek bizalmasságának, titkosságának megőrzése végett. Természetesen ez a folyamat további erőforrás felhasználást igényel.
5.3.3.3. SMTP Ez a kommunikációs protokoll (Simple Mail Transfer Protocol) alapvetően email üzenetek küldésénél vált szabvánnyá a világon, azonban ennek köszönhető, hogy nem, vagy nehezen alkalmazható olyan működési környezetben, ahol elsősorban XML - és információ - alapú
kommunikáció folyik. Bár ennek a protokollnak a használata is magában hordozza azokat az előnyöket, amelyeket a HTTP-vel biztosított átviteli csatorna megléte – tehát alkalmassá tehető SOAP üzenetek továbbítására is - azonban hasonlóan ahhoz, jellemző rá a biztonságosság hiánya. 5.3.3.4. JMS Ebben a témakörben mindenképpen meg kell említeni a JMS-t (Java Message Service), mint a kommunikáció biztosításának egy igen széles körben elterjedt módját. A SOA-ra alapvetően jellemző az üzenetsoros kommunikáció, melynek egyik és talán legelterjedtebb eszköze a JMS használata. Java-ban íródott alkalmazások képesek ezen keresztül elérni más implementációkat ezzel megvalósítva a platformfüggetlenséget. Sok esetben említik úgy ezt az interfészt, mint az ún. Message Oriented Middleware (azaz üzenetorientált köztes réteg) egyik legfontosabb elemét. Ezzel együtt a kommunikációnak két formáját is támogatja. Nem csak a két pont közti üzenetküldést teszi lehetővé, hanem ez az interfész illeszkedik a SOA elveknél már említett publish-subscribe (nyilvánosságra hoz- előfizet) kommunikációs elvbe is. Ezen felül a következő fejezetben ismertetett interakciós módok közül mind a szinkron, mind az aszinkron kommunikációt lehetővé teszi. Azonban hátrányként kell megemlíteni, hogy az elvi platformfüggetlenség valós környezetben nem mindig valósul meg, ugyanis általában szükséges ugyanannak a szoftvernek a megléte mindkét kommunikáló rendszer esetében, hogy a web-szolgáltatások képesek legyenek JMS-hez kapcsolódni ([9]).
5.3.3.5. Kommunikáció iránya szerint megkülönböztetett interakciós módok Az egyes rendszerek különféle módokon kommunikálhatnak egy-egy szolgáltatás meghívása és a kérés fogadásának esetében attól függően, hogy szükséges-e tudnia a kliensnek a szolgáltatás nyújtójának állapotáról, vagy nem. Ez természetesen fordítva is igaz. Az egyes üzenetküldési módszerek a már tárgyalt WSDL-ben, vagy éppen aktuális leíró fájlban kerül definiálásra. Ezek alapján a következő eljárásokat különböztetjük meg:
Szinkron komMunikáció
Ebben a kommunikációs formában a szolgáltatást igénybe vevő fél (folyamat) az üzenet elküldését követően nem lesz elérhető, azaz a válasz megérkezéséig - vagy beállított lejárati időig (timeout-ig) - blokkolja magát. Ez az eljárás alapvetően nem foglalkozik azzal, ha
esetleg a fogadó fél feldolgozási folyamataiban hiba következik be, elvben erről nem kap értesítést a szolgáltatás hívója. Ezeket a beállításokat a szolgáltatói oldalon kell megtenni, hogy
a
megfelelő
hibaüzenet/timeout
megérkezzen
a
kommunikációt
elindító
alkalmazáshoz. Ez magában foglalja azt is, hogy a nem megfelelő feldolgozás következtében létrejövő hibát a szolgáltató félnek kell kezelnie, akár a hiba felderítéséről, annak naplózásáról, vagy a hibaüzenet kliens felé történő visszaküldéséről van szó. Egyirányú kommunikáció
A legegyszerűbb interakciós mód a rendszerek között az egyirányú kommunikáció. Ebben az esetben az üzenet küldőjének, azaz a hívás elindítójának nem célja, hogy választ kapjon, sokkal inkább az információ átadása a fogadó alkalmazás felé. Ezt a fajta kommunikációt jól reprezentálja a naplózás megvalósítása egy rendszer esetében, amikor a naplózást végző fél az egyik rendszertől megkapja az eltárolásra szánt információkat. Konkrét példaként hozható erre az ún. SOAP-over-HTTP szinkron kommunikáció megvalósulása, melynek lényege, hogy egy SOAP üzenet indításával kezdődik meg az interakció. Mint már említésre került, ilyenkor nem szükséges a válasz üzenet visszaküldése, de ez a fajta kommunikáció lehetővé teszi, hogy egy HTTP üzenet formájában visszakapjon a kliens egy státuszkódot, mely megmutatja, hogy, sikeres volt-e a háttérrendszer üzenetfogadása, vagy akár azt is, hogy maga a feldolgozás megvalósult-e. A „párbeszéd” szinkronitása abban nyilvánul meg, hogy amíg ez a HTTP üzenet vissza nem érkezik, a kliens addig elérhetetlenné válik. Azonban meg kell említeni, hogy ez a szinkronitás többféleképpen megvalósulhat, mivel egyrészt a kliens sem feltétlenül kell, hogy egyáltalán választ kapjon az üzenet megérkezéséről, azonban amikor ez beállításra kerül, kétféle forgatókönyv valósulhat meg. A kliens mindössze addig válik elérhetetlenné, amíg a SOAP üzenet, a szolgáltatást megvalósító félhez megérkezik, és erről megkapja az értesítést a már említett HTTP üzenet formájában. Másik esetben addig blokkolja magát, amíg magáról a feldolgozás sikerességéről küldd visszajelzést. Azonban egy hibás fogadás/feldolgozás estén így a hibakód visszaküldése is megvalósulhat, ezzel lehetővé téve a hívó alkalmazás informálását az esetleges hiba okáról. Pszeudó szinkron kommunikáció
Ez a szinkron információcsere speciális válfaja, amikor is a hívó alkalmazás és a háttérrendszer közé beiktatjuk az ESB-t. A kliens és az ESB között a fent említett szinkron kommunikáció létesül, tehát a szolgáltatás hívója az üzenet kiküldését követően blokkolja
magát, amíg választ nem kap így már közvetetten a háttérrendszertől. Az ESB és a háttérrendszer között ezt követően egy szinkron, vagy más interakciós mód valósul meg, mely így függetlenné válik a kliens oldaltól. Ezzel együtt a szolgáltatás nyújtó értesítési feladata megszűnik a kliens felé, ezt a szerepet ezt követően az ESB tölti be. Szolgáltatás hívó (Service Consumer)
Szolgáltatás nyújtó (Service Producer)
ESB
Szolgáltatás hívás
Szolgáltatás hívás
Válasz
Válasz
9. ábra: Pszeudó szinkron hívás megvalósulása
Aszinkron kommunikáció
Ahogy a név is utal rá, az aszinkron viselkedés az eddigiekhez képes abban nyilvánul meg, hogy az üzenet/hívás kiküldését követően a szolgáltatást igénylő kliens nem blokkolódik, így működését függetlenné teszi a kapott eredménytől. Ennek köszönhetően amennyiben a háttérrendszer éppen nem elérhető, a hívó alkalmazás képes folytatni tevékenységét és nem függ a választól. A folyamat lényege az, hogy a kliens fél elküldi kérését az ESB felé, aki továbbítja azt a háttérrendszer irányába. Ezt követően az ESB folyamatosan lekérdezéseket hajt végre a szolgáltató felé, amíg a választ meg nem kapja. Ezt a lekérdező folyamatot hívjuk lekérdezési próbálkozásnak, (polling). Ezzel gyakorlatilag átveszi ezt a szerepet a kliens oldaltól. Nyilvánosságra hoz-Előfizet (Publish-Subscribe)
Amikor szolgáltatásorientált architektúráról beszélünk, sokszor ezt az interakciós eljárást azonosítják az architektúrával. Ez a felfogás azonban téves, ebben az esetben csupán a SzOA elemeinek egyfajta közvetett kommunikációja valósul meg, ami természetesen csak egy részét képezi az egész rendszerfelfogásnak. Bár tény az, hogy ennek a megvalósulásához gyakorlatilag minden elemre szükség van, ami a szolgáltatásorientáltság kialakításához kellhet.
10. ábra: SOA szolgáltatás működésének alapmodellje ([13].) Ezt a fajta kommunikációt is üzenetalapú, valós idejű interakció megvalósításához használják. Ahogy az alsó ábrán is látszik, ez a három elem a főszereplő a rendszer működésében. Az alap architektúra áll egy szolgáltatás igénylőből, aki képes elérni a szükséges szolgáltatást/szolgáltatásokat azáltal, hogy feliratkozik a szolgáltatástárba. Ez a subscribe, előfizetési folyamat, melyről természetesen visszaigazolást kap a tár felől. Ezt követően a kommunikációban részt vevő harmadik elem, maga a szolgáltató deríti fel, hogy melyek azok az alkalmazások, akik a szolgáltatás elérésének igényét jelezték, valamint közvetlenül el is éri azokat a szükséges folyamattal. A szolgáltatástárban találhatók a szolgáltatások leírói, mint már korábban említettük, főként WSDL állományok formájában, melyet a szolgáltatók helyeznek el itt, ezzel kihirdetve eszközkészletüket. Ez a folyamat a publishing, nyilvánosságra hozatal, publikáció. Ezek a leírók tartalmazzák, hogy az egyes szolgáltatásokat hogyan lehet használni (mind a szolgáltatáshoz való csatlakozást, mind az eléréshez szükséges üzenet és adatformátumokat definiálja a sikeres eléréshez). Tehát egy kommunikáció során a szolgáltatás nyújtója ezen a szintén XML alapú (UDDI) szolgáltatástáron keresztül hirdeti szolgáltatását. Az igények egymásra találása a brókeren keresztül történik. Az üzenetet elindító kliens egy ún. ügynök (ágens, agent) segítségével elküldi kérését a brókerhez, amely megvizsgálja, hogy az igényeihez melyik szolgáltatás illik és a tárolóban meghirdetett szolgáltatások közül kiválasztja a megfelelőt, melyhez így eljut a hívó fél kérése. Ez azt jelenti, hogy egy szolgáltatás megigénylése esetén a hívó alkalmazás egy, a szolgáltatást leíró WSDL állomány alapján létrejövő SOAP üzenetet hoz létre, hogy
képes legyen a szolgáltatás interfészein definiált metódusokat azzal közvetlenül meghívni. Az UDDI állományok pedig - melyek az egyes web szolgáltatásokat tárolják - tartalmazzák azok interfészeinek további specifikációját.
6.
IRODALOMJEGYZÉK 1.
Dirk Matthes, Enterprise Architecture Frameworks Kompendium, © Springer-Verlag Berlin Heidelberg 2011, e-ISBN 978-3-642-12955-1, ISSN 1439-5428 2. John A. Zachman (2009): The Zachman Framework: The Official Concise Definition http://test.zachmaninternational.com/index.php/the-zachman-framework , 2011-0818 3. Open Group, TOGAF: The Open Group Architecture Framework, TOGAF® Version 9, http://www.opengroup.org/togaf , 2010. 4. Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471-2000, The Architecture Working Group of the Software Engineering Committee, Standards Department, IEEE, Piscataway, New Jersey, USA (2000), ISBN-10:0738125180. http://www.ieee.org 5. Sowa, J., Zachman, J.: Extending and formalizing the framework for information systems architecture. IBM Syst. J. 31(3), 590–616 (1992) 6. TOGAF— TOGAF Version 9, The Open Group Architectural Framework, The Open Group, 2009, http://www.togaf.org 7. Zachman, J.: A framework for information systems architecture. IBM Syst. J. 26(3) (1987) 8. Barber, Graham (2007.): Service Components, Oasis Open CSA, http://www.osoa.org/display/Main/Service+Component+Architecture+Home , letöltve: 2012.01.19. 9. Endrei, M. - Ang, J. - Arsanjani, A. - Chua, S. - Comte, P. - Krogdahl, P. - Luo, M. Newling, T. (2004.): IBM Service Oriented Architecture and Webservices, IBM redbooks, 17-43., 107-157., http://www.redbooks.ibm.com/abstracts/sg246303.html, letöltve: 2012.02.08. 10. Erl, Thomas (2009.): Introduction to Service-Orientation, Szolgáltatások autonómiája, SOA Principles, http://www.soaprinciples.com/service_autonomy.php, letöltve: 2011.10.27. 11. Kovács András (2006.): SOA a jövő üzleti architekturális modellje, IQSYS, http://computerworld.hu/soa-jovo-uzleti-architekturalis-modellje.html, letöltve: 2011.11.25. 12. Sheldon, Thomas (2001.): Back-end systems, Big Sur Multimedia, http://www.linktionary.com/b/back_end.html, letöltve: 2011.12.19. 13. Telbisz Ferenc (2007.): Szolgáltatás Orientált Architektúra Koncepció és Alapelvek, KFKI, https://nws.niif.hu/ncd2007/docs/ehu/028.pdf, letöltve: 2011.10.27.
7. KÉPEK FORRÁSAI 1. ábra 14. Arsanjani, A. - Zhang, L.J. - Ellis, M. - Allam, A. - Channabasavaiah, K. (2007.): Design an SOA solution using a reference architecture kép, http://www.ibm.com/developerworks/library/ar-archtemp/, letöltve: 2011.10.27.
