SOA – Szolgáltatás orientáltság –

alapelvek – Chapter 8
 Mitől lesz egy szolgáltatás „megfelelő”? Hogyan lehet
tényleg „szolgáltatás orientált” Web szolgáltatásokat
definiálni?
 SOA megközelítés az tervezési módszertan is,
szolgáltatások, leírások, üzenetek, stb. mind
szolgáltatás-orientáltak kell, hogy legyenek
 Üzleti logika <-> Alkalmazás logika
 Előbbi a vállalat tevékenységéből ered, tipikusan
folyamat modellekkel lehet leírni
 Utóbbi az üzleti logika automatizálására
implementált technológiai megoldásokat tömöríti
magába – standard v. egyedi fejlesztésű
rendszerek formájában, melyek a vállalati IT
infrastruktúrán működnek
 Szolgáltatás orientáltság egységesen vállalati logikát
jelent.. ?? – lásd folytatás 

28
SOA – Szolgáltatás orientáltság –
alapelvek - szolgáltatások
 Névből adódóan a szolgáltatások központi szerepet
játszanak
 Szolgáltatások szintje – üzleti és alkalmazási
absztrakciós szintet is jelenthet – ÁBRA(282 – Fig. 8.2)
– alkalmazás réteg, szolgáltatás réteg, üzleti réteg.
 Szolgáltatások egymásba ágyazása (encapsulation) –
szülő, gyerek szolgáltatások
 Fizikai szinthez közel lévő szolgáltatások az alkalmazási
logika közvetítésére (encapsulation) valók. – ÁBRA(283
Fig. 8.3)

29
SOA – Szolgáltatási szintek &
szolgáltatás „becsomagolás”

30
SOA – Szolgáltatás orientáltság –
alapelvek – SOA építőelemek
 Web szolgáltatások- melyek műveleteket „tartalmaznak”
 Műveletek a szolgáltatás 1-1 funkciójának végrehajtására
képesek – végrehajtás üzenetfogadás-küldés során történik
 Szolgáltatás hívó és a hívott együtt megoldanak egy
automatizált üzleti feladatot az üzenetváltás során
 Logikai egységek ez alapján: SOAP üzenetek, Web
szolgáltatások, Web szolgáltatás műveletek, és maga a
megoldott feladat (activity) - > SOA terminológiában:
üzenet, művelet, szolgáltatás, folyamat
 Autómatizálási logika (automation logic) és építőelemek
kapcsolata:
 Üzenetek: elemi kommunikációs egységek
 Műveletek: elemi munkaegységek
 Szolgáltatások: feldolgozási logikai egységek
(műveletek gyűjteménye)
 Folyamatok: automatizálási logika egységek
(megfelelően összekötött – koordinált – műveletek
halmaza)
 ÁBRA 287 - Fig. 8.7-8.8 31
SOA – Szolgáltatás orientáltság –
alapelvek – SOA építőelemek
 Autómatizálási logika (automation logic) és építőelemek
kapcsolata:
 ÁBRA 287 - Fig. 8.7-8.8

32
SOA építőelemek funkciói,
kapcsolataik
 Üzenetek: tartalmazzák egy munkaegység
végrehajtásához szükséges adatokat
 Műveletek: adják a logikát mely az üzenetek
feldolgozásához szükséges egy munkaegység
végrehajtásánál
 Szolgáltatások: logikailag összetartozó műveletek
gyűjteménye, amik együtt egy nagyobb
feladategység végrehajtásához kapcsolódnak
 Folyamatok: tartalmazzák az üzleti szabályokat
melyek meghatározzák mely műveleteket, milyen
sorrendben kell végrehajtani egy nagyobb
munkaegység végrehajtása érdekében.
 FONTOS: Szolgáltatás != Műveletek(Műveletei) ill.
folyamat NEM szolgáltatásokból építkezik

33
 Web services & SOA:
SOA Alapelvek
 Általános IT megoldás tervezési gyakorlata a probléma ciklikus több részre
osztása (separation of concerns)
 SOA-nal is igaz, de mindezt az alapelvek megtartásával kell tenni
 SOA alapelvek= szolgáltatások tulajdonságai:
 Újrafelhasználhatóság (reuseable)
 Szolgáltatási szerződés megosztása (share service contracts)
 Laza csatolás (loose coupling)
 Működési logika elrejtése – absztrakt interfész szint képzése (abstract
underlying logic)
 Összekapcsolhatóak (composable) -> granularitás
 Autonómok (autonomous - jól meghatározott határokon belüli logikát fednek
le s egymástól függetlenek)
 Állapotmentesek (stateless) – ez biztosítja a laza csatolást. A szolgáltatások
állapotmentességét explicit biztosítani kell, akkor is, ha ezzel máshol kell az
állapotmenedzselést megvalósítani
 Megtalálhatóak (discoverable) – manuális és programozott kereséssel is meg
kell tudni találni őket ill. szolgáltatási szerződésüket
Alapvető szolgáltatásorientált elvek.
 Alapelvek cégenként és SOA keretrendszer fejlesztőknél is nagyban eltérnek
prioritásukban

34
SOA Alapelvek:
Szolgáltatások újrafelhasználhatóak
 Újrafelhasználhatóságra/újrafelhasználásra való tervezés
 A későbbi fejlesztések megelőzése, wrapper szolgáltatások
fejlesztésének megelőzése
 Szolgáltatás műveletek gyűjteménye ->újrafelhasználható
műveletek
 Messaging (SOAP headers) indirekt segítik elő az
újrafelhasználást
 Kevésbé munka specifikus ->generikus szolgáltatások
Példa: B2B számlabeküldő fél speciálisan a fő partnere – nagyvállalat
– fogadó szolgáltatására készítette el a saját számlaküldő
szolgáltatását és annak MetaData lekérő műveletét. Ezek más
partnernél nagy valószínűséggel nem lesznek
újrafelhasználhatóak.
Jól utalhat már az elnevezés is erre: GetNetriskMetadata
Netrisk oldalon jobb esetben generikusak a fogadó műveletek

35
SOA Alapelvek:
Formális szolgáltatási szerződés
 Szerződés részei:
 Szolgáltatás végpont (endpoint)
 Műveletek
 Műveletek által támogatott input/output üzenetek
 Szabályok és protokollok a szolgáltatás és műveletei
működésére vonatkozóan
 Szolgáltatást leíró szemantikus információk – legutóbbi
elem.
 Szolgáltatást igénybe vevők szorosan, csak erre
támaszkodnak: verziózás, karbantartás fontossága…
PÉLDA: tipikusan nagyvállalatok (vagy törvényi előírások,
kormányrendeletek) megadják a feltételeket – service
contracts – és ehhez igazodnak a partnercégek már a
fejlesztés során.

36
SOA Alapelvek:
Szolgáltatások lazán csatoltak
 IT környezet változása/fejlődése külső, előre nem látható
tényezőktől befolyásolt -> fel kell készülni a változásokra, ezt
a rugalmasságot a laza csatolás elve közvetlen támogatja
 Szolgáltatások ismerik egymást, kommunikálnak, használják
egymás műveleteit, de nincsenek összekötve, nem függenek
egymástól (ÁBRA 297 - Fig. 8.16)
 (állapotmentes) Web szolgáltatások megvalósításuknál fogva
eleve lazán csatoltak

37
SOA Alapelvek:
Működési logika elrejtése
 „Service interface level abstraction”
 Üzleti logika elrejtése (fekete dobozok)
 Lefedett logika terjedelme nagyon változó lehet
(granularítás) – (pl. egy szolgáltatás több vállalati
alkalmazásból is „foghat össze” működési logikát
 A mögöttes logikát a művelet „valósítja” meg (nem a
szolgáltatás)
 Web szolgáltatás technológia implicit biztosítja

38
SOA Alapelvek:
Szolgáltatások összekapcsolhatóak
 „Services are composable”
 Szolgáltatások más szolgáltatásokat is magukba rejthetnek
(pl. orchestration)
 Nem lényeges (és nem is ismert), hogy a szolgáltatás
„maga”, vagy más szolgáltatások bevonásával old meg egy
feladatot
 Composability az újrafelhasználás egy kézenfekvő formája
 Szolgáltatás összekapcsolhatóság alapvetően függ a
definiált műveletektől (operation composability)
Példa: Korábbi számlafeldolgozó szolgáltatása és kapcsolódó
beszállító profil/egyenleg ellenőrző ill. kifizetést
ütemező/könyvelő szolgáltatás

39
SOA Alapelvek:
Szolgáltatások autonómok
 „Services are autonomous”
 Szolgáltatás határai (lefedett üzleti logika) jól meghatározott
 Ez biztosítja az „önfenntarthatóságot” (self-governance)
 Nem függenek más szolgáltatásoktól, így önállóan fejleszthetőek,
deployolhatóak, stb.
 Autonómia fenntartása a fő vezérelv az alkalmazási és üzleti
logika „szolgáltatásokba osztásánál” – átfedések elkerülése
 Service level autonomy (pl. wrapper szolgáltatás) és pure
autonomy (control and ownership of underlying logic)
Példa: számlaküldő szolgáltatás, mely a pénzügyi vállalati rendszerre
épít (szolgáltatás szintű autonómia)

40
SOA Alapelvek:
Szolgáltatások autonómok – B2B példa

41
SOA Alapelvek:
Szolgáltatások állapotmentesek
 „Services are stateless”
 Állapotinformációk mennyiségének és azok birtoklási
időtartamának minimalizálása
 Szolgáltatás üzenetfeldolgozáskor nem állapotmentes ->
hosszú futásidejű szolgáltatások(műveleteknél)nál van
gond.
 Állapotmentesség az újrafelhasználhatóság előfeltétele
 Minél inkább állapot teli az üzenet (SOAP headers, WS*
szabványok) annál inkább állapotmentes a szolgáltatás
 Állapotmentesség foka mérhető – ld. művelet átfutási ideje
Példa: Wrapper szolgáltatás a megrendelés feldolgozásra ami
ERP rendszerre épül. Feldolgozási idő hosszú lehet,
állapotmentesség emiatt alacsony.

42
SOA Alapelvek:
Szolgáltatások kereshetőek
 „Services are discoverable”
 Discovery segít megelőzni ugyanannak többszöri
leprogramozását, elősegíti az újrafelhasználhatóságot
 Szolgáltatás szintű kereshetőség != SOA szintű
kereshetőség
Példa: a nagyvállalatok (tipikusan több partnerrel
rendelkeznek) biztosítják a discovery lehetőségét, s így
tervezik a szolgáltatásokat is, míg partnercégeik, akik
tőlük függenek, egyedileg „rájuk” tervezik szolgáltatásaikat
ezt nem teszik meg.
Ennél sokkal fontosabb a szervezeten belüli szolgáltatás
kereshetőség biztosítása. Fontos, ha lehet, a
szolgáltatások szemantikáját is bevonni a discovery
folyamatba (nem csak egyszerű WSDL alapon).

43
SOA Alapelvek összefüggései –
Chapter 8.4-Újrafelhasználhatóság
 Autonómia biztosítja hozzá a futtatási környezetek elválasztását
 Állapotmentesség közvetlenül meghatározza a mértékét
(maximalizálja)
 Kereshetőség közvetítő médiumot nyújt az elősegítéséhez
 Szolgáltatás absztrakció az újrafelhasználható csomagokba
tömöríti a szolgáltatásokat
 Összekapcsolhatóságot (composability) az újrafelhasználhatóság
teszi lehetővé (annak egy fajtája)
 Laza csatolás biztosítja a szolgáltatások függetlenségét, ami
támogatja az újrafelhasználhatóságot.
OO analógia: újrafelhasználható osztályok az OO-ban. Absztrakció,
egymásba ágyazás az újrafelhasználhatóság elősegítéséért
hasonló céllal létezett már OO-ban is.
WS támogatás: WS-ek NEM automatikusan újrafelhasználhatóak, ez
a szolgáltatás által lefedett logika természetétől függ ->
tervezésnél erre figyelni kell.

44
SOA Alapelvek összefüggései
Szolgáltatás szerződés
 ~ szükséges az összekapcsolhatósághoz
 ~ képezi a szolgáltatás kereshetőség alapját (tárgyát?)
 ~ szükséges a működési logika elrejtéséhez
 ~ lehetővé teszi szolgáltatások laza csatolását

OO analógia: objektum orientált alkalmazások interfészeihez

hasonlítható. „WSDL first” megközelítés a tervezésnél
SOA-nál ua. mint „Interface first” az OO-ban.
WS támogatás: WSDL kell hogy létezzen a WS-ekhez, így a
szolgáltatás szerződés megléte biztosított

45
SOA Alapelvek összefüggései
Szolgáltatások laza csatolása
 ~ támogatja az összekapcsolhatóságot (composability)
 ~ lehetővé teszi a szolgáltatások autonomiáját
 ~ olyan környezetet biztosít mely elősegíti a szolgáltatások
állapotmentességét
 ~ minimalizálja a szolgáltatások egymástól való függését
támogatva ezzel az újrafelhasználhatóságot
 ~ szolgáltatási szerződések használata által
megvalósítható

OO analógia: ugyan az interfész némileg elválasztja az

osztályt annak „hívójától”, az öröklés és egyéb eljárások
mégiscsak elősegítik az osztályok szoros összekötését.
WS támogatás: Ws-ek természetüknél fogva lazán csatoltak a
WSDL-el használatán keresztül.
46
SOA Alapelvek összefüggései
Szolgáltatás absztraktció
 ~ csomagokba fogja össze a logikát, elősegítve ezzel az
újrafelhasználhatóságot
 Szolgáltatási szerződések használata által támogatott

OO analógia: osztályok is interfészeken keresztül érhetőek el,

ezek szintén egy absztrakciós szintet alkotnak.
Encapsulation és information hiding a szolgáltatás
absztrakcióhoz hasonlóan rejtik el a működési logikát a
külső világtól.
WS támogatás: WS-ek természetszerűleg elrejtik a mögöttes
üzleti logikát, fekete dobozként viselkednek.

47
SOA Alapelvek összefüggései
Összekapcsolhatóság (composability)
 Szolgáltatás autonómia mértéke növeli
 Szolgáltatás állapotmentesség mértéke is növeli
 Szolgáltatás szerződés alkalmazása szükséges hozzá
 Újrafelhasználhatóság közvetlen elősegíti (annak a composability
egy fajtája)
 Szolgáltatások laza csatolása is támogatja

OO analógia: fogalmak összerendelését mint aggregáció és

kompozició támogatja – ahogy a SOA is az
összekapcsolhatóságot. Ahogy az objektumokat építjük
elemekből, úgy építjük a szolgáltatásokat is
szolgáltatásokból/műveletekből.
WS támogatás: Technikai nézőpontból természetszerűleg biztosított,
azonban valódi mértéke a tervezés során ill. az lefedett üzleti
logika újrafelhasználhatóságától függően alakul.

48
SOA Alapelvek összefüggései
Szolgáltatás autonómia
 ~ növeli az összekapcsolhatóság mértékét
 ~ futtatási környezet elhatárolásával hozzájárul az
újrafelhasználhatósághoz
 ~ növeli az állapotmentesség mértékét
 Szolgáltatások laza csatolása teszi lehetővé

OO analógia: autonómia jobban támogatott SOA-ban mint

OO-ban: SOA-ban a laza csatolás preferált és szolgáltatás
függetlenség egyértelmű cél. Ugyanakkor az objektum
közötti referenciák – pl. öröklés – csökkentik az objektum
szintű autonómiát az OO-ban.
WS támogatás: Ezt tervezésnél kell biztosítani, egyáltalán
nem jön automatikusan 

49
SOA Alapelvek összefüggései
Szolgáltatás állapotmentesség
 ~ növeli az összekapcsolhatóság mértékét
 ~ maximalizálja az újrafelhasználhatóság lehetőségét
 Szolgáltatások laza csatolása biztosítja hozzá a megfelelő
környezetet
 Szolgáltatás autonómia növeli mértékét

OO analógia: objektumok az OO-ban természetüknél fogva

állapottal rendelkeznek. A SOA állapotmentes tervezési
megközelítése így teljesen eltér az OO-tól. (Persze lehet
SOA-ban is ilyen állapotteli szolgáltatásokat tervezni, de ez
leginkább kerülendő…)
WS támogatás: erősen preferált, WS-* szabványokkal
támogatott (SOAP headers & document-style SOAP), de
nem automatikus. (WS-* szabványok ritka használata )
50
SOA Alapelvek összefüggései
Szolgáltatás kereshetőség(discoverability)
 ~ környezetet/megoldást biztosít az újrafelhasználhatóság
elősegítésére
 Szolgáltatás szerződés adja az alapját- keretet –a
kereshetőségre.

OO analógia: az osztályok újrafelhasználhatóságának

elősegítése miatt az OO-ban is cél konzisztens, önleíró
interfészek definiálása. Ugyanakkor a discovery elősegítése
erősebben jellemző a SOA-ra, discovery-t mind tervezési,
mind futásidőben támogatja.
WS támogatás: Külön architektúrával, IT infrastruktúrával kell
támogatni, így természetszerűleg nem támogatja a WS
technológia.

51