Vállala alkalmazások integrációja

Szóbeli vizsga tételek kidolgozása

Józsa Ernő,
Kis Vencel,
Rácz Tamás,
Takács Noémi.

1
Információ

A “jegyzet” a 2017/2018/1 félévben készíte ük a tárgy kiado diáiból.

Hibák lehetnek benne, gyorsan készült! :)

2
Tartalomjegyzék
Tartalomjegyzék 3

1. [Tomi] Adatintegráció 7
Közvetlen hozzáférés / oszto adatbázis: 8
Adatbázis replikáció 9
ETL (extract, transform, load) 10
„Interfész táblák” 11
MDM (Master Data Management) 12

2. [Tomi] ETL + Adattisztitás 13

ETL 13
Extract 14
Transform 14
Load 14
Ada sz tás 15
Ada sz tás szükségessége 15
Inves ga on 15
Standardizáció 16
Matching 17
Survivorship 17
3. [Ernő] Alkalmazásintegráció 18
Fájl-csere alapú kommunikáció 19
Szinkron kommunikáció 20
Remote Procedure Call (RPC) 21
Object Oriented Middleware 21
Szinkron - RPC, RMI 22
Aszinkron - Messaging 23
Web services 25

3
 Vizsgakérdések 28
4. [Noémi] SOA Alapelvek 29
SOA alapelvek 29
SOA szükségessége 34
SOA vezérelvek és előnye 35
A SOA négy fő jellemzője: 36
vizsgakérdések 36
5. [Noémi] SOA alap topológia, SOA bevezetési módszertanok 37
SOA alap topológia 37
SOA bevezetési módszertanok 38
Projekt (SOA bevezetés életciklusa) 38
Stratégiák: 39
Top-down 39
Bo om-up 40
Agilis 41
vizsgakérdések: 43

6. [Vencel] Szolgáltatási szintek, szolgáltatási szint konfigurációk 44

Szolgáltatási szintek 44
Alkalmazási szint (applica on service layer): 44
Üzle szint (business service layer) 45
Folyamat szint (komponált szolgáltatások szintje, orchestra on service layer) 46
Szolgáltatási szint konfigurációk 46
vizsgakérdések: 47
7. [Vencel] Folyamat szolgáltatások tervezése BPEL-ben 47
Alapok 47
Lépések 49
Interakciók modellezése 49

4
 Folyamat interfész megtervezése 49
Partner szolgáltatásokkal folytato kommunikáció definiálása 52
Workflow logika megadása 54
Együ működési szkenáriók igazítása, folyamat finomítása (opcionális) 59
vizsgakérdések 60

8. [Ernő] Séma illesztés 61

Főbb feladatok - kihívások 61
Összete pusok relációja 61
Megközelítések 62
NTA algoritmus 63
Küszöbérték probléma 65
Jósági mutatók 66
Vizsgakérdések 66

9. [Vencel] Entitás centrikus szolgáltatások analízise és tervezése (top down

módszertanban) 67
Szolgáltatás tervezés alapok 67
En tás centrikus szolgáltatás tervezése 67
Szolgáltatás orientált analízis 70
Célja: 70
Folyamata 70
Üzle szolgáltatások és difiniálásuk 71
Módszertanok: BPM és En tás modellek 72
Task-centrikus és en tás-centrikus szolgáltatások, folyamat (szolgáltatások) 72
vizsgakérdések (Szolgáltatás tervezés alapok+En táscentrikus szolgáltatások
tervezése) 74

10. [Noémi] Szabványosító testületek + Tanult SOA bevezetés szolgáltatás analízis,

tervezés lépései 75
Szabványosító testületek 75

5
 Tanult SOA bevezetés szolgáltatás analízis, tervezés lépései 76
11. [Noémi] WS* szabványok 77

12. [Tomi] Vállalati tartalmak - tartalom integráció 86

Vállala tartalmak 86
Tartalomkezelési szolgáltatások: 86
Tartalom integráció 87
Vállala tartalom integráció 87
Enterprise Content Management - Tartalom menedzsment 87
13. [Ernő] ESB 90
ESB képességek 91
Bus részei 92
Basic ESB Pa ern 93
Egyéb vizsgakérdések, amelyek nem tartoznak sehová 95

EAI def, célok, alapfogalmak 96

EAI definíció: 97

6
1. [Tomi] Ada ntegráció
Alkalmazásintegráció nem minden esetben lehetséges:

● Dokumentálatlan, nem létező, nem szabványos interfészek

● Nem azonos formátumú redundáns adatok
○ ekkor-> bonyolult transzformáció szükséges
● Eltérő szintaxisú, nem konzisztens adatok: ada sz tás, párosítás szükséges
● Nagy teljesítményű batch tranzakciók lehetségesek: alkalmazás integráció sok
overhead-et tartalmazhat

Megoldás: ada ntegráció:

● Közvetlen hozzáférés
● ETL, ada sz tás
● Batch és valós idejű működés

Kri kus problémák:

● A vállalat értékek adatai, információi elkülönült alkalmazások adatbázisaiban

hevernek
● Az alkalmazások csak saját feldolgozási és anali kus területükre fókuszálnak,
nehézkes az átjárhatóság (más forrás megszólítása, külső kérés kiszolgálása)
● A heterogén (technológia, protokollok, adatreprezentáció, adatminőség)
ada orrásokkal nehézkes az alkalmazások közö integráció, vagy egységes
ada árház kialakítása
● Redundancia – önmagában veszélyes!
○ Inkonzisztencia
○ Eltérő struktúra (granularitás), eltérő adatminőség

Megoldások:

7
Közvetlen hozzáférés / oszto adatbázis:

● Közös adatbázis
● Az alkalmazások azonos sémába (-ból) dolgoznak
● Az alkalmazások egymástól függetlenek

Előnye:

● Egyszerű, költséghatékony:
○ 1 DB könnyen karbantartható
○ Nincsenek DB szinkronizálási feladatok
○ DB szintű konzisztencia biztosíto
● Nincs hard-coded függőség az alkalmazások közö
● Olyan esetben is alkalmazható, ahol az alkalmazás nincs felkészítve az
integrációra (semmi plusz alkalmazásintegrációs interfész vagy adapter nem
szükséges)

Hátránya:

● Single point of failure

● Körültekintő tervezést igényel:
○ Méretezési problémák, skálázhatóság
○ Deadlock-ok

8
 ○ Eltérő / ellentmondásos üzle logika és ellenőrzések lehetnek az
alkalmazásokban
● Alkalmazások adatstruktúra-függősége
○ Adatstruktúra módosítás: minden alkalmazást egyszerre érint

Adatbázis replikáció

● Adatbázis másolatok gyártása, hogy több alkalmazás is ugyanazon adatokhoz

férjen hozzá.
● Saját adatbázisok, de azonos adatstruktúrák
● Az alkalmazások (részben) azonos adatstruktúrát használnak
● Az alkalmazások egymástól függetlenek
● Adatbázisok szinkronizációja / replikációja szükséges:
○ Időzítés ↔ Konzisztencia
○ Időzítés ↔ Teljesítmény / rendelkezésre állás Online / offline replikáció?
○ Egyirányú / ké rányú?

Előnye:

● Nincs hard-coded függőség az alkalmazások közö

● Olyan esetben is alkalmazható, ahol az alkalmazás nincs felkészítve az
integrációra
● Könnyebben méretezhető
● Dead-lock szituációk könnyebben elkerülhetők, lokalizálhatók

9
Hátránya:

● Szinkronizáció / replikáció körültekintő tervezést igényel

● Eltérő / ellentmondásos üzle logika és ellenőrzések lehetnek az
alkalmazásokban
● Alkalmazások adatstruktúrafüggősége
○ Adatstruktúra módosítás: minden alkalmazást egyszerre érint (az
adatbázisok egyformák)

ETL (extract, transform, load)

● Külön adatbázisok, eltérő adatstruktúrák

● Az alkalmazások saját adatstruktúrájukat használják, a transzformációt az ETL
modulok végzik
● Az alkalmazások egymástól függetlenek
○ ETL - pikusan egyirányú
○ Időzítés ↔ Konzisztencia
○ Időzítés ↔ Teljesítmény / rendelkezésre állás
○ Online / offline betöltés?
● ETL modul megvalósítható
○ Egyéni fejlesztés

10
 ○ ETL tool-ok segítségével (hatékonysági növekedés 3-5X ☺ @ETL tool
vendors) pl. Oracle Warehouse Builder -OWB, Microso Integra on
Services - SSIS, IBM Cognos Data Manager, SAS Data Integra on Studio))

Előnyök:

● Nincs függőség az alkalmazások közö

● Adatstruktúra függőség sincs
● Olyan esetben is alkalmazható, ahol az alkalmazás nincs felkészítve az
integrációra
● Könnyebben méretezhető
● Dead-lock szituációk könnyebben elkerülhetők, lokalizálhatók

Hátrányok:

● ETL modulok implementációja

● Eltérő / ellentmondásos üzle logika, szeman ka jelenhet meg az
alkalmazásokban
● Bármely oldal adatstruktúra változása az ETL modulok módosítását igényli

„Interfész táblák”

● Alkalmazások közö adatcsere ún. „interfész-táblákon” keresztül

11
 ● Az interfész táblák kerülhetnek külön adatbázisba, de közvetlenül valamely
alkalmazás adatbázisába is
● Az adatcsere lehet egy- és ké rányú, pl.:
○ A: beír – B: kiolvas, töröl
○ A: beír –B: kiolvas, feldolgoz, update-el – A: feldolgozás eredményét
kiolvassa

MDM (Master Data Management)

● Master adatokat függetlení az azt nyilvántartó alkalmazásoktól
● Közpon , alkalmazás-független információ-forrás
● Egyszerűsí az integrációt és új alkalmazások fejlesztését
● Konzisztens Master adatok a tranzakcionális és anali kus rendszerek számára
● Adatminőség és konzisztencia biztosítása már az ada orrásoknál, nem az
ada árházba töltéskor kell sz tani

● Minden rendszer felé aktuális és pontos információkat nyújt

● Az ügyfélről teljes nézetet ad

12
 ● Új ügyfél-stratégiák megvalósítását teszik lehetővé
● Esemény-orientált akciók

2. [Tomi] ETL + Ada sz tás

ETL

● Külön adatbázisok, eltérő adatstruktúrák

● Az alkalmazások saját adatstruktúrájukat használják, a transzformációt az ETL
modulok végzik
● Az alkalmazások egymástól függetlenek
○ ETL - pikusan egyirányú
○ Időzítés ↔ Konzisztencia
○ Időzítés ↔ Teljesítmény / rendelkezésre állás
○ Online / offline betöltés?
● ETL modul megvalósítható
○ Egyéni fejlesztés
○ ETL tool-ok segítségével (hatékonysági növekedés 3-5X ☺ @ETL tool
vendors) pl. Oracle Warehouse Builder -OWB, Microso Integra on
Services - SSIS, IBM Cognos Data Manager, SAS Data Integra on Studio))

Előnyök:

● Nincs függőség az alkalmazások közö

13
 ● Adatstruktúra függőség sincs
● Olyan esetben is alkalmazható, ahol az alkalmazás nincs felkészítve az
integrációra
● Könnyebben méretezhető
● Dead-lock szituációk könnyebben elkerülhetők, lokalizálhatók

Hátrányok:

● ETL modulok implementációja

● Eltérő / ellentmondásos üzle logika, szeman ka jelenhet meg az
alkalmazásokban
● Bármely oldal adatstruktúra változása az ETL modulok módosítását igényli

Extract

● Közvetlen adathozzáférés
● Adatbázisok
● Fájlok
● Szabványos források (JDBC, ODBC, WebServices, ...)

Transform

● Transzformációs job-ok
● Hozzáférés, transzformációk és betöltés szekvenciális sorozata
● Pipeline-olható
● Párhuzamosítható:
○ Par cionálással
○ Nem függő job-ok párhuzamos fu atásával
● Újrahasznosíthatóság

Load

● Betöltés

14
 ● Batch alapú, sta kus célba
● Real- me, web services válaszként

Ada sz tás

Adattisztítás szükségessége

● Tárolási / rögzítési szabványok hiánya:A rendszerekben eltér ő formátumok,

struktúrák
● „Data surprises”: Hibásan rögzíte adatok, mez ő-keveredés
● Szabad-szöveges mezőkben eláso információk
● Data myopia („rövidlátás”):Konzisztens azonosítók hiánya nehezí az egységes
nézet létrehozását
● Redundancia: Duplikált bejegyzések

Investigation

● Teljes állományok / adatbázisok vizsgálata

● Szabadszöveges mezők értelmezése
● Szabályszerűségek keresése és ellenőrzése
● Trendek, anomáliák detektálása
● Valótlan, vagy default értékek detektálása
● Megérteni a kontextusba helyeze adatokat

15
 ● Lexical analysis (Lexikai elemzés)
○ Determining business significance of individual pieces
(Az egyes darabok üzle jelentőségének meghatározása)
● Context Sensi ve (Tartalom érzékenység):
○ Iden fying various data structures and content
(Különböző adatszerkezetek és tartalom azonosítása)
○ “The instruc ons for handling the data are inherent within the data
itself.”
"Az adatok kezelésére vonatkozó utasítások magában az adatokban
vannak.”

Standardizáció

● Normalizáció a standardoknak megfelelően

○ Suffix, Prefix, Gender, Nickname, Title... Mezők formalizálása,
egységesítése
○ Ke ős nevek és egyéb különleges struktúrák kezelése
○ Földrajzi adatbázisok és ellenőrző rendszerek használata

16
Matching

Survivorship

17
3. [Ernő] Alkalmazásintegráció

● Adat/tartalom integráció nem minden esetben lehetséges/célravezető

○ Ha az alkalmazás adatbázisa „zárt”, dokumentálatlan
○ Az alkalmazások az DB fölö szinten „üzle ” logikát tartalmaznak
■ Verifikáció (constraint-ek)
■ Addícionális feldolgozási logika
■ Jogosultságkezelés
■ Eseménykezelés
■ ...
■ (Ha ezeket figyelmen kívül hagynánk: INKONZISZTENCIÁT
okoznánk)
● Megoldás: alkalmazás integráció
○ Kiajánlo metódusok / objektumok
○ Komple API (Applica on Programming Interface)

18
Fájl-csere alapú kommunikáció

19
Szinkron kommunikáció

20
Remote Procedure Call (RPC)

Object Oriented Middleware

● RPC-hez hasonló, ám objektum-orientált szemlélet:
● IDL bővülése
○ A paraméterek / visszatérési értékek objektum pusúak is lehetnek
○ Interface öröklés
○ Fejle ebb hibakezelő mechanizmusok
● Eloszto működés
● Objektum referenciák hosthoz kötése
● Objektum adapterek
● Bizonyos implementációkban: Asynchronous Method Invoca on
● Pl.: Java RMI, CORBA

21
Szinkron - RPC, RMI
RMI = RPC + Object-orienta on

22
Aszinkron - Messaging

Messaging

● Üzenet-orientált köztes rendszer (MOM – Message Oriented Middleware)

○ aszinkron, lazán csatolt, rendelkezésre-állástól független, de
tranzakció-biztos feldolgozás
○ közve te üzenetek biztos, egyszeri de csakis egyszeri továbbítása
○ egyes alkalmazások eseményvezérelt üzemeltetése
○ pla orm független, egyszerű programozási API felületet
● Pl:
○ IBM WebSphere MQ (korábban MQSeries)
○ Sun Java System Message Queue PE / EE
○ BEA MessageQ
○ JBossMQ
○ MS MQ

23
Messaging – rendelkezésre állástól független

● Minden folytonosan elérhető

● Minden feltételesen elérhető

Messaging – interakciós modellek

● Fire & forget (datagram)

○ Nem várunk választ
● Request – response (reply)
○ Választ várunk ado üzenetsorba

Message = Header + User Data

● Tipikus fejléc mezők

○ Des na on - célobjektum (ahová az üzenetet küldjük)
○ DeliveryMode- perzisztens / nem perzisztens
○ Expira on - lejára idő
○ Priority - prioritás
○ MessageID - üzenet azonosító
○ Timestamp - küldési idő
○ Correla onID - hivatkozo üzenet azonosítója
○ ReplyTo - a válasz célobjektuma
○ Type - üzenet „ pusa”
○ Redelivered - újraküldö jelző flag

Üzenet tartalma a konkrét alkalmazástól függ.

● Byte-tömb
● Szöveges üzenet (XML, Egyszerű XML, SOAP (pl.: SOAP-over-JMS), CWF (Custom
Wired Format), TDL (Tagged/Delimited)
● Serializált objektum (Pl.: Java – Java kommunikáció esetén)

24
Web services
Olyan hálóza alkalmazás vagy komponens, amely a SOAP protokoll és a WSDL
technológia felhasználásával, XML dokumentumok formájában kommunikál a külvilággal

● XML mint adatreprezentációs réteg pla ormfüggetlen

● SOAP (HTTP fölö ) mint szállítási réteg pla ormfüggetlen
● laza csatolás: a kliensek el tudják érni a szolgáltatást akkor is, ha annak
megváltozo az interfésze önleíró
● lehet szinkron és aszinkron is
● az XML-lel nemcsak egyszerű adatokat, hanem komplex dokumentumokat is
leírhatunk
● pla ormfüggetlensége mia kiváló integrációs eszköz

25
26
27
Vizsgakérdések
Integrációs minták, technológiák

1. Szinkron - RPC, RMI

2. Aszinkron - Messaging
3. Web services

28
4. [Noémi] SOA Alapelvek

SOA alapelvek
= szolgáltatások tulajdonságai:
(PINK: OO analógiát írtam oda, ha segít valakinek)
● Újrafelhasználhatóság
(reuseable)
ú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éteze már OO-ban is.

29
● Szolgáltatási szerződés megosztása
(share service contracts)
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.

● Lazacsatolás
(loosecoupling)

30
 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í k az osztályok szoros összekötését.

● Működési logika elrejtése – absztrakt interfész szint képzése

(abstract underlying logic)
osztályok is interfészeken keresztül érhetőek el, ezek egy szintén egy absztrakciós
szintet alkotnak. Encapsula on és informa on hiding a szolgáltatás
absztrakcióhoz hasonlóan rej k el a működési logikát a külső világtól.

● Összekapcsolhatóak
(composable)->granularitás
fogalmak összerendelését mint aggregáció és kompozició támogatja – ahogy a

31
 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.

● Autonómok
(autonomous-jól meghatározo határokon belüli logikát fednek le és egymástól
függetlenek)
autonómia jobban támogato 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ö referenciák – pl. öröklés – csökken k az objektum szintű autonómiát az
OO-ban.

32
● Állapotmentesek
(stateless) – ez biztosítja a laza csatolást. A szolgáltatások állapot mentességet
explicit biztosítani kell, akkor is, ha ezzel máshol kell az állapotmenedzselést
megvalósítani
objektumok az OO-ban természetüknél fogva állapo al rendelkeznek. A SOA
állapotmentes tervezési megközelítése így teljesen eltér az OO-tól. (Persze lehet
SOA-ban is ilyen állapo eli szolgáltatásokat tervezni, de ez inkább kerülendő...
lásd. korábban)

● Megtalálhatóak
(discoverable)–manuális és programozo kereséssel is meg kell tudni találni őket
ill. szolgáltatási szerződésüket
az osztályok újrafelhasználhatóságának elősegítése mia 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.

33
 ● Alapvető szolgáltatásorientált elvek.

SOA szükségessége
● Az információs rendszernek az üzle változásokat gyorsan és hatékonyan kell
támogatnia, miközben követnie kell az újabbnál újabb technológiák gyors
fejlődését is. A legtöbb vállala információs rendszer felépítése heterogén,
különféle alrendszereket, alkalmazásokat, technológiákat és architektúrákat fog
össze. Ezen technológiák minél hatékonyabb integrálása elengedhetetlen
fontosságú, mivel csak az integrált információs rendszerek tudják hatékonyan
támogatni az üzletmenetet, például döntéstámogatással, azonnali információ
hozzáféréssel, értéknövelő szolgáltatásokkal.

● Az elmúlt év zedben számos módszer jelent meg a változó követelmények, a

technológiai fejlődés és integráció problémájának megoldására. Ezek közül ma a
legkorszerűbbnek a szolgáltatás orientált architektúra (SOA) néven ismer é vált
megközelítést tartják.

34
SOA vezérelvek és előnye
● A szolgáltatásorientált architektúrák egy igen egyszerű vezérelve, hogy a
szo verfejlesztés folyamata során a funkciókat könnyen együ működö
szolgáltatásokként implementáljuk. Ezek a szolgáltatások lazán csatoltak lesznek,
egy jól definiált feladatot látnak el, ezáltal könnyedén újrafelhasználható
építőkövekként funkcionálnak. A szolgáltatásokat felhasználva pedig újabb,
immár bonyolultabb funkciókat építhetünk fel.
● Azt a folyamatot, melynek során a már meglévő szolgáltatásokat újabb
funkciókba rendezzük orkesztrációnak nevezzük. Az orkesztráció velejárója a SOA
szemléletnek, mivel az egyes funkciók az építőkövekként szolgáló
szolgáltatásokban implementáltuk, az orkesztráció során ezeket tetszőleges
módon szervezzük újabb és újabb csoportokba, így kapunk egy az üzle
követelmények változását könnyen követni tudó, rugalmas réteget a
szolgáltatásaink fele .

● Mint látha uk a szolgáltatásorientáltság legfőbb előnye a lazán csatolt, könnyen

újrafelhasználható szolgáltatásokban rejlik, melyek igen rugalmas, a változásokra
könyen reagáló vállala rendszereket alkotnak.

● A SOA másik vezérlőelve, hogy elterjedt standardok alapján készítjük a rendszert,

így könnyen megszüntethetjük a különböző operációs- illetve
adatbázisrendszerekből adódó különbségeket. A szolgáltatásokat elérhetjük
hálózaton keresztül is, és gyakran megjelennek teljesen eltérő programok
alkotórészeiként.

● A szolgáltatás orientált architektúra újrafelhasználható komponensekre,

modulokra, szolgáltatásokra támaszkodik, amelyek az alkalmazásoktól és a
fu ató pla ormoktól is függetlenül meghívhatók.

35
A SOA négy fő jellemzője:
● Komponens-alapú: szabványos szolgáltatási interfészekre támaszkodik az
alkalmazások és erőforrások felé

● Együ működő: könnyű információcserét tesz lehetővé az alkalmazások és

erőforrások közö

● Moduláris: „építőkocka-elvű” felépítés az üzle folyamatok és az infrastruktúra

terén egyaránt

● Skálázható: „kezdd azzal, amid van, majd terjeszd ki fokozatosan”

A SOA az üzle folyamatok hatékony támogatását célozza a vállalat jelenleg is meglévő

alkalmazásainak segítségével, jóval túlmutat az egyszerű Web Services alapú
kapcsolatokon.

vizsgakérdések
1. SOA Alapelvek
a. Építőelemek, kapcsolataik
b. Újrafelhasználhatóság (reuseable)
c. Szolgáltatási szerződés megosztása
d. Laza csatolás (loose coupling)
e. Működési logika elrejtése – absztrakt interfész szint
f. Összekapcsolhatóság (composable)
g. Autonómia
h. Állapotmentesség (stateless)
i. Kereshetőség(discoverability)
j. OO analógia + Web service támogatás
k. Egyes alapelvek összefüggése – legfontosabb néhány…

SOA Alapelvek összefüggései – Újrafelhasználhatóság

36
5. [Noémi] SOA alap topológia, SOA bevezetési módszertanok

SOA alap topológia

SOA NEM Web Services

37
SOA bevezetési módszertanok

Projekt (SOA bevezetés életciklusa)

Projekt szervezés – mint tetszőleges egyedi eloszo rendszerfejlesztési projekteknél

kisebb SOA specifikus átalakításokkal

Projekt szakaszok:

● Szolgáltatás orientált analízis (Analisys)

● Szolgáltatás orientált tervezés (Design)
● Szolgáltatás fejlesztés (Developement)
● Szolgáltatás tesztelés (Tes ng)
● Szolgáltatás telepítés (Deployment)

38
 ● Szolgáltatás karbantartás (Administra on)

Egyes lépések fontossága → folyamatba szervezése

Projekt sikere: NEM az eredmény SOA „mértéke”, hanem a kitűzö célok elérésének
vizsgálata a rendelkezésre álló idő és költségkeret függvényében

Stratégiák:
● Top-down
● Bo om-up
● Agile (meet-in-the-middle)

A választo stratégia és projekt folyamat meghatározza az elérhető eredményt

Top-down

● „analysis first” – nem csak üzle szolgáltatások, de meglévő üzle folyamatok

(felül)vizsgálata is
● Támogatja valamennyi (több) szolgáltatás szint létrehozását is

Lépései:

● Vállalati üzleti modellek definiálása

○ Üzle modell dokumentumok, ontológiák, en tás modellek
vállalatonként különbözőek – 1 „szabványosíto ” megoldás szükséges
○ Üzle modell centrikus és en tás centrikus leírások
○ Több folyamat/modell/projekt csoport (kialakítása)
● Up-front SOA analízis
○ Szolgáltatási szintek
● Vállala szolgáltatás modell definiálása
○ (Főbb) Szolgáltatás jelöltek definiálása
○ Jelöltek szolgáltatási szintekhez rendelése

39
 ○ Itera v visszacsatolás – folyamatonkén szolgáltatás definiálás, vizsgálat,
finomítás
● Szolgáltatás orientált analízis végrehajtása
● Szolgáltatás orientált tervezés végrehajtása
● Szolgáltatások implementálása
● Szolgáltatások tesztelése
○ Funkcionális & QoS – újrafelhasználhatóság mia körültekintőbb tesztelés
● Szolgáltatások installálása
○ Betöltés a produk v rendszerbe
○ Újrafelhasználás mia gyakori a technikai és funkcionális „plusz” dolgok
használata – pl. security, accessibility v. nagyobb teljesítmény mint épp
szükséges volna

Top-down, előnyök, hátrányok:

● Jó minőségű szolgáltatások → és eredmény Alapos analízis → maximálisan

○ újrafelhasználható komponensek
○ Szabványok következetes használata → egyszerűbb karbantarthatóság,
adoptálhatóság, homogenitás
● Költséges stratégia
○ Idő és költség – az up-front elemzés már maga rengeteg erőforrást
felemészt ami nem mutat rövidtávon látványos eredményt

Bottom-up

● Alkalmazás centrikus szolgáltatások készítése (annyit amennyi lefedi a szükséges

alkalmazási logikát)
● Szolgáltatás készítés csak az igény felmerülésekor – pl. alkalmazás integráció
(wrapper szolgáltatások)
● Lépések: (üzle igények már előfeltételként rendelkezésre állnak)
○ Alkalmazási szolgáltatások modellezése

40
 ■ Alkalmazási igényeknek megfelelő szolgáltatások definiálása (pl.
B2B point-to-point integráció, vagy SOAP alapú komm.
Bevezetése)
■ A szolgáltatások ált. üzle logikát (is) tartalmaznak (hybrid
services)
● Alkalmazási szolgáltatások tervezése
○ Wrapper, 3. party és auto-generált proxy-k-nál nem érdekes
○ Egyedi szolgáltatások tervezése szabványok alapján a homogenitás
céljából
● Szükséges alkalmazási szolgáltatások fejlesztése
○ Korábbi specifikáció alapján
● Szolgáltatások tesztelése
○ Legacy logika tesztelése
○ Legacy alkalmazások performancia (esetleg stressz) tesztelése az
szolgáltatások nézőpontjából
○ Security tesztelése Installálás az éles rendszerbe

Bottom-up – előnyök, hátrányok

● Legelterjedtebb ← legtöbb vállala csak WS szintet/technológiát szeretne adni

az alkalmazásaihoz
● A mögö es vállala IT arhitektúra változatlan marad
● Nem is „igazi” stratégia – jól elősegí WS-ek létrehozását, de cseppet sem a SOA
alapelvek megvalósulását

Agilis

● 2 korábbi köz „arany középút” keresése

○ Üzle specifikáció és szolgáltatás fejlesztés egyszerre

41
 ● Mivel egyszerre 2 oldalról közelítjük a megoldást sokkal komplexebb szervezést
(összehangolás) igényel

Lépések:

● Top-Down analízis (megkezdése)

○ Top-down 1, 2, 3-as lépések, de nem sorban egymásután, hanem
„folyamatonként”
● Szolgáltatás orientált analízis
○ Kezdés, ha a Top-down elért egy megfelelő kiindulási szintet ehhez (nehéz
megítélni, ...)
○ Üzle szolgáltatások modellezése az üzle folyamatok alapján
● Szolgáltatás orientált tervezés
○ Szolgáltatási szintek és szolgáltatások definiálása - mint a Top-Down- nál
● Fejlesztés
● Tesztelés
● Installálás
● Itera v visszacsatolás a Top-down analízishez
○ Üzle folyamatok összevetése az aktuális modellekkel Eltérések
dokumentálása, továbbfejlesztések (tervezés, fejlesztés, stb.) ütemezése
● Szolgáltatási szerződések megtartása
○ új verziók várhatóak, de a régieket is mindig támogatni kell
○ Verziómenedzsment
● Szolgáltatás karbantartás

Agilis stratégia – előnyök, hátrányok

● Az előző 2 előnyeit hivato egyesíteni

● Utólag a szolgáltatásonkén átlagköltség magasabb mint a többi módszernél
(revisit, redesign, redevelopment, stb.)

42
 ● Létező szolgáltatások valamennyi verzióját meg kell tartani → nagy karbantartási
és erőforrás igény

vizsgakérdések:

1. SOA Bevezetési stratégiák

a. Projekt alapok
b. Top-Down
c. Bo om-Up
d. Agilis módszertanok

43
6. [Vencel] Szolgáltatási szintek, szolgáltatási szint konfigurációk

Szolgáltatási szintek
A SOA alapelvek önmagukban semmisek, ezért törekedni kell rájuk és tervezni
velük→ vállalatnál a SOA megközelítést be kell vezetni (szolgáltatási szintek definiálása és
megfelelő használata)

Alkalmazási szint (application service layer):

● “u lity services” ← nem üzle célú, nem kapcsolódik egyik üzle modellhez
sem, olyan szolgáltatások, amelyek sok másik szolgáltatásnak is hasznosak, pl.
árfolyam váltás, kivételkezelés, no fica on, esemény logolás..
FYI check for more : UTILITY SERVICE link :)
● magas szinten újrahasználhatóak
● közös vállala erőforrásokat és képességeket reprezentálnak

44
 ● ado pla orm erőforrásait közve k
● funkcionalitást jól meghatározo rendszer kontextushoz is köthe k
● az alkalmazások sokfélesége mia gyakran inkonzisztensek a granularitásukat
tekintve (mi az a szemcséze ség? :( )
● lehetnek saját, egyedi fejlesztések is, 3. party fejlesztések, wrapper
szolgáltatások,
pl. SystemNo fica onService

Üzleti szint (business service layer)

● komoly tervezés: üzle funkciók milyen üzle szolgáltatásokba legyenek

csoportosítva
● ezt végzik: üzle elemzők, achitect-ek, IT szakemberek közösen
● 2 modell
○ Feladat centrikus üzl. szolg. (Task centric):
■ üzle folyamatot ölel
■ több en tást is érint
■ alacsony újrafelhasználhatóság

■ FYI check for more → TASK CENTRIC link

○ En tás centrikus üzl. szolg. (En ty centric)

■ feldolgozási logikát fog össze
■ egy en táshoz tartozik
■ üzle folyamatok komponálásakor jól újrafelhaszálható
■ en tás lehet: számla, rendelés, kliens…

■ FYI check for more →ENTITY CENTRIC link

○ általában a két modell példányai együ alkotják az üzl. szolg. szintet

45
 ● pl. kifizethetőség, ügyfélegyenleg ellenőrző, könyvelést indító szolg.
○ hybrid: kis cégek, egyedileg fejleszte wrapper szolgáltatásai →
alkalmazási szintre soroljuk inkább

Folyamat szint (komponált szolgáltatások szintje, orchestration service

layer)
● üzle folyamatmodellezés és szolgáltatás orientált tervezés a BPEL folyamatban
megvalósíto workflow szintjén ér össze
● BPEL folyamat maga is szolgáltatás
● szolgáltatások futási sorrendje
● szkenárió specifikus szolgáltatás definiálás
● “orchestrated task services”, “parent business process layer”
● nagyobb, akár hosszú futásidejű szolgáltatások
● orchestra on szint bevezetése általában új IT middleware bevezetését is
szükségessé teszi (process server)

Szolgáltatási szint konfigurációk

1. csak hybrid szolgáltatások (1 szint)

-------------------------------------------------
2. hybrid és u lity szolgáltatások (2 szint) néhány hybrid használ u lity szolg-okat
3. task centric és u lity (2 szint) már jól elkülöníte 2 szint, nem keverednek

--------------------------------------------------
4. u lity, en ty centric, task centric (3 szint) az üzle logikát 2 féle szolg. fedi le
5. u lity, hybrid app, process szolgáltatások (3 szint) 2. + orkesztrációs szint
6. u lity, task centric, process (3 szint)
7. u lity, en ty centric, process (3 szint)

--------------------------------------------------
8. u lity, task centric, en ty centric, process (4 szint)

46
Ezek közül általában a szolgáltatások mérete, tulajdonságai alapján választunk. Hybrid
szolgáltatások szinte mindig találhatók legacy rendszereknél (régi, elavult technológiával
rendelkező hasznos rendszer). Nagy stratégiai előny lehet hosszútávon a megfelelő
megközelítéssel az alkalmazási és üzle szint minél jobb szétválasztása különösen üzle
ÉS folyamat szint együ es bevezetésével.

vizsgakérdések:

1. Szolgáltatási szintek
a. Alkalmazási szint
b. Üzle szint
c. Folyamat szint

2. Szolgáltatás pusok ????? (talán: u lity, hybrid, task centric, en ty centric,

process ← amik a konfigurációkban lehetnek)

7. [Vencel] Folyamat szolgáltatások tervezése BPEL-ben

Alapok
● Legfelső réteg, workflow logika megvalósítás (ha létezik külön orkesztrációs szint
akkor BPEL, egyébként...)
● Egyik legfontosabb kérdés: mikor, hogyan kerülhetünk abnormális működési
ágba, s ekkor mi történik, mi a teendő
● Régen: üzle elemzők modelleztek diagrammokat rajzolva, melyeket átadták az
IT tervezőknek, szakembereknek akik implementálták → komoly eltérési/hiba
lehetőségek
● BPEL: összevonja a tervezési és implementációs nyelvet/környezetet (bár modern
BPEL tervezési eszközök megint „eltávolodnak” a kódtól)

Esettanulmány: Timesheet-es folyamat szolgáltatás

47
 ● Timesheet benyújtása
● Számlázo órák ellenőrzése
● Túlórák és he limitek ellenőrzése
● Dolgozó profil frissítése
● Fele es értesítése
● Dolgozó értesítése

Már létező entitás szolgáltatások és műveleteik

● Employee (ezt muta uk be részletesen korábban)

○ GetWeeklyHoursLimit
○ UpdateHistory
● Invoice
○ GetBilledHours
● Timesheet
○ GetAuthorizedHours
● No fica on
○ SendMessage

Szolgáltatás kompozíció korábbról ado (SOA Analízis: szolgáltatás modellezés,

szolgáltatás rétegek...)

● ÁBRAAAA 590/1 - Fig. 16.6

Folyamat szolgáltatás funkcionalitása is korábbról ado (ugyanúgy SOA analízisből)

● TimeSheet Submission Process Service

○ Compare recorded hours with billed hours
○ Confirm authoriza on
○ Compare weekly hours limit with hours recorded

48
Lépések
1. Interakciók modellezése

2. Folyamat interfész megtervezése

3. Partner kommunikációk formalizálása

4. Folyamat logika definiálása

5. Együ működési szkenáriók feltérképezése és folyamat definíció véglegesítése

1. Interakciók modellezése
● Folyamat és résztvevő partnerszolgáltatások együ működése már
körvonalazódo
– ld. előző fejezet, taszk centrikus szolg. Tervezés
● Módszer: ak vitás diagramok elemzése
● Ese anulmány
○ Korábbi 2 ak vítás diagram: 1 normál lefutás, 2 hibás lefutás (+ értesítés
küldése)
ld. üzle szolg. tervezése
○ A folyamatnak 4 partner szolgáltatása és egy hívó (kliens) szolgáltatása
lesz.
○ ÁBRAAA592, 593, 594. Fig. 16.8,9,10
2. Folyamat interfész megtervezése
● Általában folyamat tervezők generálják a WSDL-t, de jó ha tudjuk módosítani
● Manuálisan (mint korábbi szolgátatás design-nál, pl. üzle szolg, ld.előző
szakaszban)
○ 1. Input, output adatok felmérése műveletenként, types rész XSD-inek
megadása, ha kell külön file-ban

49
 ○ 2. Interfész definiálása – portType rész – opera on alkotóelemeinek
megadásával majd message építőelemek és part-jaik megadása XSD
hivatkozásokkal. Eénevezési koncenviók betartása – mint más szolgáltatás
WSDL-eknél.
○ 3. Meta-információk elhelyezése (documenta on tag)
○ 4. További tervezési standard-ok érvényre ju atása (akár a tervezési
eszköz „ellenében”)
○ További szolgáltatás tervezési dolgok (pl. SOA alapelvek figyelése, mint
állapotmentesség, újrafelhasználhatóság i nem értelmezhető…)

Esettanulmány

Timesheet Submission Process szolgáltatás

Submit művele el

50
51
3. Partner szolgáltatásokkal folytatott kommunikáció definiálása
● BPEL definíció elkészítésének kezdete
○ 1. Folyamat partner szolgáltatásainak meghatározása, szerepek (role)
hozzárendelése
○ 2. Partner szolgáltatások WSDL-jének bővítése a megfelelő
partnerLinkType-al
○ 3. Folyamaton belül partnerLink elemek készítése a partner
szolgáltatásokhoz
○ 4. Változók definiálása kimenő és bemenő üzenetekhez (variables)
○ Ezzel a workflow kommunikációkat lefedtük.
○ Ált. ez a tevékenység (grafikus) UI-al is támogato .

Esettanulmány: Timesheet feldolgozási folyamat definíciója (BPEL)

● 1-es pontból: 1 kliens, 4 partner szolgáltatás

● Role-ek meghatározása
● Partnerlink-ek definiálása a szolg. WSDL-ekben – ld. Példa employee.wsdl
● Partnerlink-ek definiálása a BPEL folyamatban ( pikusan drag&drop...)
● Változók megadása az input/output üzenetekhez – névegyezőség: WSDL name-jei
a messagekből megegyeznek az i eni messageType-al

52
53
4. Workflow logika megadása

Önmagában is komplex lépés – teljes logika definiálása

Esettanulmány

● Korábban definiált (pl. 1. lépés) folyamat és interakciók „lefedése”

● 1. Folyamat logika modellezése BPEL építőelemekkel – pl. ÁBRRA601
modellező/BPEL tervező eszközök) - Fig. 16.12
● 2. Receive elem létrehozása a folyamat „submit” műveletéhez
○ Látható, hogy az input egy teljes mesheet példány -> ClientSubmission
process nevű változóba tesszük
● 3. Ak vitások létrehozása az 1-beni diagram alapján

54
 ○ Először az Invoice szolgáltatást kell meghívni, hogy a leado órákat a
számlázo al összehasonlíthassuk: az összehasonlítást ez a szolgáltatás
NEM végzi el, csak visszaadja a számlázo óraszámot ->
○ Meghívása elő assign-al a ClientSubmission változóból kiszedjük a
customer ID-t és a dátumokat – ezek lesznek az inputok
○ Assign és Invoke elemek létrehozása ld. 21-es dia.

Esettanulmány

3. Ak vitások létrehozása az 1-beni diagram alapján

55
 ● Először az Invoice szolgáltatást kell meghívni, hogy a leado órákat a számlázo al
összehasonlíthassuk: az összehasonlítást ez a szolgáltatás NEM végzi el, csak
visszaadja a számlázo óraszámot
● Válasz a megfelelő InvoiceHoursResponse BPEL változóban lesz – ezt az
óraszámot hasonlítjuk a Timesheet-en lévővel – switch-case használata –ld. 23.
dia
○ Nem egyezőségnél hiba dobása – throw elem -> faultHandlers – ld.
Később
● Ezt a assign-copy-from-to, invoke, switch-case, throw sablont rá lehet húzni a
folyamat további részeire is (és ált. legtöbb workflow egyes részeire is) – korábbi
BPEL tervezési ábra.
● További két lépés röviden
○ TimesheetID kiszedése a ClientSubmission változóból a
● TimesheetAuthoriza onRequest változóba, hogy meghívjuk a Timesheet
szolgáltatás GetAuthorizedHours műveletét. Az eredmény kiértékelését
switch-case-el végezzük, ha gond van (nem volt engedélyezve a munka) hibát
dobunk (throw).

Esettanulmány

3. Ak vitások létrehozása az 1-beni diagram alapján

56
 ● További két lépés röviden
○ 1. TimesheetID kiszedése a ClientSubmission változóból a
TimesheetAuthoriza onRequest változóba, hogy meghívjuk a Timesheet
szolgáltatás GetAuthorizedHours műveletét. Az eredmény kiértékelését
switch-case-el végezzük, ha gond van (nem volt engedélyezve a munka)
hibát dobunk(throw).
○ 2. EmployeeID kiszedése a ClientSubmission változóból az
EmployeeHoursRequest változóba, hogy meghívjuk az Employee
szolgáltatás GetWeeklyHoursLimit műveletét. Az eredmény kiértékelését
switch-case-el végezzük, ha gond van (limitet túllépte a dolgozó) hibát
dobunk (throw).

4. Válasz definiálása (reply)

● Nem szerepelt ugyan az erede definícióban, de lehetne visszajelezni pozi v

esetben is

5. További szkenáriók kidolgozása -> vissza az 1. lépéshez

● Esetünkben a köv. szkenárió hibakezelés, o máshogy járunk el.

Esettanulmány

● Hibakezelés – faultHandlers
○ Keretkonstrukció – ld. 26. dia
○ Esetünkben catchAll-al mindent elkapunk
○ A hibakezelésnél végrehajtandó üzle feladataink
■ Munkatárs history-jának frissítése – ld. 27. dia
■ Fele esének értesítése – ld. 28. dia
■ Munkatárs értesítése – ld. 28. dia

Ezek implementálása assing-invoke párosokkal végezhető el -

tervezzünk i is BPEL modelt mint korábban – ÁBRAA606. - Fig.16.13

57
○ Assing-invoke implementációk elhelyezése a korábbi keretbe - sequence

58
5. Együttműködési szkenáriók igazítása, folyamat finomítása (opcionális)
● Interakciós modellek megőrzése -> dokumentáció szerves része → későbbi
karbantartás, továbbfejlesztés inputja, továbbá
● Teszt esetek is ez alapján definiálhatóak
● Esetleges új szolgáltatás együ mködési igényel kiszolgálása → visszacsatolás
● BPEL op malizálási lehetőségek keresése
○ Többféle módon is definiálható ugyanaz a workflow logika BPEL-ben
■ Ak vitások újrastrukturálása teljesítménynövekedés céljából
■ Kód „áramvonalasítása” – szabványok, stb -> könnyebb
karbantarthatóság
■ Új képességek, lehetőségek keresése

59
Esettanulmány

● Sorba rendeztük az egyes feladatoknak megfelelő szolgáltatás hívásokat

○ Ezek nem függenek időben egymástól, ezért párhuzamosíthatóak (ezzel a
plusz, „bevi ” függőséget megszüntethetjük) – BPEL flow használata.
● Ugyanez igaz a hibakezelés ágon is az elvégzendő feladatokra
● 2 No fica on szolgáltatás hívást lehet 1 konstrukcióba tenni - while

vizsgakérdések
SOA folyamat szolgáltatás tervezése – BPEL

1. Alapok
2. Lépések
a. Interakciók modellezése
b. Folyamat interfész megtervezése
c. Partner kommunikációk formalizálása
d. Folyamat logika definiálása
e. Együ működési szkenáriók feltérképezése és folyamat definíció
véglegesítése
3. Ese anulmány: Timesheet-es folyamat szolgáltatás

60
8. [Ernő] Séma illesztés
Elérhető vállala sémák (pl. xCBL, Oagis)

● Teljes vállala rányítást lefedik

● 8-10 maximális mélységű, 10.000-20.000 csomópontot tartalmazó gráfok

Főbb feladatok - kihívások

Séma illesztés

● Hatékony módszerek és algoritmusok készítése

○ Pontossága
■ Univerzális mérési és összehasonlítási módszer
○ Számítási komplexitása
■ Komplexitás meghatározása, csökkentése

Szolgáltatás alapú integráció (SOA-EAI)

● Transzformációk alkalmazása
○ Nyílt szabványokon és elterjedt standard eszközökön alapuló megoldás
● Futásidőben is működő megoldás készítése
○ Újrafelhasználhatóság, modularitás, átlátszóság figyelembevétele
● Nem funkcionális teljesítmény paraméterek vizsgálata
○ Kiszolgálási idő és áteresztőképesség becslése és mérése speciális vállala
környezetben

Összete pusok relációja

● 2 összete pus pl. 2 szolgáltatás interfész input és output adatainak halmaza (A
és B)
○ Ekvivalens – ha ugyanazt a valós világbeli en tást reprezentálják

61
 ○ Tartalmazási viszonyban van – ha az egyik (A) reprezentálja valamennyi
valós világbeli en tást melyiket a másik (B) reprezentálja
○ Á edésben vannak - ha van olyan valós világ beli en tás amit A és B is
reprezentál, de A nem tartalmazza B-t és B nem tartalmazza A-t
○ Különbözőek – ha A nem reprezenál 1 olyan valós világbeli en tást sem
amit B is.
● Összete pusok relációja -> interfészek irányíto kompa bilitása
(összekapcsolhatóság egy ado folyamatban)
○ Globális és lokális séma
■ Alkalmazási területek összekapcsolása tervezési időben,
folyamatkomponálás elő
○ Reláció -> transzformációk elemhalmaza
■ A (globális en tás) és B (lokális en tás) ekvivalensek (őket
transzformációs szabályokba foglalva össze kell kötni)
■ Ha A tartalmazza C-t (lokális en tás), akkor valószínűleg össze kell
kötni A-t C-vel valamennyi transzformációs szabályban
■ Ha A és D (lokális en tás) á edésben vannak, akkor lehet, hogy
össze kell kötni A-t D-vel valamennyi leképzési szabályban

Megközelítések
● Lingvisz kus – „string alapú” egyezőségek értékelése –
pl. részszavak, leghosszabb előtagok, stb.
● Strukturális – fastruktúra hasonlóságának vizsgálata –
pl. csomópontok hasonlósága (gyerek, szülő, leszármazo , ős-csomópontok stb.)
● Szótár alapú – tartalmi kapcsolat megítélése szótár alapján –
pl. Ontológia, szeman kus szótár
● Kombinált – ke ő(vagy több megközelítés) ötvözése
○ Legelterjedtebb

62
 ○ Komponensekre oszto – azokat súlyozva ér el eredményt:
F= a * A + b * b + c * C.... , ahol a+b+c.... = 1
● Hasonlósági mérték megadása: 0..1 skálán
○ 1: a két en tás pontosan megegyezik
○ 0: nincs tartalmi kapcsolat a 2 en tás közö

NTA algoritmus
Fogalmak szeman kus távolságát meghatározó algoritmus: 3 tagfüggvény,

● elnevezések N(),
● csatolt fogalmak és leírások T(), illetve
● kapcsolódó a ribútumok A()

hasonlóságának kiértékelésére: NTA algoritmus.

A képlet:

A képlet N része:

A képlet T része:

63
A képlet A része:

64
Küszöbérték probléma

● Séma illesztés - küszöbértékezés

● Eldön , hogy az ado hasonlóság mértéke alapján 2 en tás össze
tartozik vagy sem (azaz vizsgáljuk-e őket transzformációk
definiálásakor)
● Küszöbérték helyes megválasztása kri kus
○ Túl magas – kevés a találat, igaz azok biztosan valódi találatok
(pontosság nagy)
○ Túl alacsony – sok a találat, igaz abból sokhamis (felidézés
nagy)
○ Küszöbérték választási stratégia - költségmodellek

65
Jósági mutatók

*F-mérték: jósági mutató, a pontosság és a felidézés harmonikus közepe

Vizsgakérdések
1. Probléma formalizálása

2. Megközelítések – algoritmus pusok

3. NTA algoritmus és komponensei
4. Jósági mutatók
5. Küszöbérték probléma

66
9. [Vencel] En tás centrikus szolgáltatások analízise és tervezése
(top down módszertanban)

Szolgáltatás tervezés alapok

● „WSDL-first” megközelítés
● Szolgáltatás tervezés célja olyan kiegyensúlyozo szolgáltatások tervezése,
melyek
○ Pont a szükséges üzle logikát fedik le
○ Szolgáltatás orientált alapelveket köve k
○ Üzle elvárásoknak is megfelelnek (funkcionális és egyéb...)
● Input: szolgáltatás jelöltek a SOA analízisből
● Javasolt tervezési sorrend – kicsi, újrafelhasználható szolgáltatások felől haladva a
komplexebb, üzle tartalommal bírók felé
○ 1. En tás-centrikus szolgáltatások
○ 2. Alkalmazási szolgáltatások
○ 3. Taszk-centrikus üzle szolgáltatások
○ 4. Folyamat (kompozit) szolgáltatások

Sorrend nem törvény- pl. agilis SOA bevezetési megközelítés

● Konzisztens tervezési szabványok használata a cégen belül

● Szolgáltatás tervezés Outputja, definiáljuk a
○ Szolgáltatások valamennyi műveletét
○ Az összes művelet input és output üzenetét
○ Az összes kapcsolódó XSD sémát és pust az üzetnet-tartalom leírásához

En tás centrikus szolgáltatás tervezése

// ese anulmányokat nem írtam bele, ha szerintetek kellenek, akkor beleírom

67
1. Létező szolgáltatások felülvizsgálása
● Létezik-e már a megvalósítandó funkcionalitás más szolgáltatásokban (azok
műveleteiben)?
● Vagy létezik-e az a jól definiált környezet egy másik szolgáltatásban ahová a
művelet jelöltjeink passzolnak?
2. Entitás séma definiálása
● Szolgáltatás által használandó üzenetek definiálása – WSDL types
● XSD a SOAP body-ban elhelyeze tartalomra
● Séma tükrözze a benne foglalt tartalmat → en tás centrikus sémák használata
3. Absztrakt interfész elkészítése

1. Megvizsgáljuk, hogy valamennyi szolgáltatás jelölt generikus és

újrafelhasználható-e → azaz megfelelő- e a lefede funkcionalitás granularitása.
Továbbá a 2.lépésben lévő pusok alapján definiáljunk neveket a műveleteknek.

2. Hozzuk létre az opera on egységeit a WSDL portype- ban (interface-ben)

3. Szükséges input és output-ok definiálása valamenny művelethez (message-ek

definiálsa ami a korábbi XSD-re hivatkozik)

4. Szolgáltatás-orientáltság biztosítása

1. Szolgáltatás újrafelhasználhatóság (reusability)

2. Autonómia (autonomy)

3. Állapotmentesség (statelesness)

4. Kereshetőség (discoverability)

● Első 2 teljesül, már a modellezésnél is figyeltünk rá, ill. en tás centrikus

szolgáltatásokra alapvetően igaz (általában)
○ Autonómia igaz lesz, hiszen az en tás centrikus szolgáltatások ált.
2 szolgáltatás réteg közö lesznek, így üzle /kompozit

68
 szolgáltatások használják őket ill. ők alkalmazási szolgáltatásokat
használnak
● Állapotmentesség – vagy magától teljesül, mivel nem fednek le túl nagy
üzle logikát, vagy külön figyelünk rá, ha több alkalmazási szolgáltatást
használnak (document-style SOAP üzenetek használatával)
● Kereshetőség – a korábbi 1. lépés mia is fontos, azaz en tás centrikus
szolgáltatások NEM fedhetnek át funkcionalitásban
○ Megfelelő metadata definiálása, hozzáadása (documenta on
elem)
5. Szolgáltatás interfész szabványosítása, finomítása
● Ez a lépés a szükséges szabványoktól és egyéb követelményektől függ. Egy
lehetséges megközelése:

1. Tervezési szabványok és standardok á ekintése és alkalmazása

ld. Később tervezési guidline-ok.

2. További SOA karakterisz kák támogathatóságának vizsgálata (pl. QoS)

3. WS-I Basic profile megfelelőség vizsgálata (a profil elvileg kész WSDl-t vár
el, de ami eddig elkészült az is vizsgálható)

6. Szolgáltatás tervezés kiterjesztése

● További újrafelhasználhatóságot erősítő funkciók keresése – en tás centrikus
szolgáltatásoknál különösen fontos
● Új funkcionalitás implementálása
○ Új műveletek hozzáadása (eddigi design lépések ismétlése)
○ Új paraméterek hozzáadása meglévő műveletekhez (a túl sok sem jó,
mert a hívó részéről akkor túl sok előismeretet tételez fel pl.)
● En tás-centrikus szolgáltatások „klasszikus” művelethalmaza
○ GetSomething, UpdateSomething, AddSomething, DeleteSomething

69
 ○ Ezek következetes betartása jó kiindulópont lehet →
újrafelhasználhatóság, komponálhatóság
● Csak addig adjunk hozzá új funckionalitást, amíg annak értelme lehet...
(overhead + újra kell elemezni + implementálni kell majd egyszer, stb.)

7. További szükséges szolgáltatások azonosítása

1. Nem biztos, hogy minden szolgáltatás azonosítva le a szolgáltatás orientált

analízisben

2. Meglévő szolgáltatások végrehajthatóságának elemzése – azaz megvannak-e a

végrehajtáshoz szükséges alkalmazási szolgáltatások? → További szükségesek
definiálása (ellenőrzés már létezik-e azt lefedő másik...)

Szolgáltatás orientált analízis

Célja:

● lehetséges szolgáltatás műveletek definiálása

● műveletek csoportosítása → szolgáltatásokba
● szolgáltatáshatárok előzetes megállapítása
● beépítendő üzle logika elemezése újrahasználhatóság szempontjából
● szolgáltatás autonómiát zavaró tényezők összegyűjtése

Folyamata

1. Analízis területének behatárolása (analyzis scope)

● Tipikusan ez egy üzle folyamat „egység”
● Ált.: folyamatból indulunk, s azt dekomponáljuk több szinten
szolgáltatásokba
● Lehet egy önálló üzle szolgáltatás is
● Vagy egy pikus beágyazásra készülő szolgáltatás

70
 ● En tás centrikus szolgáltatásoknál nehéz a terjedelem meghatározása
● Dokumentálás a SOA bevezetési projekt későbbi szakaszai mia kri kus
2. Meglévő üzle alkalmazások/megoldások azonosítása
● Előző pontban azonosíto /lefede funkcionalitás azonosítása meglévő
alkalmazásokban/megoldásokban
● Alkalmazási kényszerek pontos azonosítása csak a későbbi (design)
szakaszokban szükséges
3. Szolgáltatás jelöltek modellezése (service candidates)
● Szolgáltatás műveletek azonosítása, szolgáltatásokba (szolgáltatás
jelöltekbe) csoportosítása
● Ez a későbbi szolgáltatás tervezés legfőbb inputja

Üzleti szolgáltatások és difiniálásuk

Miért definiáljunk üzleti szolgáltatásokat?

● A SOA alapelvek érvényre ju atásáért -> pl. megváltozo üzle folyamatok

könnyen átalakíthatóak ha SOA alapelvek mentén készültek a szolgáltatásaik a
technikai szinten is
● Ha (később) (mégs/n)incs lehetőség folyamat szint alkalmazására
● Előkészíteni az alsó(bb) szinte(ke)t a későbbi orkesztrációra
● Elősegí az újrafelhasználhatóság megvalósulását
● Az üzle logika modellezése elősegí üzle szolgáltatások sőt akár
részfolyamatok újrafelhasználását
● Az üzle szolgáltatások szintje lehetővé teszi, hogy szta alkalmazási szolgáltatás
szint is létrejöhessen, magas fokon újra felhasználható, generikus
szolgáltatásokkal
● Kikényszerí az üzle tudás/folyamatok szolgáltatás-orientált definiálását
● Üzle változások esetén a folyamatok újraszervezését/átalakítását támogatja egy
meglévő továbbra is használható üzle szolgáltatás réteg (=„szint”)

71
 ● Példa: hybrid szolgáltatások fele külön üzle szolgáltatási réteget alkothatunk

Üzleti szolgáltatások definiálása

● Szolgáltatás modellezés
● Üzle folyamatmodellezés is mindenhol más és más (folyamat modell, eszköz,
nyelv -> minden folyamat egyedi)-> up-front analízis NEM kerülhető el
● Üzle szolgáltatás ~ Vállala belső működési egy egysége (unit of work)
● A folyamatmodellezés és dokumentálás azonban mindenhol más -> megfelelő
megközelítés kiválasztása, példa:

Módszertanok: BPM és Entitás modellek

// innentől már Modellek

I. Business Process Management (BPM)

○ Folyamat modellezés és újra(ésújra...)modellezés
○ Üzle logika a folyamatokban van dokumentálva -> szolgáltatások a
workflow-ból nyerhetőek ki
○ Komoly döntés, a szolgáltatás terjedelmének megállapítása a folyamatból
II. Entitás modellek
● En tás = főbb üzle dokumentumok és tranzakciók pl. megrendelés,
számla...
● En tás centrikus szolgáltatások – en tásokhoz kapcsolódó műveleteket
fognak össze
● En tások kapcsolatainak feltérképezése, modellezése

Task-centrikus és entitás-centrikus szolgáltatások, folyamat (szolgáltatások)

Levezethető Task centrikus szolgáltatások

● Tipikusan Use-case modellekből v. BPM folyamat-definíciókból

● Pl. Számlaellenőrzés, GetHistoryReport

72
 ● Tipikusan azonnali eredmény elérése céljából használt megközelítés
– kisebb újrafelhasználhatóság
● Előző példánk Task centrikus szolgáltatásai:
○ Számlaküldő szolgáltatás
○ Megrendelés feldolgozó szolgáltatás
○ B2B partner értesítésére feliratkozó szolgáltatás (meta-data periodikus
lekéréséhez)

Levezethető entitás centrikus szolgáltatások

● Ismertetőjegyük: interfészük nem (ado ) folyamat specifikus →

újrafelhasználhatóság → újrakomponálhatóság
● Több front-end analízist igényelnek -> költséges
● Generikusak, felhasználásuk vagy irányító task-centrikus szolgáltatások vagy
folyamatréteg „ala ” történik
● Korábbi B2B példánk- nagy cég en tás centrikus szolgáltatásai:
○ Számla kifizethető, ügyfél profil és kifizetést ütemező/könyvelő
szolgáltatások illetve megrendeléseket kezelő szolgáltatás

„Levezethető folyamat szolgáltatások”

● Folyamatot megvalósító implementáció is szolgáltatás, méghozzá erősen

üzlet-centrikus (business-centric)
● A folyamat szolgáltatás pikusan task és en tás centrikus szolgáltatások
kombinációját tartalmazza:
○ Alap üzle modell az en tás szolgáltatásokon,
○ Üzle logika (ado folyamatra) specifikus feldolgozás pedig a task
centrikus szolgáltatásokon keresztül jelenik meg.
● Folyamatszint speciális esetek kezelésére is használatos: pl. humán interkació
kezelése

73
vizsgakérdések (Szolgáltatás tervezés alapok+Entitáscentrikus szolgáltatások
tervezése)

Tervezés folyamata

1. Létező szolgáltatások felülvizsgálása

2. En tás séma definiálása
3. Absztrakt interfész elkészítése
4. Szolgáltatás-orientáltság biztosítása
5. Szolgáltatás interfész szabványosítása
6. Szolgáltatás tervezés kiterjesztése
7. További szükséges szolgáltatások azonosítása

vizsgakérdések (Szolgáltatás orientált analízis – 1.)

1. Célja
2. Folyamata
3. Üzle szolgáltatások és definiálásuk
a. Módszertanok: BPM és En tás modellek
b. Task-centrikus és en tás-centrikus szolgáltatások,
folyamat (szolgáltatások)

74
10. [Noémi] Szabványosító testületek + Tanult SOA bevezetés
szolgáltatás analízis, tervezés lépései

Szabványosító testületek
WorldWideWebConsortium(W3C)~400fő

● 1994-től, a html-el kezdődö („az IT valaha készíte legnépszerűbb technikai

szabványa”
● Később eBusiness irányba mentek – pl. XML, XLS, XSLT – amik a későbbi
szabványok alapjai le ek.
● SOAP & WSDL – elválaszthatatlan ma már a WS-ektől.
● WS-CDL- choreography-hoz
● Nagyon formális, szigorúan kötö szabványosítási folyamatok –sok review,
revision stages, 2-3 év á utási idő

Organization for the Advancement of Structured Information Standards (OASIS) ~ 600

fő

● 1993 – SGML -> 5 évre rá az XML kiszoríto a

● WS-BPEL, ebXML, UDDI
● Manapság security és access control: legfontosabb WSS (Web services security)
szabvány
● Ipar-közelibb/függő szabványok létrahozása
● W3C-nél sokkal rövidebb á utási idők

Web services Interoperability Organization( WS-I)~200fő

● Nem szabványkészítes, „csak” az interoperabilitás megvalósítása volt a cél

2002-ben.
● Basic Profile – az interoperabilitáshoz ajánlo szabványok gyűjteménye (WSDL,
SOAP, UDDI stb.)

75
 ● Aktuálisan: Basic Security Profile
● Példa implementációk és best prac ce-ek a használhatóság elősegítésére
● Szo ver szállítók törekednek a Basic Profile-al való kompa bilitásra

Tanult SOA bevezetés szolgáltatás analízis, tervezés lépései

SOA bevezetés életciklusa

Projekt szervezés – mint tetszőleges egyedi eloszo rendszerfejlesztési projekteknél

kisebb SOA specifikus átalakításokkal

Projekt szakaszok:

● Szolgáltatás orientált analízis (Analisys)

● Szolgáltatás orientált tervezés (Design)
● Szolgáltatás fejlesztés (Developement)
● Szolgáltatás tesztelés (Tes ng)
● Szolgáltatás telepítés (Deployment)
● Szolgáltatás karbantartás (Administra on)

Lépések

Szolgáltatás orientált analízis (Analisys)

● Bevezetendő SOA megoldás terjedelme

● Szolgáltatási szintek meghatározása
● Szolgáltatás jelöltek meghatározása

Szolgáltatás orientált tervezés (Design)

● Szabványok, ipari megoldások és szolgáltatás orientált elvek összehangolása

● Komoly tervezési döntések a szolgáltatások határainak pontos kialakításánál
● Szolgáltatáis szintek szolgáltatásainak megtervezése, köztük az orkesztrációs szint
is szerepelhet i

76
11. [Noémi] WS* szabványok
Szabványok:

● WS-Addressing,
● -ReliableMessaging,
● -Policy Framework,
● -MetadaExchange,
● -Security,
● -No fica on Framework,
● -Even ng

Addressing

● Mint egy postai küldeménynél, ismerjük:

○ Honnan jön a csomag/üzenet,<wsa:From>
○ A küldemény címét,<wsa:To>
○ A meghatározo személyt a célcímén,
○ <wsa:RelatesTo> (korreláció)
○ Hovaküldjük,ha nem sikerült a megjelölt helyre kézbesíteni.<wsa:FaultTo>
○ (mindhez kell a<wsa:MessageID>üzenetazonosító)
● Cím: WSDL endpoint reference – ismert.
○ Konkrét WS példány is megjelölhető (pl.arégiWeb-alkalmazásokURL
végére toldalékolt megoldással oldo ák meg a példány azonosítást) –pl.
WSDL: reference parameters
○ Többi WSDL adat:address(URL),referenceproper es,servicepor ype, port
type, policy

WS-Addressing szabvány:

● SOAP header-ekben. (Message informa on headers: az együ működő

szolgáltatások köz szabályokat írják le –üzenetváltás szeman kája)

77
 ● Az üzenet ezáltal autonóm kommunikációs egységgé válik -”minden” információt
maga tartalmaz.
● Példa: Service (A, C, D) -> Üzenet[A-tól, B-nek, Válaszolj C-nek, gond van értesítsd
D-t] -> Service B

Előny:

● SOAP üzenetek biztosítják az üzenet logikát az addressing-hez

● ReliableMessaging, policies, metadata exchange addressing használatával van
megoldva
● Web szolgáltatások végpont azonosítása addressing-el van megoldva
● Addressing segít a korreláció megvalósításában is

ReliableMessaging

Lazán csatolt rendszereknél a kommunikációs folyamat irányítása kérdéses:

Miután egy szolgáltatás elküldö egy üzenetet, nem tudja azonnak, hogy:

● Sikeresen célba ért-e,

● Esetleg elvesze , s újra kell küldeni,
● Az üzenetek helyes sorrendben érkeztek-e meg.

WS-ReliableMessaging szabvány:

● Küldő értesítést kap a siker/vagy hiba tényéről ill hogy a sorrend megfelelő volt-e.
● Megvalósítás SOAP header-ekben
● Plusz logikai réteg: RM source, RM des na on az applica on source és
des na on fele (ala ? ☺), send -> transmit -> receive.
● Visszaigazolások: acknowledgements
○ <wsrm:Sequence><wsrm:SequenceAcknowledgement>
■ <wsrm:MessageNumber>
■ <wsrm:AcknowledgementRange Upper=„8” Lower=„6”>
■ <wsrm:Nack>5</wsrm:Nack> - nega v visszaigazolás

78
 ■ <wsrm:AckRequested>
● Egyéb elemek,
○ pl. SequenceRef a biztosíto üzenetküldés megvalósításához:
■ Legfeljebb egyszer érjen célba (AtMostOnce)
■ Legalább egyszer (AtLeastOnce)
■ Pontosan egyszer (ExactlyOnce)
■ Sorrendben (InOrder) stb. Expires – elavulás dátuma
● ReliableMessaging biztosítja a SOAP üzenetek kézbesítését, vagy a hiba jelzését
● ReliableMessaging használja az Addressing eszközeit – címzés a visszaigazolásnál,
újraküldésnél, stb.
● ReliableMessaging a korreláció egyfajta megvalósítása lehet – üzenetek
számozása

Correlation

● Laza csatolás mia nem tudni mely üzenetek tartoznak össze/egy

kontextushoz/egy feladathoz. „Alapvetően” egy egyszerű request-response
„páros” response üzenete sem hivatkozik a request üzenetre.
● Korreláció feladata üzenetek közös értekkel történő „megjelölése”, hogy a
kommunikáló szolgáltatások „össze legyenek kötve”.
● Szolgáltatások állapotmentesek (perdef) -> ezt is az üzenetben-headerben kell
megoldani /korábbi eloszto rendszereknél folyamatosan fenntarto kapcsolat
mia a korreláció implicit megvalósíto – technológia függő protokollal
megoldo /
● Correla on-nal megado kontextus lehet egyszerű atomic transac on, vagy
komplex – long running occhestra on.

Megvalósítható

● pl. Ws-Coordination-nal:

79
 ○ ac va on service felelős az ak vítások létrahozásáért, és a contextus
információk létrehozásáért és szétküldéséért.
○ Szolgáltatások ez alapján regisztálhatnak az ado kontextusba. (Megj.
Persze WS- Coordina on sokkal többről szól, teljes ac vity protocoll-okat
valósít meg mint atomic transac ons vagy business ac vi es)

SOA Policies

Üzle folyamatok szabályokhoz és kényszerekhez kötö ek. Ez vonatkozik a

megvalósításukban résztvevő folyamatokra is, lehet:

● " Speciális üzle elvárás,

● " Speciális természetű adat kezelése,
● " Szerveze biztonsági követelmény, stb.

Másrészről a szolgáltatásoknak is lehet egyedi karakterisz kája:

● " Viselkedési karakterisz ka,

● " Preferenciák,
● " Technikai korlátok,
● " QoS karakterisz kák.

Mindezeket metaadatok írják le, ezt valósítja meg a Policy (így ezek explicit
leírására/használatára nem kell külön egyedi megoldás)

Megvalósítás: WS-Policy (ami a WS-Security része)

● Policy leírás felépítése: Policy descrip on {policy alterna ve(- Policy asser on
type(-
● Policy asser on A);(- Policy asser on B)));(policy alterna ve(..(..)))}
● Policy futásidőben mutatja a hívó szolgáltatásnak milyen korlátozások (+stb.)
ado ak a hívo szolgáltatásnál VAGY tervezési időben értelmezhető hívó
szolgáltatást implementáló humán felhasználó által ! Minden a Policy asser on
szintjén van leírva, melyeket opcionálisként és kötelezőként is meg lehet jelölni.

80
 ● Policy alterna ve – egy elfogadható kombinációt jelöl meg.
● Policy subject: lehet WS, üzenet, vagy más forrás. Gyűjtő leírás: policy scope-ban
(policy a achment használatával).
● <wsp:Policy> : asser on elements: TextEncoding, Language, Specversion...
● <wsp:Policy> : elements: <wsp:ExactlyOne><wsp:All>
● <wsp:Policy> : usage a ributes: Required, Op onal, Rejected, stb.
● <wsp:Policy> <wsp:PolicyA achment><wsp:AppliesTo>
● Policies támogatja a ReliableMessaging-et
● Policies addressing-et használ (applies to)
● Policies metaadatainak terjesztésére a metadata exchange ad megoldást
(szabványt)
● Policies önmagában metaadatokat ad a szolgáltatásokról (viselkedés,
preferenciák, kényszerek, stb.)
● Példa: B2B – számlafogadó rendszer Policy-val mutatja, hogy új (pl.
ReliableMessaging) szabványt használ (preferálja)– de még a régi formátumot is
fogadja (policy alterna ves). E ől függetlenül persze külön rögzíthe a
textencoding-ot kötelezőként minden esetben

SOA Metadata exchange

● WSDL definíció tartalma

● Policies egyéb tulajdonságokat is jelent -> metadata amihez hozzá kell férni:
○ " Manuálisan a publikált dokumentumok közö keresve
○ " Manuálisan a szolgáltatástól elkérve
○ " Programozo an nyilvános registryből (public registry)
○ " Programozo an a szolgáltatástól kérve egy speciálisan erre kialakíto
interfész megszólításával
● Szabvány: WS-MetadataExchange – szabványosíto lekérdezési folyamat egy
végpont felé (endpoint)

81
 ○ ‘Metadata exchange request’ – szolgáltatás végpont ismert kell hogy
legyen!
● Megvalósítás SOAP üzenetben header-ben&/body-ban – „klasszikus”
Request-Response MEP-ben.
● <wsa:Ac on>
h p://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request
</wsa:Ac on> VAGY <body><wsx:GetMetadata/><body>
○ Válasz: WSDL, Schema, Policy (lehet maga a dokumentum vagy annak
címe)
● Bővíthetőség (minden más meta lekérése) Get paranccsal:
● <wsa:Ac on> h p://schemas.xmlsoap.org/ws/2004/09/mex/Get/Request
</wsa:Ac on> <wsx:Dialect>h p://www.w3.org/2001/XMLSchema</> -
metadata exchange type and version meghatározása
● <wsx:Iden fier>h p://www.xmltc.com/tls/schemas/ap1/schemas</> - melyik
metadata elemről van szó
● <wsx:MetadataSec on> - metadat struktúrálása az üzenetben, pl.: 1. WSDL, 2.
reference-endpoint, stb.
● Szelek v get request & response (sok WSDL, XSD, stb lehet 1 végponton)
● Metadata exchange != Service Discovery
● Service contract automated administra on <- Metadata exchange
● Metadata exchange-t a standard SOAP üzenetek teszik lehetővé
● Metadata exchange addressing-et használ – pl. <wsa:ReplyTo>
● Metadata exchange a szabvány a Policy-k lekérdezésére
● Metadata exchange teszi lehetővé WS-ek közö szabványos meta-adat cserét
● Legfontosabb, hogy leveszi a terhet a fejlesztők válláról, nem kell egyedi
metadata csere megoldásokat fejleszteni.

82
 ● Példa: B2B számlabeküldő előbb metadata-t kérdez, ha újabb, nem megfelelő
leírásokat kap, nem küld számlát. VAGY periódikusan (pl. naponta) lekéri a
metadata-t.

SOA Security

● Csak az és csak ahhoz férjen hozzá amihez jogosultsága van

● SOA-ban securityre használható:
○ WS-Security,
○ XML-Signature,
○ XML-Encryp on,
○ Ws-Trust,
○ Ws-Federa on,
○ SAML,
○ XACML,
○ .Net Passport,
○ SSL,
○ WS-I Basic Security profile,
○ stb. több mint 10 különb szabvány.
● Security: 1. iden fica on, 2. authen ca on, 3. authoriza on, 4. confiden ality, 5.
integrity:
○ 1. requester ident. Infot küld magáról
○ 2. a requester tényleg az-e akinek mondja magát
○ 3. mire is van joga a requesternek?
○ 4. bizalmas információk kezelése
○ 5. küldö info NEM változhat meg a kézbesítés ideje ala
● Singlesign-on:SOA-ban nem ado mivel a szolgáltatások autonóm-ok->külső
kezelési mechanizmus szükséges.
Pl. SAML: service provider az egyben issuing authority is – kérésre authen- és
author- asserion-ket küld a többi providernek. ÁBRA!!!

83
 ● Transport level security(pl.SSL) VS message level security (ÁBRA)
Előbbinél nincs védve az adat egy intermediary service-nél – pl. rou ng,
terheléselosztó, stb.
● Utóbbi: encryp on & digital signatures („útközben nem olvasható, nem
manipulálható az üzenet)
● Web services & SOA: SOA Security
○ Security – SOAP üzenet védelme
○ Security – követelmények Pocilcy-ban vannak leírva
○ Security – biztosítja a WS-ek helyes használatát (nincs visszaélés,
engedély nélküli adat módosítás- hozzáférés, stb.)

SOA Notification & Eventing

● Publish and subscribe

○ Feliratkozás egy biz. TOPIC-ra (közvetlenül a publisher-nél vagy borker
szolgáltatásnál)
○ Publisher (v. borker) broadcast-ol a feliratkozóknak ha a Topic-on vmi.
Esemény történt
● Megvalósítás:
○ WS-Notification framework (IBM)
■ WS-BaseNo fica on – szabványosíto szolgáltatás interfészeket
definiál
■ WS-Topics – topics-ok strutúrálása, csoportba sorolása.
■ WS-BrokeredNo fica on – szabvány a broker szolgáltatás
definiálására/használatára
■ Folyamat: event -> situa on -> 1* no fica on message[topics] ->
topic alapján értesítés küldése a feliratkozo aknak
■ Egyszerű model – ÁBRA(270) – külön subscriber és no fica on
consumer

84
 ■ Összete model – ÁBRA(271) – külön no fica on
broker(no fica on producer), publisher registra on
manager(feliratkozás segítése – pl. topic keresés) és subscriber
manager(ado topicra feliratkozo ak lekérdezését nyújtja a
brokernek)
○ WS-Even ng (Microso )
■ Event sources(feliratkoztatás, no fica on-ök küldése), Event
sinks(fogadó) and subscribers(feliratkoztató), Subscrip on
managers(opcionális réteg) (ÁBRA 273)
■ Subscrip on messages & filters(feliratkozás tárgya – események
halmaza):

85
12. [Tomi] Vállala tartalmak - tartalom integráció

Vállala tartalmak
● Nyomtatási kimenetek
● Elektronikus Formok
● Képek, videók, hang
● Weboldalak
● Papír alapú dokumentumok, mappák
● Irodai dokumentumok
● Fax
● Email

Tartalomkezelési szolgáltatások:

● Adatok tárolása Strukturált

○ Rekordok, relációs adatok
● Strukturálatlan
○ Dokumentumok
○ Képek
○ Levelek
○ Riportok, nyomtatási képek
○ Hangfelvételek
○ Egyéb mul média
● Metaadatok
○ Manuálisan rögzíte
○ Automa kusan extraktált

86
Tartalom integráció

Vállalati tartalom integráció

Definíció:

Vállala tartalom integráció egy olyan middleware szo vermegoldás és kapcsolódó

módszertan, mely célja az alkalmazási rendszer által kezelt dokumentumok és egyéb
digitális tartalmak decentralizált menedzselésének megvalósítása. Legfőbb hozzáado
értéke a strukturálatlan tartalmak kezelésének megoldása (feldolgozása, elérhetővé
tétele, stb.)

Főbb funkciók:

● tartalom migrálás és szikronizáció külön rendszerek közö ,

● keresés/kereshetőség megvalósítása reposirty-k/ban,
● Single point of Access – biztosítása.

Enterprise Content Management - Tartalom menedzsment

Definíció:

Vállala stratégiák, módszerek eszközök azon együ ese mely megvalósítja a

vállala dokumentumok és a vállala üzle folyamatai alapján releváns egyéb tartalmak
menedzselését teljes életciklusuk ala .

Főbb funkciók:

● capture - felvesz/begyűjt
● manage – kezel
● store - tárol
● preserve - megőriz
● deliver - szállít

87
Capture:

● Papír alapú tartalmak szkennelése

● Elektronikus adatok begyűjtése
● Metaadatok létrehozása

Alkalmazott eszközök:

● Szkennelt adatok feldolgozása, példák:

○ Szkennelt adatok feldolgozása, példák:
○ Op cal character recogni on (OCR)
○ handprint character recogni on (HCR) Intelligent character recogni on
(ICR)
○ Op cal mark recogni on (OMR)
○ Barcode recogni on
● Képfeldolgozás/ sz tás: pl. forgatás, élesítés, szín beállítás stb…
● Formanyomtatványok: Form-processing – electronic forms
● Indexelés – manual/automa c

88
89
13. [Ernő] ESB
Enterprise Service Bus (ESB)

● Elsősorban architektúrális minta (pa ern) melyet számos módon

implementálhatunk
○ Centralizáltan
○ Eloszto an
● Szabványokon alapuló integrációt tesz lehetővé lazán csatolt alkalmazások és
szolgáltatások közö :
○ Szolgáltatás-orientált architektúrában
○ Üzenet-vezérelt architektúrában
○ Esemény-vezérelt architektúrában
● Az ESB-n belüli mediáció a szolgáltatáshívások / üzenetek / események intelligens
feldolgozását teszik lehetővé:
○ Az alkalmazások végpontjain, illetve a bus infrastruktúrájában
■ Transzformáció, szolgáltatás-kiválasztás, tartalom-alapú irányítás
(rou ng)
■ Loggolás, mérés, monitorozás

90
 ■ Autonóm viselkedés (rendszer & üzle események detektálása,
op malizáció...) architektúrában
○ Hívó és szolgáltató összekötése
■ Lazán csatolt módon
■ „Separa on of concerns”
○ Szolgáltatás virtualizáció
■ Rou ng – elfedi a szolgáltatót
■ Conversion – elfedi a hívás módját
■ Transforma on – elfedi az interfészt
○ Aspektus orientált kapcsolatot tesz lehetővé
■ Security
■ Management
■ Logging, audit
■ Stb.

ESB képességek

91
Bus részei

Mediation Flows (Mediation Patterns)

● A hívó és szolgáltató közö áramló üzenetek feldolgozása

○ Large grained – összete mediációs logikák
○ Újrahasznosíthatók
○ Media on Pa ern-ekből épülnek fel
● Media on Pa ern-ek alkotják a mediációs folyamatok lépéseit
○ Small to middle grained – elemi lépések
○ Intenzíven újrahasznosíthatók
○ ESB termékekben „mediációs primi veknek” nevezik

Message Models (Meta models)

● Message Models
○ A hívó és szolgáltató közö áramló adatstruktúrák leírása, kezelése
○ Meta-modellek
■ Üzenetek leírására szolgál
■ Pl.: XML Schema language
○ Tartalom-modellek írják le a konkrét üzene pusokat
■ Pl.: XML Schema
● Az ESB-k legalább egy meta-modelt támogatnak
● Az ESB-k több tartalom-modellt támogatnak

92
 ● Iparág-specifikus és vállalat-specifikus modellet, ada pusok
● Gyengén- pusos modellek

Communication Protocols (Interaction Patterns)

● Kommunikációs protokollok
○ Kapcsolat képessége a hívókkal és szolgáltatókkal
QoS támogatás (pl.:, reliable delivery, tranzakcionalitás)
○ Interakciós minták támogatása (pl.: request/reply, one-way, pub/sub)
● Tipikus elvárások:
○ HTTP (SOAP/HTTP, XML/HTTP)
○ MQ (SOAP/JMS/MQ, XML/MQ, text/MQ, ...)
○ Adapters (legacy, EIS)
○ WS-I, WS-Security

Basic ESB Pa ern

93
94
Egyéb vizsgakérdések, amelyek nem tartoznak sehová
(nem tudjuk hogy hova a *.?.*!!*-ba valók, csak benne voltak a dia sorban!

vizsgakérdések (Szolgáltatás orientált tervezés – alapok, és legfontosabb szabványok)

1. XSD
2. WSDL
3. SOAP
4. kapcsolataik
5. WSDL előállítási módszerei

vizsgakérdések (Folyamatmodellezés és esettanulmány)

1. Építőelemek és azok absztrakciója

2. SOE modell
3. Ese anulmány – TimeSheet-es példa

vizsgakérdések (SOA kompozíció – irányelvek, szabványok)

1. Alapok
2. Szolgáltatási rétegek meghatározása
3. Használandó alapvető (SOA-) szabványok kiválasztása
4. Szabvány kiterjesztések bevonása a SOA-ba (WS-*)

vizsgakérdések (Szolgáltatás modellezés – irányelvek)

1. Task centrikus szolgáltatások újrafelhasználhatósága, komponálhatósága

2. Folyamat szintű szolgáltatások /emulálás
3. Szolgáltatás funkcionalítás á edések
4. Szolgáltatás granularitás
5. Szolgáltatás autonómia
6. Modellezési szempontok, ellentmondások
7. Modellezés résztvevőinek megválasztása

95
vizsgakérdések (Üzleti folyamatok tervezése – BPEL)

1. BPEL alapok
2. BPEL elemek
a. Process
b. Partnerlinks
c. Partnerlinktype
d. Variables
e. Sequence
f. Invoke
g. Receive
h. Copy
i. Stb…

vizsgakérdések (Szolgáltatás tesztelés – teljesítményparaméterek)

1. Erőforrásfajták
2. „Szűk keresztmetszet” megközelítés
3. Egyszerű elméle modell
4. Válaszidő és Áteresztőképesség karakterisz kák
5. Ese anulmány
a. 4 féle transzformációt alkalmazó logika

EAI def, célok, alapfogalmak

96
EAI definíció:

Az adatok és az üzle folyamatok korlátlan megosztása a vállalatban összekapcsolt

alkalmazások és adat-forrásokon keresztül. (Gartner, szabad fordítás)

EAI célja: Vállala folyamatok összekötése Vállalaton belül vagy vállalatok közö
(intra/inte r organiza onal EAI) Üzle folyamatok egyszer űsítése, automa zálása Már
létez ő rendszerek megváltoztatása nélkül Kés őbbi piaci változásokra való könnyebb
reagálás: rugalmasság biztosításával .

Alkalmazásintegráció kihívásai:

- Különféle Operációs rendszerek,

- Ada árolási megoldások,
- Fejlesztő környezetek,
- Legacy rendszerek (esetleg már support nélkül…)

Integráció Vállala környezetben:

Tipkusan nagyvállala :

Komplex, már meglévő architektúra

Kihívások:

- eltérő interfészek
- eltérő pla ormok
- eltérő kommunikációs protokollok
- eltérő rendelkezésre állás: folyamatos / időszakos / kötegelt feldolgozás
- előre nem látható igények
- előre nem látható igények

Kihívások vállala környezetben – Üzle elvárások:

● Üzle agilitás (nagyfokú rugalmasság):

97
 ○ Reagálás a környeze változásokra (törvényi változások, új ipari
szabványok, konkurensek fenyegetései)
○ Innováció támogatása (versenyelőny gyors termékfejlesztési ciklus révén)
● Szerveze határokon á velő megoldások
● Hatékonyabb működés:
○ Költséghatékonyabb IT
○ Változások gyors végrehajtása
● Hatékonyabb működés

Alkalmazásintegrációs módszertan és technológia szükségessége:

● Kezde ad-hoc kapcsolatok kialakulása:

○ Pont-pont kapcsolatok
○ Sokféle technológia
○ Sokféle integrációs cél (pl. adatmigráció, üzle kollaboráció, új üzle
logika megvalósítása, adat-szinkronizáció, backup, stb..)
○ Eredmény: gyakran n(n-1)/2 ++ darab kezelhetetlen, átláthatatlan,
dokumentálatlan stb. együ m űködési környezet.
● Az integrációra/lehet őségének biztosítására és el őkészítésére/ tudatosan
készülni kell:
○ Már a rendszerek fejlesztése során:
■ Megfelel ő tervezéssel,
■ Megfelel ő fejlesztési módszertan használatával,
■ Megfelel ő fejlesztési környezet (programnyelvek és szabványok)
alkalmazásával,
■ Megfelel ő dokumentálással.

Eredménye EAI alkalmas környezet:

● Integrált ~ konzisztens üzle adatok (Enterprise Informa on Integra on)

● Gyártófüggetlenség (nyílt szabványokon alapuló integráció)

98
 ● Moduláris rendszerfelépítés Egységes front end (felüle integráció – portálok)
● Egységes IT security

Integrációs minták:

● Mediáció:
○ EAI rendszer megfelel ő esemény bekövetkezésekor (event) üzenetet küld
az érinte rendszerek (subscribers) felé (no fica on)
○ Az EAI rendszer csak közve t ő szerepet tölt be
○ Hozzáférési minta (access pa ern): pikusan aszinkron
● Federáció:
○ Minden alkalmazás, mindig az EAI frontend-del kommunikál
○ EAI rendszer ak v résztvev ője/irányítója minden kommunikációnak
(service requestor&provider szerep)
○ Hozzáférési minta (access pa ern): pikusan szinkron
● Egy környezetben a ke ő legtöbbször együ és egyszerre is jelen van.
● EAI eset/„példány” éle artama (life me pa ern):
○ Rövid távú: automa zált tranzakciók melyek néhány másodperc ala
végbemennek
○ Rövid távú: automa zált tranzakciók melyek néhány másodperc ala
végbemennek

Tipkus EAI megoldások/technológiák:

● BUS/Hub – üzetnet kezelő/továbbító rendszer:

○ Tipikus megvalósítása middleware termékekkel mint pl. alkalmazás
szerver, szolgáltatás busz stb.
● Alkalmazás illesztés
○ Megvalósítása adapterekkel (adapters v. connectors)
○ Az adapter tudja, hogy pontosan mit és hogyan kommunikáljon az ado
alkalmazással, vagy annak egy-egy részével.

99
○ Adapterek lehetnek gyártófüggőek – ha speciálisan 1- 1
alkalmazáshoz/funkcióhoz készültek
○ Adapterek lehetnek gyártófüggőek – ha speciálisan 1- 1
alkalmazáshoz/funkcióhoz készültek

100