BILICKI VILMOS: PROGRAMRENDSZEREK FEJLESZTÉSE

rta:

BILICKI VILMOS

PROGRAMRENDSZEREK FEJLESZTSE Egyetemi tananyag

2011

COPYRIGHT: 20112016, Bilicki Vilmos, Szegedi Tudomnyegyetem Termszettudomnyi s

Informatikai Kar Szoftverfejleszts Tanszk

LEKTORLTA: Dr. Charaf Hassan, Budapest Mszaki s Gazdasgtudomnyi Egyetem Automatizlsi s Alkalmazott Informatikai Tanszk

Creative Commons NonCommercial-NoDerivs 3.0 (CC BY-NC-ND 3.0)

A szerz nevnek feltntetse mellett nem kereskedelmi cllal szabadon msolhat, terjeszthet,

megjelentethet s eladhat, de nem mdosthat.

TMOGATS:

Kszlt a TMOP-4.1.2-08/1/A-2009-0008 szm, Tananyagfejleszts mrnk informatikus,

programtervez informatikus s gazdasginformatikus kpzsekhez cm projekt keretben.

ISBN 978-963-279-492-1

KSZLT: a Typotex Kiad gondozsban

FELELS VEZET: Votisky Zsuzsa

AZ ELEKTRONIKUS KIADST ELKSZTETTE: Benk Mrta

KULCSSZAVAK:

kztesrteg, JEE, CDI, EJB, Servlet, ESB, SOA, SCA/SDO, BPEL4WS

SSZEFOGLALS:

A jegyzet egy szles kr ttekintst nyjt az elosztott rendszerek alkalmazsa mgtt ll motivcikrl, az

elosztott viselkedsnl kvethet paradigmkrl s az elosztottsgot elfed szoftver rtegrl. Ezen szles

repertorbl a klaszter s SOA paradigmkon alapul alkalmazs s alkalmazsrendszer fejleszts kpezi a

jegyzet fajslyos rszt. Itt a JEE platform szolgltatsai s a klasszikus 3 rteg architektra mentn

vizsgljuk meg az egyes rtegek szerept, a fellp problmkat illetve megoldsokat. Tllpve az egyes

alkalmazsok hatrait az ESB platform megismerse segtsgvel valstjuk meg a SOA koncepci mentn

elkszl elosztott rendszernket.

Tartalomjegyzk 3

Bilicki Vilmos, SzTE www.tankonyvtar.hu

1. Tartalomjegyzk 1. Tartalomjegyzk ........................................................................................................ 3 I. RSZ BEVEZET ......................................................................................................... 5 2. Bevezet .................................................................................................................... 6 3. Elosztott rendszerek ................................................................................................. 10

3.1. Felmerl problmk........................................................................................ 11 3.2. Elosztott rendszer-architektrk........................................................................ 12 3.3. A SOA-koncepci ............................................................................................ 15 3.4. Virtualizcis szintek ....................................................................................... 18 3.5. sszefoglal ..................................................................................................... 20 3.6. Krdsek .......................................................................................................... 20 3.7. Ajnlott irodalom ............................................................................................. 20

4. tszvd vonatkozsok .......................................................................................... 22 4.1. Kontextusok, ltalnos problmk .................................................................... 22 4.2. Jellemz alkalmazsi terletek.......................................................................... 22 4.3. sszefoglal ..................................................................................................... 27 4.4. Krdsek .......................................................................................................... 28 4.5. Ajnlott irodalom ............................................................................................. 28

5. Kztesrteg .............................................................................................................. 29 5.1. A kztesrteg fogalma, eredete ......................................................................... 29 5.2. A kztesrteg alap tpusai ................................................................................. 30 5.3. A kztesrteg megvalstsa ............................................................................. 31 5.4. A kztesrteg feladatai, lehetsgei .................................................................. 32 5.5. Kztesrteg pldk ........................................................................................... 33 5.6. sszefoglal ..................................................................................................... 35 5.7. Krdsek .......................................................................................................... 35 5.8. Ajnlott irodalom ............................................................................................. 35

II. RSZ NYELVI PARADIGMK, TRENDEK ............................................................ 36 6. Nyelvi paradigmk, trendek - logika megvalstsa ................................................. 37

6.1. Rendszertervezs alapok ................................................................................... 37 6.2. A nyelvi krnyezet melyre pthetnk .............................................................. 38 6.3. A logika modellezse, megvalstsa ................................................................ 40 6.4. sszefoglal ..................................................................................................... 46 6.5. Krdsek .......................................................................................................... 46 6.6. Ajnlott irodalom ............................................................................................. 47

7. Nyelvi paradigmk, trendek - adatkezels................................................................. 48 7.1. Az adatmodellezs fontossga .......................................................................... 48 7.2. Egy j adatmodell ismrvei .............................................................................. 49 7.3. Modellek kztti megfeleltetsek, tjrsok ..................................................... 54 7.4. Krdsek .......................................................................................................... 55 7.5. Ajnlott irodalom ............................................................................................. 56

III. RSZ ALKALMAZS FEJLESZTS....................................................................... 57 8. Felhasznli interakci Megejelentsi rteg ......................................................... 59

8.1. Bevezets ......................................................................................................... 59 8.2. Elvrsok a felletekkel szemben ..................................................................... 59

4 Programrendszerek fejlesztse

www.tankonyvtar.hu Bilicki Vilmos, SzTE

8.3. RIA, Okos kliens .............................................................................................. 60 8.4. Rendelkezsre ll bngsz alap alaptechnolgik ....................................... 60 8.5. Jelenleg rendelkezsre ll absztrakt technolgik ........................................... 66 8.6. Technolgiai kitekints .................................................................................... 79 8.7. sszefoglal .................................................................................................... 80 8.8. Ellenrz krdsek ........................................................................................... 80 8.9. Referencik ...................................................................................................... 80

9. Httrlogika zleti logika rteg ............................................................................ 81 9.1. A Java EE keretrendszer zelti rteg tmogatsa .............................................. 82 9.2. EJB kontner .................................................................................................... 83 9.3. Web Babok ...................................................................................................... 88 9.4. sszegzs ........................................................................................................ 95 9.5. Ellenrz krdsek ........................................................................................... 95 9.6. Referencik ...................................................................................................... 95

10. Adatkezels Perzisztencia rteg ............................................................................. 96 10.1. Bevezets ......................................................................................................... 96 10.2. Hibernate ......................................................................................................... 98 10.3. sszefoglal .................................................................................................. 107 10.4. Ellenrz krdsek ......................................................................................... 107 10.5. Referencik .................................................................................................... 107

IV. RSZ ALKALMAZSRENDSZEREK FEJLESZTSE ......................................... 108 11. Szolgltats-integrci megvalstsa .................................................................... 113

11.1. Webszolgltatsok s a REST specifikci ..................................................... 113 11.2. zenetorientlt tmogats integrcis megvalstsok .................................... 115 11.3. Az OSGi s kapcsolata a SOA vilgval......................................................... 123 11.4. Krdsek ........................................................................................................ 127 11.5. Ajnlott irodalom ........................................................................................... 127

12. Szolgltatsveznyls s koreogrfia...................................................................... 128 12.1. A Business Process Execution Language ........................................................ 129 12.2. A BPEL htrnyai s korltai ......................................................................... 131 12.3. A BPEL kiegsztsei ..................................................................................... 132 12.4. Jvkp - Automatizlt szolgltatsveznyls ................................................ 134 12.5. sszefoglal .................................................................................................. 137 12.6. Krdsek ........................................................................................................ 137 12.7. Ajnlott irodalom ........................................................................................... 138

13. Keresztlvel problmk integrlt rendszerekben ................................................. 139 13.1. Elosztott azonosts s egyszeri bejelentkezs ................................................ 139 13.2. Elosztott jogosultsgellenrzs ....................................................................... 144 13.3. Krdsek ........................................................................................................ 147 13.4. Ajnlott irodalom ........................................................................................... 148 13.5. sszefoglal .................................................................................................. 148

Animcik ..................................................................................................................... 152 brk, animcik jegyzke ............................................................................................ 154

brk ...................................................................................................................... 154 Animcik ................................................................................................................. 155

I. rsz Bevezet 5


I. rsz

Bevezet



2. Bevezet A szoftverfejleszts mint tudomny mr tbb mint 30 ves mltra tekint vissza. Ezen lett alatt a mdszertanok, megkzeltsek, eszkztrak szmos paradigmavltson esetek t. A paradigmavltsok mozgatrugja a legtbb esetben a szoftverfejlesztk produktivitsnak a nvelse volt. A klnbz paradigmk nem felttlenl szekvencilisan, egyrtelmen sorbarendezheten kvetik egymst, hanem inkbb egy fa struktrban brzolhatak. Adott tpus problmra, adott kontextusban a klnbz paradigmk nem nyjtanak azonos teljestmnyt sem a szoftver performancijban, sem a fejlesztk produktivitsban. A szoftverfejlesztknek gy ismernie kell a klnbz paradigmk korltait ahhoz, hogy adott kontextusban legjobban alkalmazhat paradigma mentn valstsk meg a szoftvert.

A szoftverekkel szemben tmasztott nem funkcionlis ms nven rendszerszint kvetelmnyek szintn fejldtek, egyre nagyobb kihvsokat jelentenek. A Julian Browne ltal kivlasztott 15 kvetelmnybl nhny legfontosabb nem funkcionlis kvetelmny:

Rendelkezsre lls: azon id, amely alatt a komponens kpes kielgteni a funkcio-nlis kvetelmnyekben meghatrozott funkcikat azon idhz viszonytva, amikor ezt nem tudja megtenni

Kapacits/sklzhatsg: a komponens a terhels nvekedsvel is kpes elltni a funkcionlis kvetelmnyekben megfogalmazott feladatokat

Prhuzamossg: a komponens tbb, egymssal prhuzamos terhels hatsra is k-pes elltni a funkcionlis kvetelmnyekben megfogalmazott feladatokat

Fejleszthetsg: a komponens j funkcionlis kvetelmnyeket is el tud ltni vi-szonylag szerny fejlesztsi rfordtssal

Egyttmkdsi kpessg: a komponens kpes krnyezetvel s a szksges kompo-nensekkel arnytalan plusz terhels okozsa nlkl is egyttmkdni

Ksleltets: a komponens az adott funkcionlis kvetelmnyben szerepl szolglta-tst adott terhels mellett adott idtartamon bell kiszolglja

Karbantarthatsg: a komponensnek tmogatnia kell az adott szervezetben definilt karbantartsi feladatokat (pl.: biztonsgi ments)

Menedzselhetsg: a komponensnek tmogatnia kell a megfelel konfigurlhatsgi szintet

Monitorozhatsg: a komponensnek monitorozhatnak kell lennie Visszallthatsg: hibs adat esetn a komponensnek tmogatnia kell a megfelel

llapot visszalltst

Biztonsg: a komponensnek a helyi biztonsgi elrsoknak megfelelen kell m-kdnie

Konzisztencia: a komponens az adatot konzisztens llapotban tartja A produktivits nvelst teht ezen kvetelmnyek betartsa mellett kell elrni. Emiatt

nem vletlen, hogy nem csak programozsi nyelvekrl s azok kpessgeirl kell beszl-

2. Bevezet 7


nnk, hanem egyes nyelvekhez kthet vagy fggetlen futtat- s fejleszti krnyezetekrl, amelyek magas szint szolgltatsokkal lehetv teszik ezen nem funkcionlis kvetelm-nyek hatkony, produktv kielgtst. Ezen keretrendszerekbl, megkzeltsmdokbl azonban igen sok van s nehz kzttk eligazodni. (pl. Melyik a jobb a Spring vagy a JEE?) Ahhoz, hogy egy ilyen krdsre vlaszolni tudjunk (ha egyltaln lehet), meg kell is-mernnk azokat az absztrakt kpessgeket amelyeket ezek a fejleszt/futtat krnyezetek nyjtanak a fejlesztknek. (pl. Inversion Of Control vagy bijekci) Ezen kpessgek meg-rtshez viszont az alapoktl clszer kiindulni. Esetnkben ez az gynevezett menedzselt kd. Ilyen a Java s a .NET krnyezet. A menedzselt kd elssorban a memriakezels ki-szervezst jelenti: a programoznak nem kell a memria allokcijval s felszabadts-val foglalkoznia, megteszi ezt helyette a szemtgyjt. Ezen alapszolgltatson tl azonban jval komplexebb szolgltatsok is megjelennek a menedzselt krnyezetben (a tovbbiak-ban a Java krnyezetet rtjk menedzselt krnyezet alatt, a legtbb esetben a meglla-ptsaink igazak a .NET vilgra is). Egy ilyen pldul az alkalmazs-tartomnyok kezelse, amikor a menedzselt krnyezet tveszi az opercis rendszertl az alkalmazsok elklnt-snek a feladatt, s megvalstja azt a szlak szintjn. Az alkalmazs-tartomnyokon bell pedig szerepkr alap hozzfrs-vezrls lehetsges, (amennyiben ezt kln belltjuk s hasznljuk) amely segtsgvel adott kdrszek csak adott szerepkr tulajdonosai futtathat-nak (Java esetn ezt a JAAS API segtsgvel tudjuk elrni). Ezen megoldsok br lta-lnosak, nehezen illeszthetek bele kzvetlenl egy vllalat AAA (Azonosts, Jogosultsg-kezels, Naplzs Authentication, Authorization, Accounting) krnyezetbe. Egy msik fontos alapszolgltats a prhuzamossg tmogatsa. A Java nyelv s a legtbb JVM alkal-mas prhuzamos futtatsra s az alap problmk (zrols, megszakthatatlan kdrsz, stb.) kezelsre, br ez az opercis rendszer kpessgeitl is fgg. Ezzel az eszkztrral azon-ban a programozra hrul a klnbz versenyhelyzetek (holtpontok) kezelse, a prhuza-mos programozs teljes problmakre. Ez az egyik f mozgatrug azon magasabb szint menedzselt krnyezetek (n. vllalati/enterprise krnyezetek) hasznlata mgtt, amelyek elrejtik a prhuzamossg problmit a programoz ell. A tranzakcik tmogatsa teljes mrtkben hinyzik az alap JVM kpessgeibl, ezt is klnbz vllalati krnyezetek biz-tostjk. Az alap nyelv s krnyezet ltal biztostott objektum-orientlt adat- s algoritmus-absztrakci adott mretig megfelel, azonban nem teszi lehetv modulok megfelel meg-fogalmazst, ezen modulok megfelel menedzsmentjt. A sima procedurlis alap logika-megvalstst szintn nem clszer alkalmazni magasabb absztrakcis szinten. Az alkalma-zs menedzselhetsge, tesztelhetsge szintn gyenge lbakon ll. Ezen s mg szmos problma (pl. sklzhatsg, web-alkalmazs, integrlhatsg, stb.) miatt az egyszer me-nedzselt krnyezet nem igazn nyjtja a kvnatos produktivitst azon szoftverfejlsztk rszre, akik a fenti problmkkal szembeslnek. Termszetesen minden problma orvosol-hat sima JVM fltt is, mindent le lehet programozni, a krds a produktivits.

Mint ahogyan mr rtuk a megoldst a klnbz vllalati krnyezetek jelentik. Ezen krnyezetek a menedzselt alapkrnyezet (itt JVM) szolgltatsaira ptve nyjtanak magasabb szint szolgltatsokat. Gyakran nevezik ezeket a krnyezeteket kontnereknek. Kt nagy csoportot klnbztetnk meg: az els csoportba az alkalmazsokat tmogat kontnerek tartoznak. Ezekre az jellemz, hogy egy alkalmazs mkdst tmogatjk akr fizikailag elosztott krnyezetben is (ilyenek pl. a Spring, az EJB, a web kontnerek, rszben az OSGi). A msik az alkalmazs-rendszereket tmogat kontnerek amelyek tbb alkalmazs egyttmkdst tmogatjk (ilyen pl. az ESB, az SCA, rszben az OSGi).



A Java nyelvi krnyezet egyik meghatroz szabvnyost mechanizmusa a Java Community Process (JCP), mely JSR-ek (Java Specification Request) segtsgvel teszi egysgess a klnbz terletek problmit kezel Java API-k s ezeken keresztl a klnbz kontnerek interfszeit, telepts-lerit s az egyb kapcsold, nem szorosan az implementcival sszefgg krdseket. Ezen mechanizmuson tl jelents befolysa van mg a Spring mgtt ll VMware cgnek s az OASIS, valamint az OSGi testletek-nek is. Jegyzetnkben igyeksznk az adott problmnl s az arra adhat megoldsoknl megemlteni a kapcsold szabvnyokat is.

A terjedelmi korltok nem teszik lehetv, hogy egy-egy problmakrt/megoldst olyan rszletessggel ismertessnk, amely az adott megolds hatkony alkalmazshoz szksges lenne. Ehelyett jegyzetnk clja az, hogy bemutassa azokat a problmkat s megoldsokat, amelyekkel a programoz szembesl, amikor egy gynevezett vllalati alkalmazst fejleszt.

Az els hrom fejezet egy szleskr ttekintst nyjt az elosztott rendszerek

alkalmazsa mgtt ll motivcikrl, az elosztott viselkedsnl kvethet paradigmkrl s az elosztottsgot elfed szoftver rtegrl. Ezen szles repertorbl a klaszter s SOA alap elosztott rendszerekre koncentrl a jegyzet. A kvetkez rsz (4., 5. fejezet) a nyelvi paradigmk oldalrl kzelti meg a tmt s felvillantja azokat a lehetsgeket, melyek adott paradigmk alkalmazsval vlnak elrhetv.

1. bra

A jegyzet hromnegyedt kitev 3. s 4. rsz pedig a technolgia szintjre ereszkedve mutatja be azokat a napjainkban hasznlt megoldsokat, keretrendszereket, melyek az alkalmazsok s alkalmazsrendszerek fejlesztse sorn leggyakrabban elkerlnek.

A 2. bra egy tipikus elosztott rendszert szemlltet, mely jl demonstrlja a jegyzet megkzeltst is. Be szeretnnk egyrszt mutatni a sklzhat klaszter alap alkalmazsok fejlesztst (az brn a webshop), msrszt a jegyzet clja a SOA alap rendszerek ele-meinek bemutatsa is. Ez a kpen a klnbz meglv szoftverrendszerek egytteseknt lthat.

2. Bevezet 9


2. bra

A kvetkez fejezetben az elosztott rendszerek absztrakt problmival s az azok elrejtsvel foglalkoz kztesrteggel ismerkednk meg.



3. Elosztott rendszerek Mieltt belekezdennk az elosztott rendszerek problematikjnak s a lehetsges megold-soknak, megoldsi mdszereknek az ismertetsbe, ttekintjk a lehetsges alkalmazs architektrkat, alkalmazs architektra paradigmkat. Ezen architektra mentn tudjuk majd meghatrozni azokat a rtegeket, amelyek az elosztottsgban szerepet kaphatnak.

A legegyszerbb, de a legtbb esetben leginkbb kerlend architektra a monolit. Ezen architektrt nem szabdaljk rtegek, az absztrakci is leginkbb a procedrk (el-jrsok) szintjn valsul meg. Tipikusan egy gpen futtatott egy darab futtahat llomnyt jelent. A monolit s az egyszer procedurlis paradigma utn egy minsgi ugrst jelentett az objektum-orientlt paradigma gy a tervezs, mind a nyelvek terletn. Ez esetben az absztrakcit az objektumok s a kzttk definilhat tartalmazsi, szrmazsi viszonyok kpviselik. Az objektum-orientlt tervezst kt egymstl eltr nzeteket vall iskola hat-rozza meg: a skandinv iskola az adatok reprezentlsra koncentrl elszr (Domain Model), s csak ezutn foglalkozik az adatok viselkedsvel, folyamatokkal. Az amerikai iskola leginkbb a kd jrahasznosthatsgra fkuszl, kevsb a tervezsre. Mivel az ob-jektumok mr megadjk a szoftver alap granularitst ezrt az objektumok/objektum-csoportok mentn mr lehet rtegekrl, modulokrl beszlni. Az absztrakci egy magasabb szintjt adja a komponens-orientlt szoftverfejleszts, amely az objektum-orinetlt para-digma egy termszetes kiterjesztse. Ekkor a tervezs a konkrt zleti funkcik mentn tr-tnik, tipikusan sok objektumot magba foglal komponensek megtervezsvel. Az alap-vet klnbsg a kt megkzelts kztt az, hogy amg az OO tervezs sorn a tervez a konkrt objektumra, annak a val vilgbeli tulajdonsgaira koncentrlva tervezi meg a valsgot legjobban modellez objektumot, addig a komponens-orientlt tervezsnl jval nagyobb granularitsban s gyakran hozott anyagbl, azaz meglv komponensekbl lltjk ssze a rendszert. Egy msik alapvet klnbsg az, hogy az objektum-orientlt tervezsnl nem igazn veszik figyelembe az interakcinl a laza csatols lehetsgt, (pl. tvoli kommunikci vagy aszinkron kommunikci) addig ez a komponens-alap terve-zsnl alapvet fontossg. A komponensek fekete dobozknt szerepelnek, s ellenttben az objektum-orientlt paradigma esetn alkalmazott lthatsgi lehetsgekkel, itt a kom-ponens csakis az ltala biztostott interfszn keresztl rhet el.

Egy tovbbi klnbsg az, hogy a komponens gyakran sajt perzisztencia (tarts adatt-rols) megoldssal is br. A komponens-orientlt paradigma egy magasabb szint absztrak-cija a szolgltats-orientlt paradigma. Mg a komponens-orientlt megkzeltsnl lehetsges volt a kd alap funkcimegoszts is, addig a szolgltats-orientlt megkzel-tsnl a fut kd ltal biztostott szolgltatsok kpezik az alap ptkveket. A komponen-sek szintjn taln, de a szolgltatsok szintjn mindenkppen rdemes foglalkozni kell az elosztottsggal s az ebbl fakad problmkkal, lehetsges megoldsokkal. Jelen fejezet clja az, hogy a szolgltats-orientlt architektrk szintjn megjelen elosztottsggal kap-csolatos problmkat s megoldsmdokat ttekintse.

3. Elosztott rendszerek 11


3.1. Felmerl problmk Leslie Lamport egy igen frappns defincit adott az elosztott rendszerekre:

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable azaz Elosztott rendszer az, ahol egy olyan szmtgp hibja teszi hasznlhatatlann a sajt gpnket, amirl azt sem tudtuk, hogy ltezik.

Egy szabatosabb definci Wolfgang Emmerichtl: Elosztott rendszernek nevezzk az autonm, egymssal hlzaton egyttmkd szmtgpeket, amelyek kzs egyttmk-dsn alapul szolgltatst a felhasznl gy rzkeli, mintha azt egy integrlt eszkz szolgltatta volna.

Mieltt belemerlnnk a rszletekbe, tekintsk t az egyik legfontosabb mozgatrugt, amely az elosztott rendszerek mgtt ll. Ez a sklzds kpessge, azaz hogy kpes legyen nagyobb mennyisg feladatot is elltni akkor, ha jabb erforrsokat tesznk a rendszerbe. Az erforrsokat kt mdon tudjuk sklzni:

Vertiklis sklzs: ekkor egy fizikai gpen vagyunk s ide tesznk jabb pro-cesszorokat, tbb memrit, httrtrat. Ennek a mdszernek az elnye, hogy egy processzen belli alkalmazs maradhat, viszont mint az belthat a behelyezhet erforrsoknak fizikai korltai vannak.

Horizontlis sklzs: ekkor nem a futtat gpet bvtjk, hanem jabb futtat g-peket vonunk be. Ez viszont mr egy elosztott rendszert eredmnyez. Igaz a skl-zdsnak nincsenek korltai (elvileg, a lentiekben ismertetett CAP tzis azrt ad korltokat).

Az elosztott rendszerek kpessgeinek alapvet dimmenziit s ezek korltait a 2000-ben eladott Brewer-fle CAP ttel hatrozza meg. A kpessgek hrom dimmenzija kzl egy-egy konkrt rendszer legfeljebb kt kpessget tud egyszerre megvalstani. Az alap kpessgek az albbiak:

Konzisztenica (Consistency): A hagyomnyos adatbzisok biztostani tudjk, hogy nem konzisztens adat nem kerlhet lementsre (perzisztlsra). Ezen kpessgre az ACID (Atomicits, Konzisztencia, Elklnts s Tartssg) tulajdonsgok megva-lstsval tesznek szert. Amennyiben nem elosztott alkalmazsrl beszlnk, ez minden tovbbi nlkl megtehet.

Rendelkezsre lls (Availablity): A rendelkezsre lls azt jelenti, hogy a rendszer hibatr azaz a szolgltats adott szzalknyi esllyel elrhet. A rendelkezsre llst vilgmret trendszerek esetn csak elosztott rendszerrel lehet megoldani.

Particionils-trs (Partition tolerability): Gilber s Lynch defincija szerint A teljes rendszer (hlzat) hibjn kvl semmilyen hibakombinci sem okozhatja azt, hogy a rendszer hibsan vlaszol. A hibk alatt jellemzen nem szoftveres hibkat, hanem hlzati hibkat (pldul zenetvesztseket) rtnk.

Mint mr emltettk, egy egyetlen gpen fut rendszernl a CAP mint knyszer nem je-lenik meg, mivel ott pldul a particionls nem jelent problmt. Az is igaz viszont, hogy a magas rendelkezsre llst is nehz ilyen architektrval megvalstani, nem beszlve arrl az esetrl, amennyiben nem egy, hanem tbb, a vilgon sztszrt felhasznlt/



/helysznt szeretnnk kiszolglni. Az albbi dntseket hozhatjuk meg (a valsg persze nem binris, ezen kvetelmnyek egy folytonos skln is brzolhatak, mint azt a BASE esetn is ltjuk):

Enyhtnk a particionls trssel kapcsolatos kvetelmnyeken: egy megolds, hogy minden, az adott tranazakci ltal rintett adat egy gpen van, ekkor nem lphet fel a particionls. Ekkor csak a vertiklis sklzs a jrhat t, ez viszont komoly korltokkal br. Pldk: adatbzisok, klaszter alap adatbzisok.

Enyhtnk a rendelkezsre llssal kapcsolatos kvetelmnyeken: az elz ellentte, partci esetn egyszeren megvrjuk, amg az megsznik, s a rendszer megy tovbb. Pldk: elosztott adatbzisok, elosztott zrolsok, tbbsgi protokollok.

Enyhtnk a konzisztencival kapcsolatos kvetelmnyeken: sok esetben az ACID megkzelts nem kritikus, egy kevsb friss adat visszaadsa is megfelel lehet. A konzisztencinak az ACID ltal megvalstott verzijt ers konzisztencinak (strong consistency) nevezzk, ekkor csak a legfrissebb j adat adhat ki. A gyenge konzisztencia (weak consistency) ezzel szemben megenged egy olyan idtartamot (inkonzisztencia-ablak inconsistency window), amikor nem a legfrissebb adat kerl visszaadsra. A vgs fokon konzisztens (eventually consistent) megkzelts a gyenge konzisztenica egy specilis esete, amikor hibamentes mkds esetn az inkonzisztencia-ablakot a rendszer mrete s aktulis llapota (replikk szma, a rendszer terhelse, hlzati ksleltets, stb.) hatrozza meg. Ezen konzisztencia megkzeltst valstja meg a BASE (Basically Available Soft-state Eventually consistent) archtektra. Pldk: Web gyorstrak, DNS.

Mint lthattuk, nincs ingyen ebd, valamilyen kompromisszumot meg kell ktnnk an-nak rdekben, hogy megvalsthassuk a rendszernket. A kvetkez fejezetben ttekintjk az alapvet szinteket, amelyeket egy-egy elosztott rendszer ma szolgltathat.

3.2. Elosztott rendszer-architektrk Az elosztott rendszereket megvalst szoftver-architektrk esszencilis tpusait architek-tra mintaknt szoktk emlegetni. Ezen architektra mintk nem ortogonlisak, azaz pl. egy megolds lehet kliens-szerver s lazn vagy szorosan csatolt egyszerre. A kvetkezkben felsorolt architektra mintk sokszor inkbb kiegsztik mint kizrjk egymst.

3.2.1. Kliens-szerver

A kliens-szerver architektra minta elssorban a szerepkrk alapjn hatrozza meg a rendszerben rsztvev entitsok helyzett. A szerver oldal birtokolja az erforrsokat, mg a kliens oldal hasznlja azokat. Ezen elvek mentn mkdnek napjaink legnpszerbb proto-kolljai (HTTP, SMTP, DNS, stb.). A megkzelts elnyei kz tartozik a knnyebb kar-bantarthatsg, s a kzpontosts miatt elvileg knnyebb biztonsgos rendszert kszteni. A megkzelts htrnya a sklzhatsg s a robosztussg krdse, mivel ez csak a szerver oldalon mlik.



3.2.2. P2P

A kliens szerver architektra ellenttje a P2P architektra, ahol egyenrang vagy nem egyenrang, de az erforrsok megosztsban egyarnt rszt vev entitsok alkotjk a rendszert. Napjaink legnpszerbb VoIP alkalmazsa, a Skype vagy a legtbb fjlcserl protokoll ezen az elven mkdik. Ami viszont kevsb lthat, hogy a ksbbiekben emltett felh architektrk, de mg a klaszter megoldsok alatt is gyakran P2P algorit-musokon alapul replikcis megoldsok vannak. A kliens-szerver megoldssal szemben a htrnya a komplexitsban s elosztottsgban rejlik, viszont cserbe extrm sklz-hatsgot nyjt. (Vegyk szre, hogy ezek nem merleges terletek: a JBoss klaszter alatt lehet P2P gyorsttr, azaz a rendszer egy rsze megvalstja a P2P paradigmt, mg a kiszolglt kliensek HTTP protokollon frnek hozz a tartalomhoz, megvalstva a kliens-szerver paradigmt).

3.2.3. Tbbrteg architektrk

A szerepkrkn tllpve egy msik rendezelv a logika lehetsges szeparlsnak mdja. Erre j plda a 3- vagy tbbrteg architektra. Ez esetben a konkrt erforrs megoszts-nak rszleteit vizsgljuk. Az alkalmazst/rendszert sklzhatsg, robosztussg, menedzsel-hetsg s sok ms szempont miatt is rdemes rtegekre bontani. A leggyakrabban alkal-mazott rtegels a hromrteg architektra, melynl az albbi rtegeket definiljuk:

Megjelents: a trs rendszer fel nyjt interfszt (gyakran ez a felhasznli inter-fsz), s az ehhez kapcsold esemnyeket kezeli le. Ennek a leggyakoribb megva-lstsa a weboldal s az elllt logika.

zleti logika: ezen rteg feladata az zleti folyamatok futtatsa, hossz let tranzakcik kezelse. Itt kerl sor az adatok szlesebb hatkrt, tbb adattpust tlel szablyainak kiknyszertse is.

Perzisztencia: az adatok tarts trolsval foglalkozik. Itt trtnik meg a szkebb hatkrrel rendelkez adatszablyok kiknyszertse s gyakran az objektum s relcis adatmodellek kztti lekpezs is.

A hromrteg architektrt gyakran keverik a megjelentsben hasznlatos MVC (Model-View-Controller) architektrval. Fontos megemlteni, hogy mg az MVC-nl a View s a Controller egyarnt kommunikl a Modellel addig a hrom rteg architektrnl ez nem trtnik meg. A megjelents rteg csak az zleti logikn t rheti el a perzisz-tenict. A hrom rteg jelenti alapesetben azokat a vlasztvonalakat, amelyek mentn a horizontlis sklzs megoldhat. Lehet pldul egy olyan RIA (Rich Internet Application), ahol a megjelents rtegen nagy terhels van de ez az alatta lv rtegekre nem terjed t, mivel hatkony gyorsttrazst alkalmaz. Ekkor a megjelents rteget kell sklzni tbb gp bevonsval, mg az zleti logika s a perzisztencia rteg megmaradhat egy-egy gpen. Amennyiben sklzhatsg, robosztussg vagy egyb szempontok miatt nem elegend a hrom rteg, akkor a hrom rteget jabb rtegekre lehet bontani. Ennek egy gyakori pld-ja, amikor a perzisztenica rteget kt rtegre bontjuk: az egyik az ORM (objektum-relcis lekpezs) ltal megvalstott DAO (Data Access Objects) tervezsi minta mentn meg-valstott rteg, mg alatta a hagyomnyos esetenknt heterogn adatbzis rteg helyez-kedik el.



3.2.4. Szorosan csatolt rendszerek

Egy jabb rendezelv lehet a rendszert alkot modulok csatolsnak mdja. A szorosan csatolt rendszerekben a komponensek (vagy ha ilyenek nincsenek, akkor az osztlyok, objektumok) aszinkron mdon kommuniklnak egymssal, szorosan kvetve a klasszikus fggvnyhvs szemantikjt. Ebbe a kategriba tartoznak a tvoli eljrsokon alapul rendszerek is. A megkzelts elnye az, hogy a rendszer a klasszikus, egy processzen bell is megtallhat interkacis paradigmkra pt, egyszerv tve ezzel a megvalstst. Ezzel a megoldssal viszont nehz robosztus, sklzhat rendszereket ltrehozni.

3.2.5. Lazn csatolt rendszerek

A lazn csatolt rendszerek a szorosan csatolt rendszerekkel ellenttben zenet alap kom-munikcira ptenek s e kommunikci mentn az aszinkron interakci az alaprtelme-zett. Ezen paradigmk mentn jval nehezebb egy rendszert megvalstani, mivel az aszinkronits, tbbutas vgrehajts vgig ott lebeg a fejlesztk szeme eltt, azonban ez a leginkbb jrhat t a robosztus, sklzhat rendszerek megvalstsra. Ebbe a kate-griba tartozik mg az esemnyalap szoftver architektra is (EDA Event Driven Software Arhictecture), mely az esemnyeket tekinti a komponensek kztti interakci alapjainak. Az esemnyek feldolgozsa az albbi kategrikba csoportosthat:

Egyszer esemnyek feldolgozsa: ez esetben egy atomi esemny berkezse indt el egy feldolgozsi folyamatot. Egy plda erre a klnbz felhasznli interakcikat tmogat keretrendszerek esemnykezelse (pl. SWING JSF, stb.)

Esemnyfolyamok feldolgozsa (Event Stream Processing ESP): ez esetben esemnyfolyamokat szrnek egyszer felttelek alapjn, s az rdekes esemnyekre feliratkozott vevknek kldik ki a szrt esemnyeket. Plda lehet erre, amikor a naplzsnl csak adott szintet elr esemnyeket tovbbtunk.

Komplex esemny feldolgozs (Complex Event Processing - CEP): ez esetben a vals idej esemnyfolyamon rtkelnk ki olyan szablyokat, melyek figyelembe vehetik az esemnyek sorrendisgt, bekvetkeztt, szmossgt s szmos egyb tulajdonsgt. Erre a ksbbiekben majd ltunk pldt a Drools-szal kapcsolatban.

3.2.6. Tr alap architektrk (Space Based Architectures - SBA)

A tr alap elosztott architektrk lnyege az, hogy a rendszert olyan egymstl fggetlen egysgekre osztjk, amelyeket tetszleges szmban lehet hozzadni, elrve ezzel a lineris sklzdst. Ezeket az egysgeket feldolgoz egysgeknek (Processing Unit - PU) nevezik, s tipikusan egy olyan szoftver rtegen lnek, amely elrejti ellk az elosztottsg problmit. Ez a rteg a ksbbiekben bvebben kifejtett kztes rteg. Ennek hrom alapvet formja van:

Klaszter alap (Cluster): a feldolgozsra koncentrl, az adattrolsra klnbz tervezsi mintk vannak, a tipikusan olvass jelleg alkalmazsoknl igen j sklzdst tud elrni a CAP kompromisszumai nlkl. Le tudja kezelni az rsi tkzst is. Pldk erre a klnbz alkalmazsszerverek ltal nyjtott klaszterezsi lehetsgek (pl. JBoss Cluster)



Felh alap (Cloud): a CAP paradigma mentn a sklzhat adattrolst is biztostja, tipikusan a konzisztencia rovsra. Plda erre a Google App Engine.

Rcs alap (Grid): fleg a feldolgozsra koncentrl, nincs igazn rsi tkzs, gy a feldolgozs tetszlegesen prhuzamosthat. Ezt leginkbb munkafolyamatok (Job) formjban szoktk megtenni.

Elosztott objektum alap (Distributed Objects): az elosztott objektumok gyakran a fenti architektrk alapjait kpezik. Ekkor egy-egy objektum vagy repliknsa (repliklt objektum replicated object) megjelenik azokon a helyeken, ahol hasznljk, s a httrben egy keretrendszer (kztes rteg) gondoskodik arrl, hogy konzisztens maradjon, vagy pedig egy helyen van trolva (l objektum live object), s azokon a helyszneken, ahol szksges megfelel proxy objektumok kpviselik az objektumot. A megosztott objektumok gyakran objektumterekbe (object spaces) vannak szervezve, melyet valamilyen kztes rteg tart karban, virtualizl (pl. Java Spaces).

A klnbz szoftver-architektrk nem egymst kizrjk, hanem igen gyakran egy-msra plnek. Egy-egy komplex rendszerben szmos szoftver-architektra megtallhat. A kvetkez fejezetekben az elosztott rendszerek megvalstsa mgtt ll legnpszerbb paradigmt, a Szolgltats-orientlt paradigmt (Service Oriented Architecture Para-digm) mutatjuk be.

3.3. A SOA-koncepci A bevezetben mr emltett komponens alap szoftver-architektra egy specilis formja a szolgltats-orientlt architektra, amelyben nem kd, hanem fut kd alap elemekbl lltjuk ssze rendszernket, alkalmazsunkat. Ez esetben nem kell az adott funkcionalits futtat krnyezetvel, menedzsmentjvel foglalkoznunk, ezt megfelel szolgltat vgzi el helyettnk, mi azt csak felhasznljuk. Persze nem ktelez ms ltal futtatott szolgltatst ignybe vennnk, a lnyeg a szolgltats szint ptkezs. Hatkonysgt tekintve a na-gyobb, komplexebb problmk esetben egyrtelm az oszd meg s uralkodj SOA szerinti alkalmazsnak elnye.

3. bra: SOA produktivits



A SOA szmos defincija kzl itt az IBM fle defincit hasznljuk: A szolgltats-orientlt architektra egy keretrendszer, mely segtsgvel az zleti folyamatokat s a tmogat IT infrastruktrt gy tudjuk biztonsgos, szabvnyos szolgltatsok formjban integrlni, hogy az jrahasznlhat s kvetend az zleti ignyeket knnyen megvltoz-tathat

Az elz fejezetben bemutatott szoftver-architektrk kzl a SOA leginkbb laza csatolsra pt:

Az egyes szolgltatsok fekete dobozok, nem ltunk bele a belsejkbe, csak a meghirdetett szolgltatsaikat vehetjk ignybe.

A szolgltatsok elrse lehet szinkron s aszinkron is. zenet vagy metdushvs stlus egyarnt.

A SOA azonban tlmutat a szolgltatsok definilsn s ezek valamilyen szint elr-sn: szmos olyan keresztlvel problma van, amit valamilyen egysges mdon t kell vinni, kezelni kell. A meglv szolgltatsokbl szervezett j szolgltats ltrehozsnl biztostott szervez kpessg (orchestration) segtsgvel lehetv vlik az zleti folya-matok vltozsnak knny kvethetsge. Magas szinten (technolgiai megkzeltsben) a SOA modell az albbi szereplk egyttmkdst definilja:

szolgltatst nyjt entits (szolgltat, service provider): az a szerepl (szmtsi egysg), amely a szolgltats ltal lefedett feladatokat kpes elvgezni.

szolgltatst ignybe vev entits (fogyaszt, service consumer): az a szerepl, amelynek feladata elvgzshez szksge van arra, hogy egy adott szolgltatst ignybe vegyen (egy szolgltattl). Ez a kliens (lehet vkony, vastag s mobil) az utbbi idben a smart client fogalom is forog az irodalomban.

szolgltatst kzvett entits (service broker): az a szerepl, aki ismeri azoknak a szolgltatknak a halmazt, amelyek kpesek egy adott szolgltatst biztostani. Ez egy kztes szerepl, amely bizonyos esetekben kihagyhat a tnyleges kommunik-cis folyamatbl.

kommunikcis csatorna: ez tipikusan webszolgltats, amely a ksbbiekben is-mertetett SOAP protokoll segtsgvel tmogatja a szinkron s aszinkron kommuni-kcit. A klnbz keresztlvel problmk kezelsre pedig a megfelel web-szolgltats profilok biztostanak szabvnyos, mindenki ltal rthet lerst, megva-lstsi tmutatt.

Vegyk szre, hogy ezek a szerepek ebben az esetben is egy adott szolgltatsra vonatkoztatva jelennek meg, teht elkpzelhet, hogy egy A szolgltatst nyjt entits egy msik, B szolgltatsra vonatkozan a szolgltatst ignybe vev entits szerepben van.

Ezek a szereplk az albbi mdon kapcsoldnak egymshoz:



4. bra: SOA szereplk s kapcsolataik

Az brn az albbi hrom interakci jelenik meg az egyes szereplk kztt:

kzzttel (publish): a szolgltat az ltala nyjtott szolgltatsokat a megfelel eszkzkkel lerja, s a szolgltatsok lerst kzzteszi a (kzismert) kzvettnl

keress (search, query): a szolgltatst ignybe venni kvn entits a kzvettt felhasznlhatja arra, hogy az ignyeinek megfelel szolgltatst keressen.

sszekapcsols (interakci): a szolgltatst ignybe vev entits a szolgltats s az azt szolgltat entits adatait ismerve felveszi a kapcsolatot a szolgltatval, s ignybe veszi a szolgltatst. Vegyk szre, hogy a SOA rendszerben jellemzen zenet alap kommunikci trtnik, amelyben a szolgltatst nyjt a szerver, a szolgltatst ignybe vev a kliens.

A SOA alap rendszerek elterjedsekor nagy hangslyt fektettek a kzvettkre, tbb nagy cg mkdtetett kereshet szolgltats-adatbzisokat, amelyeket felhasznlva bn-gszhettnk az ltaluk ismert szolgltatsok s szolgltatk kztt. Az utbbi idben azonban ez kevsb elterjedt mdszer, a kzvettk szerepe cskkent, hiszen a legtbbszr a szolgltatst ignybe vev komponensek fejlesztse sorn pontosan tudjuk, hogy milyen jellemzi vannak az ignybe venni kvnt szolgltatsnak (ez esetben statikus ktsrl be-szlnk, mg abban az esetben, amikor fejleszts sorn nem ismertek az ignybe venni k-vnt szolgltats jellemzi, dinamikus ktsrl van sz). Eltemetni azonban mg korai a hromszg kzvett elemt, hiszen a szemantikus webszolgltatsok fejldsvel jra je-lents szerephez juthatnak. A szemantikus webszolglatsokrl ksbb lesz sz a jegy-zetben.

Ha mr felmerltek a szemantikus webszolgltatsok, akkor rdemes nhny szt ejteni a webszolgltatsokrl, hiszen a jegyzet ksbbi fejezeteiben nagyon gyakran fogunk ezzel a fogalommal tallkozni. A webszolgltats egy azok kzl a technolgik kzl, amik lehetv teszik a SOA-koncepci gyakorlatba trtn tltetst. A webszolgltatsok jel-lemzen (de nem kizrlag) HTTP protokollba gyazva kzleked SOAP zeneteket ta-karnak, hogy ez pontosan mit jelent, azt a ksbbi fejezetekben trgyaljuk. Az albbi brn lthat nhny szabvny technolgia, amely felhasznlhat webszolgltatsok alkalmazsa esetn.



5. bra: Webszolgltats-technolgik

Mivel valamilyen szint webszolgltatsi eszkzkszlet ma mr szinte minden fejlesz-tsi platform alatt rendelkezsre ll, ezrt a webszolgltatsok kitn megoldst jelentenek a platformfggetlen integrcira. Azaz, ha azt szeretnnk, hogy egy szolgltatsunk minl szlesebb fogyaszti kr szmra elrhet legyen, akkor tegyk elrhetv a szolgltatst webszolgltatson keresztl! rdemes azonban figyelembe venni, hogy a haladbb tech-nolgik (WS-Trust, WS-BusinessActivity, stb.) nem minden platformra elrhetk, ezrt ha ezekre szksg van, akkor a megfelel platformot kell vlasztani. A WS-* profilok biz-tostjk a kompatibilitst kztesrteg szinten.

Egyelre elegend megjegyeznnk, hogy ezek a szolgltats-orientlt architektrk alap ptkvei. A ksbbi fejezetek alapjn egy jval teljesebb kp fog kialakulni arrl, hogy mik is azok a webszolgltatsok, hogyan kapcsoldnak egymshoz s milyen halad lehe-tsgeket biztostanak.

3.4. Virtualizcis szintek Az elosztott rendszerekkel kapcsolatos kp teljessge rdekben rdemes ttekinteni a mai felh szolgltatsi szinteket. Ezek a kvetkezek:

szoftver mint szolgltats (Software as a Service, SaaS): ez a legelterjedtebb a ha-sonl szolgltatsok kzl. Gyakorlatilag annyit jelent, hogy a szolgltat nem adja t az elkszlt szoftvert az azt hasznl gyflnek, hanem szolgltatsknt zemel-teti azt. Ilyen mdon lehetv vlik, hogy a hasznlnak ne kelljen telepteni az alkalmazst, ne kelljen az zemeltets nehzsgeivel bajldnia. Ezen fell az is lehetv vlik ilyen mdon, hogy a szoftvert hasznl gyfl annak megfelelen fizessen a szoftverrt, hogy mennyit hasznlja azt tnylegesen. Ez termszetesen bonthat tbbflekppen. Pldul elkpzelhet olyan szoftver, hogy minden funk-cija elrhet, s az gyfl az adott hnapban annak megfelelen fizet, hogy az elr-het funkcik kzl mennyit hasznlt tnylegesen, de elkpzelhet az is, hogy a djfizets alapjt a forgalmazott adat kpezi (az ignybe vett funkcik szmtl fg-getlenl), stb.



Ha jobban belegondolunk, ez a fajta szolgltats elg rgta jelen van az Interneten, gondoljunk csak a Google Mailre vagy brmely ms hasonl cg ilyen jelleg szol-gltatsra.

platform mint szolgltats (Platform as a Service, PaaS): gy nevezzk azt a szol-gltatst, amikor a szolgltat nem egy konkrt szoftvertermket biztost az gyfe-lek szmra, hanem egy olyan szmtsi platformot, amelyre az gyfl kszthet s telepthet sajt szoftvereket. Van olyan PaaS szolgltats, aminek a hasznlathoz szksges az, hogy a biztostott platformon fut alkalmazsok egy megfelel API-hoz legyenek igaztva (pldul adattrolsra csak egy adott, specilis mdon van lehetsg), de ez nem szksges felttele egy PaaS szolgltatsnak.

infrastruktra mint szolgltats (Infrastructure as a Service, IaaS): a platform szint-jhez kpest van lehetsgnk mg alacsonyabb szintben gondolkodni. Ez pedig nem mst eredmnyez, mint olyan szolgltatsokat, amelyekkel a szolgltat vir-tulis infrastruktrt biztost az gyfelei szmra. Ilyenkor az gyfelek szempont-jbl a szolgltats felfoghat egy adott mennyisg szmtgpknt, amelyre br-milyen platformot (s arra a megfelel szoftvereket) telepthet vagy fejleszthet. Az gy elrhet szmtsi egysgek lehetnek virtulis gpek, de elkpzelhet az is, hogy fizikai gpekhez kap hozzfrst az gyfl.

6. bra: Felh-szolgltatsok. Az brn az SaaI helyett IaaS

A megfelel mret infrastrukturlis htteret felhasznl cgek esetn azonban megvan a fenti szolgltatsoknak az az elnye, hogy a szolgltatst ignybe vev gyflnek nem kell rszletes s pontos elzetes becslseket ksztenie arrl, hogy az egyes rendszerkompo-nensek milyen terhelsnek lesznek kitve, mivel az ignybe vett httr biztostja azt a rugal-massgot (elasztikus felh), hogy mindig annyi erforrst biztost, amennyi szksges (s ennek megfelelen kerlnek kiszmtsra a kltsgek is). Ilyen mdon ezek a szolgl-tatsok extrm sklzhatsgot biztostanak.

E szolgltatsokkal kapcsolatban az elnyk mellett egy fontos htrnyt is meg kell em-lteni. Ez pedig az adatvdelem. Az ilyen szolgltatsok esetn ugyanis a szolgltatst ignybe vev gyflnek gyakorlatilag semmilyen rltsa nincs arra, hogy az adatok hol s milyen mdon troldnak s milyen csatornkon keresztl kzvettik azokat. Azoknl az alkalmazsi terleteknl, ahol kiemelten fontos az adatvdelem, ezek a megoldsok nem vagy csak a megfelel korltozsokkal hasznlhatk. A nagyobb IaaS/PaaS szolgltatknak (pl. Amazon, Google, Microsoft) azonban legtbbszr rdekk, hogy nagy s tkeers gy-



feleik is legyenek, emiatt a megfelel szerzdsek mellett elkpzelhet, hogy az ilyen gy-felek esetn az adatvdelmet is megfelel szinten lehet biztostani, illetve lteznek privt felh (private cloud) megoldsok is, amelyek ezt a htrnyt kikszblik. (Nemrgiben volt pldul hr, hogy az Egyeslt llamok kormnyzati szervei egyre inkbb kezdik felismerni a felhben rejl lehetsgeket.)

3.5. sszefoglal Az eddigiek sorn megismerkedhettnk azokkal az alapvet fogalmakkal melyek ma jel-lemzik az elosztott programrendszereket. A kvetkez kt fejezetben bemutatjuk egyrszt azokat az ltalnos a konkrt alkalmazsok funkcionalitsn tlmutat terleteket, amelyek egy-egy elosztott rendszerben j esllyel megjelennek (keresztlvel problmk) s azt a szoftverabsztrakcis rteget, amely az elosztottsgot s ezeket a keresztlvel problmkat megvalstja, sszefogja, szervezi, illetve magt az elosztottsgot elfedi a szoftverfejleszt ell.

3.6. Krdsek 1. Mik a szolgltats-orientlt architektrk legfontosabb elemei, ezek hogyan kapcso-

ldnak egymshoz?

2. Mit neveznk szmtsi felhnek? Milyen tpus szolgltatsokat tesz lehetv? 3. Mik az elosztott rendszerekre vonatkoz legfontosabb kvetelmnyek?

3.7. Ajnlott irodalom Coulouris, G. s msok: Distributed Systems - Concepts and Design. 4. kiads.

Addison-Wesley, 2005. ISBN 0-321-26354-5 Emmerich, W.: Engineering Distributed Objects. Wiley, 2000. ISBN 0-471-98657-7 Estefan, J. A. s msok: Reference Architecture Foundation for Service Oriented

Architecture Version 1.0. OASIS Committee Draft. Elrhet: http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-cd-02.pdf

Ganci, J. s msok: Patterns: SOA Foundation Service Creation Scenario. IBM Redbook, 2006. Elrhet: http://www.redbooks.ibm.com/redbooks/pdfs/sg247240.pdf

Graham, S. s msok: Java alap webszolgltatsok - XML, SOAP, WSDL, UDDI. Kiskapu Knyvkiad, 2002. ISBN 9-639-30104-3.

Hurwitz, J. s msok: SOA for Dummies. Elrhet: ftp://ftp.software.ibm.com/software/solutions/soa/pdfs/SOAforDummies.pdf

Keen, M. s msok: Patterns: Extended Enterprise SOA and Web Services. IBM Redbook, 2006. Elrhet: http://www.redbooks.ibm.com/redbooks/pdfs/sg247135.pdf

MacKenzie, C. M. s msok: Reference Model for Service Oriented Architecture 1.0. OASIS Standard. Elrhet: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf



Papazoglou, M. P. s msok: Service-Oriented Computing Research Roadmap. Service Oriented Computing (SOC), Dagstuhl Seminar Proceedings, 2006. Elrhet: http://drops.dagstuhl.de/opus/volltexte/2006/524/pdf/05462.SWM.Paper.524.pdf



4. tszvd vonatkozsok A nem funkcionlis kvetelmnyek kielgtshez kapcsold programrszeket tszvd vonatkozsoknak nevezik. Ezek bizonyos mrtkig megjelennek minden komponensben gy rdemes ttekinteni azokat a leggyakoribb tszvd vonatkozsokat amelyekkel tallkozhatunk. E rvid ttekints utn a kvetkez fejezetben mr bemutathatjuk azt a rteget (kztesrteg) amely ezen tszvd problmkat tbb kevsbe elfedi a fejleszt ell.

4.1. Kontextusok, ltalnos problmk A legtbb tszvd vonatkozshoz valamilyen adathalmaz tartozik, amelynek az lettar-tama, a rendszeren belli lthatsga jl definilhat. Ezt az adathalmazt sszefoglal n-ven kontextusnak nevezzk. Mint majd ksbb lthatjuk ezen kontexusok nem csak a rendszeradatok, hanem a funkcionlis kvetelmnyeket kiszolgl adatok szervezsre is igen gyakran alkalmazottak. A Web kontnernl pldul 4 klnbz lthatsg s let-tartam kontextust hasznlhatunk (viszony, krs, vlasz, alkalmazs). Ezen kontextusok tvitele egyik komponensbl a msikba, az ezekhez kapcsold protokollok esteleges tmogatsa a web szolgltats profilok legfontosabb feladata. Az albbiakban kt fontosabb kontextust tekintnk t.

4.2. Jellemz alkalmazsi terletek Kvetkezekben kifejtett kontextus a pedig a biztonsgkezels a msik pedig a

tranzakci-kezels lesz. Ezeket jellemzen tmogatjk a npszerbb kztesrteg megva-lstsok s szmos web szolgltats profil is tartozik hozzjuk. Az alfejezetben elszr bemutatjuk a kt emltett terlet jellemz problmit, majd mindkt terleten bemutatjuk azokat a pontokat, amelyek jellemzen rendszereken keresztl velnek.

4.2.1. Biztonsgkezels

Az zleti informci biztonsga minden cg szmra kiemelked jelentsg. Amikor egy-egy rendszert nllan hasznlunk, a biztonsg megvalstsa viszonylag egyszer feladat. Abban a pillanatban viszont, amint ezek a rendszerek egyttesen hasznlva egy nagyobb, elosztott rendszerbe vannak szervezve (kivltkppen, amikor klnbz cgek ltal ze-meltetett rendszerek vannak sszektve) az informci biztonsgos kezelse egszen komplex feladatt vlik. Ebben az esetben az egyes rendszereknek esetleg vals idben kell egymssal kommuniklniuk gy, hogy az zleti tranzakcik egysgessge megmaradjon. Az egyes felhasznlk, csoportok biztonsgi azonostit szinkronizlni kell a klnbz rendszerek kztt, tovbb az zleti adatokat vdeni kell mind trols mind tvitel sorn. ltalban ezeket a feladatokat egyttesen az AAA nvvel illetik (az authentication, authorization, accounting angol szavak kezdbetibl). Biztonsg tmakrben teht az albbi kihvsokra keresnk megfelel megoldsokat:

azonosts (authentikci) s azonossgkezels jogosultsgkezels (authorizci) knyvels (accounting) ltalnos adatvdelem

4. tszvd vonatkozsok 23


Ebben az alfejezetben e terletek jellemz problmit vzoljuk fel.

4.2.1.1. Azonosts s azonossgkezels Azonostsnak nevezzk azt a folyamatot, amely sorn egy felhasznl (ez lehet akr konkrt szemly akr egy szoftverrendszer) azonossga ellenrzsre, megllaptsra kerl. Ez a folyamat ltalban felttelez valamifle elzetes ismeretet a felhasznlkrl (mint pl-dul felhasznlnv-jelsz prok minden felhasznlhoz): azonostt s olyan prbkat, amelyek segtsgvel a felhasznl azonossgt bizonytani lehessen. (Ilyen prba pldul az, hogy Ismeri-e a felhasznl az azonostjhoz tartoz jelszt? vagy hogy Rendel-kezik-e a felhasznl egy megfelel titkos kulccsal?) Amikor egyetlen rendszert haszn-lunk, egy egyszer felhasznlnv-jelsz pros teljes mrtkben elegend lehet a felhasz-nlk azonostshoz, azonban ez a fajta felhasznli azonosts kevsnek bizonyulhat abban az esetben, amikor tbb rendszernek kell egyttmkdnie.

Amikor tbb rendszer mkdik egytt egy feladat sorn, akkor egy megolds lehet az, hogy minden rendszer trolhatja a sajt felhasznlhalmazt s a felhasznlkhoz tartoz prbk jellemzit, ezzel a megoldssal viszont megnehezti az egyes rendszerek kztt az azonostsi adatok tadst. E nehzsg legfbb oka, hogy ezek az nll rendszerek klnbz adatokat hasznlhatnak azonostsra s klnbzek lehetnek az azonostshoz szksges prbk is. Ezltal elfordulhat, hogy ugyanannak a felhasznlnak ms az azonostja kt klnbz rendszerben radsul ms az azonostshoz szksges prba is. Elkpzelhet pldul, hogy egy szmviteli rendszerben Kovcs Jzsef azonostja jkovacs, s az azonosthoz tartoz jelszval tudja bizonytani a szemlyazonossgt. Kovcs Jzsef azonban hozzfrhet egy gyviteli rendszerhez is, amelyben kovacs.jozsef a felhasz-nlneve s egy titkos kulcsfjl tadsa szksges a felhasznli azonostshoz. Ebben az esetben, ha azt akarjuk, hogy a kt rendszer egyttmkdhessen egymssal, akkor ezeket az azonostkat meg kell feleltetnnk egymsnak. Ezt azonost megfeleltetsnek (angolul identity mapping) hvjuk. A felhasznli azonostk megfeleltetse tbbflekppen trtn-het. Amennyiben egy adott rendszer minden egyes felhasznli azonostjhoz meg tudunk adni egy, a msik rendszerben rvnyes felhasznli azonostt, akkor tbb a tbbhz megfeleltetsrl beszlnk.

Elfordulhat azonban, hogy elegend az, ha egy rendszer sszes felhasznljhoz hoz-zrendelnk egyetlen felhasznli azonostt a msik rendszerben. Ilyenkor egy a tbbhz hozzrendelsrl van sz. Nyilvnvalan ebben az esetben elveszik az egyes felhasznlk egyedi szemlyazonossga, azonban bizonyos esetekben ez is elegend, viszont ilyenkor sokkal egyszerbb a megfeleltets.

Azt, hogy klnbz alkalmazsok esetn rdemes ugyanazt az azonostsi mecha-nizmust hasznlni (ha lehet), mr rgen felismertk a cgek, ezrt ltalban gynevezett cmtrakban vannak eltrolva a felhasznli adatok, gy e cmtrak alapjn az sszes alkal-mazott azonosthat az sszes alkalmazs szmra ahelyett, hogy az egyes alkalmazsok-ban egyenknt lennnek nyilvntartva a felhasznlk. Emiatt ltalban az azonostsi tarto-mnyok nem egy-egy alkalmazsra vonatkoznak, hanem legtbbszr az adott vllalatra. Emiatt is rdemes levlasztani a felhasznli azonostkat az alkalmazsokrl. Ez ltalban gy trtnik, hogy valamilyen fderatv azonostsi megoldst hasznlunk, ami a felhasz-nlk fel leggyakrabban egyszeri bejelentkezsknt (single sign-on, SSO) jelenik meg.

Az elzekbl pedig nyilvnvalan kvetkezik, hogy a klnbz rendszerek kztti szolgltatshvsok esetn a krst kezdemnyez (vagy tovbt - a szemlyazonossg-



megfeleltetsi mechanizmusnak megfelelen) felek szemlyazonossgt a szolgltats-hvsokkal egytt tovbbtani szksges ahhoz, hogy a szolgltatst biztost szmtsi egysgek meggyzdhessenek arrl, hogy a szolgltatst kezdemnyez fl jogosult-e az adott szolgltats ignybevtelre.

4.2.1.2. Jogosultsgkezels Jogosultsgellenrzsnek azt a folyamatot nevezzk, amikor megllaptjuk egy felhasznl jogait egy adott rendszerben. Az ellenrzsi folyamat sorn a jogosultsgellenrz alrend-szer eldnti, hogy egy adott felhasznl jogosult-e hozzfrni a megadott mdon a meg-adott erforrshoz (az erforrs itt lehet adat, de lehet mvelet is). ltalban a jogosultsg-ellenrzst hasznljuk arra, hogy az erforrsokhoz rszletes hozzfrs-szablyozst tudjunk megvalstani.

A jogosultsgellenrzs tbbfle mdszer alapjn trtnhet. A jogosultsgellenrzsi sma definilja azokat a szablyokat, amelyek alapjn engedjk vagy tiltjuk a hozzfrst egy adott felhasznl szmra az adott erforrshoz. A f clja a jogosultsgellenrzsnek az, hogy biztostsa az adatok titkossgt (confidentiality) s integritst (integrity). Egy szolgltatsorientlt rendszerben, ahol tbbfle klnbz alkalmazs egyttmkdse eredmnyekppen trtnik komplex feladatok vgrehajtsa, tbbfle jogosultsgellenrzsi sma is szerepet jtszhat, hiszen minden egyes alkalmazs meghatrozhatja a sajt ellenr-zsi smjt. Tovbb ezek az alkalmazsok tbb szinten is ellenrizhetik a jogosultsgokat (mvelet szintjn, adatok szintjn, stb.). Ennlfogva ilyen SOA rendszerek esetn a rend-szerintegrtorok feladata komplex adathozzfrsi szablyok meghatrozsa. Ezek a komplex szablyok egy tfog szablykszletbe foglalhatk, ami biztostja, hogy a szab-lyok megfeleljenek a cg biztonsgi zletszablyzatval.

Elg gyakran elfordulhat olyan eset, hogy egy adott szolgltatshoz val hozzfrsi jogosultsg, valamint a hozzfrs mdja nem kizrlag a szolgltatst ignybevev fl szemlyazonossgn mlik, hanem azon a krnyezeten is, amelyben a szolgltats igny-bevtele trtni (a nap milyen szakaszban vagyunk, a kliens rendszeren adottak-e a megfelel felttelek, ms szolgltatshvs eredmnyekppen adottak-e bizonyos felttelek, stb.) Emiatt ilyen esetekben szksges lehet a szemlyazonossgi informci mellett a biztonsgra vonatkoz egyb adatok tadsai is, esetleg a biztonsgi szablyozs (policy) adott krsre vonatkoz rszei hitelestve.

4.2.1.3. Knyvels Knyvels alatt azt a folyamatot rtjk, amely sorn a felhasznli tevkenysgeket gyjt-jk s troljuk ksbbi feldolgozs cljbl. Ennek tbbfle oka is lehet. A knyvelsi adatokat hasznlhatjuk arra, hogy a felhasznli mveletek letagadhatatlansgt (non-repudiability) biztostsuk. Ez azt jelenti, hogy amennyiben egy felhasznl vgrehajt egy mveletet a rendszerben, annak nyoma legyen, s amennyiben a ksbbiek sorn problma merl fel, ne tagadhassa le az adott mvelet elvgzst. Ebben az esetben passzv vdelem-rl beszlnk, hiszen ilyen esetekben a knyvelsi informci csak akkor kerl felhasz-nlsra, ha valamilyen problma fellpse azt indokoltt teszi.

Heterogn, elosztott rendszerekben, ahol tbbfle alkalmazs tbbfle knyvelst tart nyilvn, a knyvelsi adat gyakorlatilag a teljes rendszerben sztterlve helyezkedik el. Emellett ezek az alkalmazsok ltalban valamilyen sajt formtumot hasznlnak a knyve-



lsi informci trolsra. Ezen elosztott, tbbfle formtumot hasznl knyvelsi adat-bzis kezelse nem egyszer feladat.

A knyvelst ezek miatt tekinthetjk keresztlvel problmnak, azonban a knyvelsi adatok hozzcsatolsa az a szolgltatshvsokhoz s az ezekre adott vlaszokhoz ltalban nem jellemz, hiszen a legtbb rendszer sajt hatskrben vgzi a knyvelst. Elkpzel-het azonban olyan eset, hogy a szolgltatskrs vagy a r adott vlasz tartalmaz a msik fl szmra a knyvelsre vonatkoz javaslatot, informcit.

4.2.1.4. Adatvdelem Az AAA-hoz tartoz megfontolsok mellett tovbbi szempontokat is rdemes figyelembe venni, amikor az adatok biztonsgt kvnjuk biztostani. Ilyen pldul az adatok vdelme hlzati adattvitel sorn (ha jl meggondoljuk, elkpzelhet, hogy egy felhasznl megfe-lelen azonostja magt, van is jogosultsga a rendszerben a megadott informci megszer-zsre, s a hozzfrs tnyt a rendszer megfelelen le is knyveli, de az egsz biztonsgi rendszer haszontalan, ha az adatokhoz az adattviteli csatorna vdtelensge miatt tvitel sorn illetktelenek is hozzfrhetnek).

Ahhoz, hogy az adatok tvitele biztonsgos legyen, az tvitelig kzeget is biztostanunk kell. Egy titkostott tviteli kzeg nagyon meg tudja nehezteni az illetktelenek dolgt, ha hozz szeretnnek frni az tvitt adathoz. sszessgben elmondhat, hogy az adatok titkossgt s integritst, valamint az adatklds (s fogads) tnynek letagadhatatlan-sgt biztostani kell az tvitel sorn is. Ezeket jellemzen titkostott adattviteli rtegekkel, illetve digitlis alrssal s titkostssal szoks megoldani.

4.2.1.5. Keresztlvel biztonsgi problmk Amint azt ebben az alfejezetben lthattuk, az informcibiztonsg tmakrben szmos olyan rszterlet van, amely elosztott rendszerek esetn vlik igazn jelentss. A teljessg ignye nlkl ilyen rszterletek teht:

mveletvgzst felhasznl kiltnek (s felhasznli adatainak) tovbbtsa felhasznli jogosultsgok kezelsnek sszehangolsa, teljes rendszerre vonatkoz

biztonsgi elrsok kialaktsa s betartatsa

knyvelsi informci tvitele rendszerek kztt rendszerek kztti informcicsere vdelme (titkossg, integrits, letagadhatatlan-

sg biztostsa)

kd alap biztonsg E fejezetnek nem clja bemutatni az e terletekre vonatkoz konkrt megoldsokat,

azok egy rszvel a ksbbi fejezetekben tallkozhatunk (pl. WS-Security, fderatv szemlyazonossg-kezels, SSO).

4.2.2. Tranzakci-kezels

Az adatok biztonsgval kapcsolatosan egy olyan fontos problma is felmerl, ami mr nll terlett forrta ki magt, ez pedig az adatintegrits biztostsa. Amikor mdostst vgznk az adatainkon, fontos, hogy minden egyes mveletvgzs utn az adathalmaz n-magval konzisztens llapotban legyen. Az adatintegrits megrzsnek rdekben vtize-



dek ta hasznlnak tranzakcikat, ezltal lehetsgess vlik, hogy az sszetett adatmdo-stsi mveletek sorn minden esetben konzisztens llapotban maradjon az adathalmazunk. Klasszikusan a tranzakci-kezels problmakre az adatbzis rendszerekhez kapcsoldik, azonban az vek sorn magasabb szinten is szksges volt bevezetni a tranzakcikat s megfelelen mdostani az ide kapcsold fogalmakat, mdszereket.

A modern elosztott alkalmazsokban sokszor elfordul ugyanis, hogy egy adathalmaz nem kerl azonnal trolsra egy megfelel adatbzisban, tovbb elosztott rendszerek esetn a mveletvgzs sem felttlenl ugyanazon az eszkzn trtnik. E jelensgek miatt szksg van arra, hogy elosztott krnyezetben is tudjunk tranzakcikat hasznlni, mgpedig az elosztottsgot, mint fontos tnyezt figyelembe vve. Ezt csak gy tudjuk elrni, ha az egyes szolgltatsok nemcsak azt az adatot kapjk meg, amin mveletet kell vgeznik, hanem azt az informcit is, hogy az adathoz milyen tranzakcis krnyezet tartozik.

7. bra: Tbb rendszeren tvel tranzakci (plda)

Egy erre vonatkoz pldt mutat be a 7. bra, amely egy elkpzelt utazs-elksztsi folyamatot tartalmaz. Egy olyan munkafolyamatot lthatunk az brn, amely 3 klnbz szolgltat 3 klnbz szolgltatst rinti. A plda felttelezi azt az elzetesen ismert kvetelmnyt, hogy a teljes munkafolyamatot egy tranzakciknt kell kezelni, azaz csak akkor tekinthet sikeresnek a munkafolyamat vgrehajtsa, ha mind a repljegy foglalsa, mind a szllodaszoba foglalsa, mind pedig a gpkocsi foglalsa feladat sikeresen elvg-zsre kerlt, mert az illet, akinek a szmra vgezzk a foglalsokat, kizrlag az sszes felttel egyttes teljeslse esetn kpes a munkjt megfelelen elvgezni. Amennyiben valamelyik feladat sikertelenl hajtdik vgre (pl. nincs szabad szllodaszoba az adott idszakra), akkor a teljes tranzakcit vissza kell vonni (repljegy foglalssal s gpkocsi foglalssal egytt). A teljes problmt bonyoltja, hogy az egyes foglalsok is lehetnek sszetett mveletek, amiket nll tranzakciknt kell vgrehajtani. Ebben az esetben teht van 3 olyan tranzakcink, ami egy-egy szolgltatt rint, valamint egy negyedik, amely az sszes szolgltatt rinti.

Az ilyen jelleg feladatok megoldsra talltk ki az gynevezett ktfzis commit mdszert, ami lehetv teszi, hogy az egyes tranzakciknak a j tulajdonsgai megma-radjanak. A 8. bra s a 9. bra mutatja be problma megoldst ktfzis commit felhasz-nlsval.



8. bra: Ktfzis commit (minden rendben eset)

9. bra: Ktfzis commit (hiba a szllodaszoba foglalsa kzben eset)

Az elosztott tranzakci-kezels esetn teht a klnbz rendszerek kztt a szolglta-ts krshez s a r adott vlaszokhoz csatolni kell azt az informcit, hogy milyen tranzak-cis krnyezetben trtnik a mveletvgzs. Az ilyen tranzakcis informci is jellemzen olyan, amit kontextus adatknt kivlan lehet kezelni, s termszetesen addnak a meg-felel (tranzakcis) hatkrk is.

4.3. sszefoglal A fejezetben kifejtett kt plda (biztonsg- s tranzakci-kezels) jl mutatja az ignyt a klnbz szolgltatsok esetn a krsekhez s rjuk adott vlaszokhoz csatolhat infor-mci lehetsgre. Ez azonban csak kt olyan keresztlvel problmakr, ahol a kontex-tusok (s a hozzjuk tartoz hatkrk) alkalmazsa hozzsegt egyes rszfeladatok hat-kony s elegns megoldshoz. Kis jrtassggal s megfelelen rugalmas eszkzkszlettel tovbbi keresztlvel (s egyb) problmkra vonatkozan sajt magunk is kialakthatunk az elzekhez hasonl kontextusokat s akr hatkrket is, amelyeket a szksgeknek megfelelen az adott alkalmazsi terlethez igazthatunk. A kontextusok hatkony segts-



gben a kztesrteg megoldsok hathats segtsget nyjtanak. Nhny lehetsggel gya-korlati szempontbl is fogunk tallkozni a jegyzet htralv fejezeteiben.

4.4. Krdsek 1. Milyen problmk jelentkeznek az elosztott felhasznl-azonosts terletn? 2. Milyen problmk jelentkeznek az elosztott jogosultsgkezels terletn? 3. Milyen problmk jelentkeznek az elosztott knyvels terletn? 4. Milyen problmk jelentkeznek az adatok vdelmnek terletn elosztott rendsze-

rekben? 5. Milyen problmk lpnek fel, ha tbb rendszeren keresztl vel tranzakci-kezelst

akarunk megvalstani? 6. Mire j a ktfzis commit (2PC) mdszer, s hogyan ad megoldst a problmra?

4.5. Ajnlott irodalom Bernstein, P. A. s msok: Concurrency Control and Recovery in Database

Systems. Microsoft Research, 1987. Elrhet: http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx

Buecker, A. s msok: Understanding SOA Security Design and Implementation. IBM Redbook, 2007. Elrhet: http://www.redbooks.ibm.com/redbooks/pdfs/sg247310.pdf

Feingold, M. s msok: Web Services Business Activity Framework (WS-BusinessActivity). 2005. Elrhet: http://public.dhe.ibm.com/software/dw/specs/ws-tx/WS-BusinessActivity.pdf

Feingold, M. s msok: Web Services Atomic Transaction (WS-AtomicTransaction). 2005. Elrhet: http://public.dhe.ibm.com/software/dw/specs/ws-tx/WS-AtomicTransaction.pdf

Little, M. C. s msok: Java Transaction Processing: Design and Implementation. Prentice Hall, 2004. ISBN 0-130-35290-X

Little, M. C.: A History of Extended Transactions. InfoQ, 2006. Elrhet: http://www.infoq.com/articles/History-of-Extended-Transactions

Nadalin, A. s msok: Web Services Security: SOAP Message Security 1.0. OASIS Standard, 2004. Elrhet: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

5. Kztesrteg 29


5. Kztesrteg Az elz fejezeteken lthattuk, hogy a fejlesztknek szmos olyan nem funkcionlis rendszer szint kvetelmnnyel is foglalkoznia kell, amelyek specilis tudst ignyelnek. Nem igazn vrhatjuk el egy egyszer webes szoftver fejlesztjtl, hogy mestere legyen a hibatr rendszerek tervezsnek az egyszer zenetvesztsek kezelstl (az zenetek el-veszhetnek, kshetnek, mi a rendszer akutlis llapota, ha tetszleges ksleltetsek, zenet-vesztsek lehetnek egy csatornn?) egszen a kauzalits, vagy a biznci tpus (amikor egy kommunikl csoportban ahol szavazsos konszenzust akarunk elrni valakik tetszlegesen szablytalanul mkdhetnek) hibk kezelsig. A klasszikus opercis rendszerek nem nyjtanak megoldsokat e problmk kezelsre. A kpessgeik kimerlnek a nyers hl-zati kapcsolatok (UDP/TCP) s a processzek megfelel kezelsben. Szksg van teht egy rtegre az opercis rendszer s az alkalmazs kztt, ami ezeket a problmkat megfelel absztrakcis szintre emeli annak rdekben, hogy a programoz tlssa, s tudjon valamit kezdeni vele. Mint majd ltjuk ez nem felttlenul a futtat krnyezet (runtime), hanem egy attl esetenknt fggetlen rteg, amit kztesrtegnek (middleware) neveznk.

5.1. A kztesrteg fogalma, eredete A kztesrteg (middleware) mint olyan elszr egy 1968-as konferencin jelent meg. A rteg bevezetsnek clja a klnbz fjlrendszerek szemantikjnak s szintaktikjnak elrejtse volt az alkalmazs ell. A kztesrteg helye napjainkban az opercis rendszer s az alkalmazs kztt tallhat, de funkcionalitsa/fkusza jelentsen mdosult.

10. bra: A kztesrteg helye egy elosztott rendszerben

A kztesrteg feladatt ma sokan a klnbz alkalmazsok egyttmkdsnek else-gtsben ltjk, ms tartomnyban a kztesrteg a sklzhatsg, elosztottsg problmit fedi el a fejleszt ell. Abban taln egyetrtenek a klnbz irnyok kpviseli, hogy a kztesrteg egy magasabb absztrakcis szint segtsgvel segt az elosztottsg megfelel kezelsben (legyen ezt a heterogenits, mint dimmenzi, vagy a lokci, mint dimmenzi). Ezzel a defincival el tudjuk vlasztani attl a futtat krnyezettl (runtime environ-ment) amely egy hjat ad a program kr, amin keresztl klnbz nem csak elosztottsg-gal kapcsolatos problmkra magasszint eszkztrat nyjt. A JVM mint olyan teht egy fut-tat krnyezet, de nem kztesrteg mivel maga a JVM csak lehetsget ad az elosztottsg kezel keretrendszer beillesztsre de megoldst nem. Az EJB kontner viszont mr kz-tesrtegnek nevezhet mivel lehetsget ad szmos kztesrteg szolgltats hasznlatra.



11. bra: A JVM mint futtat krnyezet

A kztesrteg, mint lttuk tbb dimmenzi mentn tbb paradigm mentn ad egy maga-sabb absztrakcis szintet az elosztottsg kezelsre. A kvetkez fejezetben ttekintjk azo-kat az alapvet paradigmkat, amelyek mentn egy kztesrteg szolgltatsokat nyjthat.

5.2. A kztesrteg alap tpusai A kztesrteg egyes tpusai a konkrt megvalstsoknl nincsenek ilyen atomi szinten el-klntve mivel ezeket egytt rdemes alkalmazni. Itt az egyes paradigmkat rjuk le:

zenetorientlt Kztesrteg (Message Oriented Middleware): Segtsgvel ze-net alap kommunikci valsulhat meg. Az alapvet absztrakcii a csatornk, for-rsok, elfizetk s az zenetek. Pont-Pont, Pont-Tbb Pont kommunikcis para-digmkat egyarnt megvalsthatunk vele. Alapveten aszinkron kommunikcit valst meg, azaz egy zenet elmegy, akkor a program futhat, tovbb nem vrja meg a vlaszt. Az zenetek viszik t a klnbz kontextusokhoz tartoz szolgltatso-kat, a legtbb megvalstsban ez valamennyire automatizlt (pl.: az zenet kldje megfelel mdon tkerl a fogad oldalra is s ott az zenet kezelse megfelel jogosultsggal zajlik le.)

Csoportkommunikci Kztesrteg (Group Communication Middleware): Br ez is zenet kommunikcin alapul kommunikcit valst meg a cl gyakran j-val sszetettebb mint a sima zenetkldsnl. Olyan primitveket tmogathat, ame-lyek segtsgvel pldul megvalsthat az elosztott konzisztenica (pl.: szavazs alap tbbsgi dnts). Ezen kztesrteg tipikusan nincs kiajnlva a fejlesztnek, hanem valahol mlyebb rtegekben jelenik meg (egy plda erre a JBoss JGroups ami a klaszter alapja, vagy a Google elosztott zrolst megvalst rtege ami a BigTable alapja).

Objektum Kztesrteg (Object Oriented Middleware): Segtsgvel az objektum orientlt szintaktika s szemantika megtartsval virtualizlhat a konkrt futtats helye. Megoldja teht az objektumok fellelst, az esetleges repliklsbl ered konzisztencia problmkat s a tvoli metdushvs problematikjt. A Corba s a klasszikus JEE idejn lte fnykort, amikor az elkpzels az volt, hogy a kztes-rteg a terhels vagy egyb metrika figyelembevtelvel tetszlegesen helyezget-heti, az objektumokat ez nem zavarja a rendszert. Ma is megtallhat ez a szolglta-ts az elosztott gyorst trakban de a teljestmnybeli ignye miatt megfontoltan kell hasznlni.

Tvoli Eljrs Kztesrteg (Remote Procedura Call Based Middleware): Az elz paradigma alap ptkve. A tvoli eljrs hvs transzparens megvalstsra koncentrl. Ez azonban a gyakorlatban nem igazn valsul meg mivel a tvoli elj-

5. Kztesrteg 31


rshvsban kldtt s kapott objektumok tipikusan rtk s nem referencia szerint addnak t. Erre a programoznak oda kell figyelnie. Alapvet absztrakcii a csonk, amely a hv oldalon elfedi a tvoli objektumot s a vz amely a tvoli objektumnl elfedi a hv objektumot.

Adatbzis Kztesrteg (Database Based Middleware): Feladata a klnbz adatbzis kezelk sajtossgainak elfedse az alkalmazs ell. Sokan ezt nem tartjk kztesrtegnek. A JDBC pldul ezt valstja meg.

Tranzakci-Kezel Kztesrteg (Transaction Processing Middleware): A feladata az erforrsok konzisztens llapotba tartsa tranzakci-kezels tmogat-sval. Az erforrsok tipikusan adatbzisok, de lehetnek ms adattrak is (pl.: fjlok). Az ACID tulajdonsgok biztostsra az erforrs kezelk (pl.: adatbzis) a tranzakci kezelk segtsgvel ktfzis (vagy egyb tpus) tranzakcikat tud-nak vgrehajtani. Ezen rendszerek az zenet orientlt kztesrtegekkel egytt rgta a robosztus infrastruktra alapjait kpviselik.

Portl Kztesrteg (Portal Middleware): Ez egy j kategria feladata szemben az elzekkel ahol tipikusan a httr rendszerek (back-end) voltak valamilyen m-don integrlva az eltt rendszer (front-end) integrlsa. A portlok lehetsget adnak az egyes ms-ms helyrl szrmat GUI elemek integrlt egy felletben trtn integrlsra, gy, hogy kzben kln kontextust biztostanak a portl szintjn lehetv tve a portlon megjelen elemek interakcijt. Alapvet absztrak-ci a portlet amely vagy tvol, vagy a portlon fut s ez fr hozz a portl kontex-tushoz (pl.: felhasznl azonossga, ).

Felh kztesrteg (Cloud Middleware): E rteg feladata az elz fejezetekben emltett CAP kritriumok valamilyen prostsnak megvalstsa. Erre a kztesrtegre a nagyon nagyfok sklzhatsg a jellemz nagyon nagy adat-mennyisgek mellett. Egy plda erre az Amazon Dynamo kztesrtege amely egy lapos nv rtk trat biztost.

5.3. A kztesrteg megvalstsa Maga a kztesrteg lehet implicit vagy explicit. Az explicit kztesrteg egy olyan absztrakt programozi interfszt ad, amit a programoznak kell explicit mdon hvogatnia amikor a szolgltatsait ignybe szeretn venni. Az implicit kztesrteg hasonl szolgl-tatsokat nyjthat mint az explicit csak ez esetben a programoznak csak a sajt zleti logikjnak megvalstsval foglalkozik s nem vesz tudomst a kztesrtegrl mert ez szmra lthatatlan. A szolgltatsokat nem API hvsokkal .n.: kzi vezrlssel veszi ignybe, hanem automatikusan a szksges ponton a keretrendszer ezt az alkalmazs logika rszve varzsolja. Ezen varzsls majd ksbb ltni fogjuk, megtrtnhet interceptorok-kal, IoC kontnerekkel, de Aspektus Orientlt megoldsokkal is.

Egy kztesrteg-szabvny a Java EE, ami nem egy konkrt kztesrteget definil, hanem pontosan azt a modellt s felletet, amibe bele tudjuk illeszteni az alkalmazsainkat, szolgltatsainkat. A szabvny tovbb ajnlsokat fogalmaz meg a konkrt kztesrteg-implementcikra vonatkozan, de egy sereg dolgot nem szablyoz. Az ilyen nem szab-lyozott dolgokat a kztesrteg gyrti gy valstjk meg, ahogyan jnak ltjk. A Java EE szabvny ltal definilt magas szint modellt lthatjuk az albbi brn:



12. bra

A JavaEE modell egyes elemeivel gyakran fogunk tallkozni a jegyzet htralv feje-zeteiben.

5.4. A kztesrteg feladatai, lehetsgei A fentiekbl kvetkezik, hogy egy megfelel kztesrteg rengeteg terhet levesz a fejlesztk vllrl, s az elosztott alkalmazsaink kevesebb hibval rendelkez s szabvnyos meg-oldsokat hasznlhatnak ilyen mdon. A kztesrteg jsgt az ltala biztostott transz-parencia kpessgekkel s ezek mrtkvel mrhetjk. Az ANSA 1989, ISO/IEC 1996 International Standard on Open Distributed Processing testlet foglalta ssze ezeket a transzparencia tulajdonsgokat az albbi csoportokba:

helyszn ttetszsg: nem lehet megllaptani azt, hogy akivel kommuniklunk hol van. Transzparens a msik entits (pl.: objektum) elhelyezkedse. Ilyen kpessget ad rszben pl. az RMI (a referencik kezelsben nem tudja teljes mrtkben kielgteni ezt a kvetelmnyt).

hozzfrs ttetszsg: ugyanolyan szintaktikval, szemantikval rjk el a helyi s a tvoli erforrsokat is. (ez gyengbb, mint az elz mert pl. az RMI esetn ugyanaz az interfsz, de attl fggen, hogy a tvoli objektum exportlt-e vagy sem mshogy mkdnek a referencik)

replikci ttetszsg: adott erforrs tbb helyen is megtallhat, nem lehet megllaptani, hogy mikor melyik replikval kommuniklunk. (Ezt nyjtja a klasz-terezs, amikor az objektumok memriabli llapott is repliklja)

hiba ttetszsg: a bekvetkezett hibk nincsenek kihatssal a rendszer mkdsre (ez alacsony szinten lehet pl.: TCP, magasabb szinten megfelel kivtelkezels)

5. Kztesrteg 33


prhuzamossg ttetszsg: az erforrsokat tbben is hasznljk egy idben egy-mstl fggetlenl. Ezt a klasszikus java stack esetn szl kezelssel lehet meg-oldani. J2EE esetn ez pl.: a kontner dolga (hogyan kezeli a viszony babokat, ...)

migrci ttetszsg: adott komponens tetszleges mozgathat a klnbz futtat krnyeztek kztt. Ez volt a J2EE egyik clkitzse amit nem igazn tudott megvalstani, a felh vagy rcs infrastruktra valamilyen mrtkben megvalstja ezt (megfelel granuralits esetn).

teljestmny ttetszsg: a kztesrteg automatikusan sklzdik. Amennyiben tbb erforrsra van szksg akkor tbbet allokl. Ezt ma leginkbb a felh megol-dsok tudjk produklni. Ott is leginkbb az IaaS esetn (pl.: a Google PaaS renge-teg olyan nem dokumentlt limit rtkkel rendelkezik ami nem teszi lehetv a sk-lzst)

programozsi nyelv ttetszsg: a kztesrteg ugyanazt nyjtja a klnbz prog-ramozsi nyelveknek s kzttk hidat kpez. Erre egy j plda a .NET platform s a hozz kapcsold keretrendszerek.

A kvetkez fejezetben nhny ismertebb kztesrteget tekintnk t s helyezzk azt el a szolgltatstrkpen.

5.5. Kztesrteg pldk Az elz fejezetekben felsorolt paradigmkohoz illeszked azokat megvalst, legismer-tebb kztesrtegeket tekintjk t ebben a fejezetben. A JEE-vel kapcsolatos kztesrte-gekkel s az ESB-vel ksbb jval rszletesebben is megismerkednk.

5.5.1. JGroups

A JGroups egy klasszikus csoportkommunikcis kztesrteg megvalsts, amely kihasz-nlva a hlzat kpessgeit is (pl.: multicast) klnbz kpessg csoportkommunikcis megoldsokat biztost. A JGroups kpezi a JBoss EJB s JBoss Web trol klasztere-zsnek alapjt is. Alapveten a csoportok kezelst biztostja, de a csoportkommunikcit alkot zenetkezelsnl szmos megbzhatsgi szintet tud megvalstani (Atomi, FIFO, Kauzlis, Teljes Sorrend). Ezt TCP/UDP mellett JMS ignybevtelvel is biztostani tudja. Alapvet elemei a csatorna s a csatorna alatt lv protokoll halmaz. Egy-egy csatorna je-lenti azt a virtulis mdiumot amelyen keresztl a sima kommunikcin tl olyan absztrakt elosztott az alatta lv protokollok ltal biztostott szolgltatsok is elrhetek mint az elosztott zrols, tbbsgi szavazs Ezekkel mint mr rtuk a programoz ritkn tall-kozik mert elfedi ezt pldul az elosztott objektum gyorstr (pl.: Infinity) vagy az elosztott objektum cmtr (pl.: JNDI).

5.5.2. JEE Web Trol

A Web Trol (Web Container) a JEE ltal specifiklt legnpszerbb trol, nem vletlen, hogy a GWT is ezt ajnlja mint futtat krnyezetet. Alapveten egy futtatsi krnyezetet biztost a http krsek lekezelsre. Ezen fell bizonyos mrtkig lekezeli a prhuzamos-sggal kapcsolatos problmkat az adatbzis rtegre tmaszkodva. Amirt kztesrtegknt itt szerepel az az, hogy van klaszter szolgltatsa is amelyben pldul a viszony kon-



textusban trolt adatokat konzisztens mdon egy vagy tbb helyre repliklja lehetv tve ezzel a robosztus rendszerek kialaktst. Mint mr rtuk e szolgltats mgtt a JGroups ll (a JBoss megvalsts esetn, ms megvalsts pl.: IBM WebSphere ms csoportkommu-nikcis megvalstst hasznl)

5.5.3. JEE EJB Trol

Az EJB trol rtelmt gyakran megkrdjelezik megemltve azt, hogy elegend a Web trol is a szolgltats rteg (vagy zleti logika) megvalstsra. Ez egyszer alkalmazs esetn lehet, hogy gy van de olyan komplexebb alkalmazsnl ahol a tranzakcik tbb adatbzis kapcsolaton is tlnylnak s nem adatbzis hanem Java kd szinten kellene ezeket vgrehajtani az EJB kontner kikerlhetetlen. Hasonl a biztonsg is: amikor rszle-tes esetleg metdus szint jogosultsgkezelst szeretnnk akkor szintn az EJB trolt cl-szer hasznlnunk. A klnbz babok ltal biztostott absztrakcik, amelyekkel szinkron vagy aszinkron kommunikcit tudunk megvalstani ismt az EJB-t ignyelnek. Amennyi-ben komponens orientlt fejlesztst szeretnnk ismt az EJB kontner adja meg hozz a megfelel kereteket (komponensek definilsa, monitorozsa, menedzselse, ). A web kontnerhez hasonlan itt is tudunk klaszterezni, de ezen tl tmogatva van az zenet orientlt, objektum s tvoli eljrs kztesrteg paradigmk megvalstsa is.

5.5.4. Google AppEngine

A share nothing (csak adatbzis szinten van szinkronizc) elvt kvetve autonm elemekbl ptkezik (amit mr lttunk a tr alap architektrban a PU Processing Unit absztrakcit), ahol a konzisztencia, llapotok szinkronizcija a Bigtable feladata amely a CAP kritriumok BASE permutcijt valstja meg, azaz partcitr s magas rendel-kezsre lls a konziszetnica rvid tv krra. Maga a mr emltett feldolgoz egysg (processing unit) a web kontner ltal definilt futtat krnyezetre pthet, ez alatt pedig a Java virtulis gpre. Egy-egy ilyen web alkalmazs kpezi a terhelseloszts alapjt. A Google kztesrteg ezen web alkalmazsokat helyezi el annyi virtulis gpre amennyi szksges. Ezen web alkalmazsok kztt a konzisztencit a felh adattr Google imple-mentcija a BigTable valstja meg.

5.5.5. ESB

Az elzekben ltott kztesrtegek alapveten az alkalmazsok kiszolglsra lettek megter-vezve. Az ESB s az SCA alkalmazs rendszerek kiszolglst valstjk meg. Az ESB Vllalati Szolgltats Busz (Enterprise Service Bus -ESB) mint ahogy a nevben is benne van egy busz absztrakcis segtsgvel valstja meg a klnbz rendszerek kztti kommunikcit. Az ESB tekinthet a SOA egyfajta megvalstsnak is. A busz zenet alap kommunikcit tmogat s kpes a klnbz helyszneket virtualizlni (klaszterezs segtsgvel). Szmos absztrakcit tmogat melyek az zenetek irnytsval, manipulci-jval foglalkoznak. Bvebben a 11-12 fejezetekben beszlnk az ESB-rl.

5.5.6. SCA

Ellenttben az ESB-vel mely az zenetekre azok manipullsra koncentrl, az SCA (Szol-gltats Komponens Architektra Service Component Architecture - SCA) egy nagyobb szkpot cloz meg. Alkalmazsokat lehet benne definilni a SOA koncepci men-

5. Kztesrteg 35


tn. Mg az ESB java specifikus (gyakorlatilag a JBI JSR 208 megvalstsa) addig az SCA nyelv fggetlen. Az SCA-ban szerelvnyeket lehet definilni melyeket a futtat krnyezet megfelel mdon virtualizlhat s kezelhet. Ezen szerelvnyek ms szerelvnyekre vagy szolgltatsokra (komponensekre) pthetnek (a SOA paradigma mentn).

5.6. sszefoglal E fejezet clja a kztesrteg szerepnek, lehetsges tpusainak s kpessgeinek bemutatsa volt. A kztesrtegek hasznlata napjaink alkalmazs vagy alkalmazsrendszer fejleszt-sekor elkerlhetetlen. A trendek azt mutatjk, hogy egyre fontosabb vlik a BASE s az ACID megkzeltst is vegyt rendszerek hasznlata, ezek megfelel integrcija mg nyitott krds. A jegyzet kvetkez rszben ttekintjk a napjainkban hasznlatos progra-mozsi nyelvi paradigmkat mivel ezek megfelel kivlasztsa nagyban hozzjrulhat a fejlesztk produktivitshoz.

5.7. Krdsek 1. Mit neveznk kztesrtegnek? 2. Mik egy kztesrteg legfontosabb feladatai? 3. Hogyan tmogatja a kztesrteg az egymssal kommunikl szmtsi egysgeket? 4. Hogyan tmogatja a kztesrteg az alkalmazsok s szolgltatsok fejlesztit? 5. Hogyan viszonyulnak a klasszikus rtelemben vett kztesrteg-megoldsok a mai,

modern felhalap szolgltatsokhoz?

5.8. Ajnlott irodalom Coulouris, G. s msok: Distributed Systems - Concepts and Design. 4. kiads.

Addison-Wesley, 2005. ISBN 0-321-26354-5

EBU project group on Middleware in Distributed programme Production: The Middleware Report. 2005. Elrhet: http://tech.ebu.ch/docs/tech/tech3300.pdf

Emmerich, W. s msok: The impact of research on middleware technology. ACM SIGOPS Operating Systems Review. Volume 41 Issue 1, 2007.

Jendrock, E. s msok: The Java EE 6 Tutorial. Oracle, 2010. Elrhet: http://download.oracle.com/javaee/6/tutorial/doc/javaeetutorial6.pdf



II. rsz

Nyelvi paradigmk,

trendek

6. Nyelvi paradigmk, trendek logikai megvalstsa 37


6. Nyelvi paradigmk, trendek - logika megvalstsa

Az elz fejezetben lthattuk az elosztott rendszerek irnyba mutat trendeket s azt a rteget mely az elosztottsgot igyekszik elfedni a fejleszt ell. Ezzel egyfajta magas szint ttekintst nyertnk a terletrl, lehetsges stratgiai irnyokrl. Egy kvetkez absztrak-cis szint lehetne, ha a kztesrtegre koncentrlva bemutatnnk annak rszletesebb krnye-zett az alkalmazson bell s alkalmazs rendszerek szintjn is. Ehhez azonban ismernnk kellene a kztesrteg alatt lv nyelvi krnyezetek kpessgeit, az ltaluk nyjtott lehetsgeket. Ezen ismeretek nlkl a programozk gyakran esnek abba a hibba, hogy csak egy nyelvi krnyezetre megoldsmdra koncentrlnak s figyelmen kvl hagyjk a programozsi nyelvek fejldsnek eredmnyeit. Jelen fejezet clja teht mieltt a kvet-kez rszekben belemlyednk a kztesrtegek s a hozzjuk kapcsold technolgia megoldsok, kpessgek bemutatsba, hogy ttekintsk azokat a megkzeltsmdokat, paradigmkat melyeket rdemes ismernnk amikor az zleti logika vagy az adatbrzols megvalstshoz hasznlhat paradigmkat rtkeljk.

Annak rdekben, hogy az elbb ismertetett adatbrzols s zleti logika mlyebb tar-talmt is megismerjk a kvetkez fejezetben a rendszerfejleszts folyamatnak vzlatos bemutatsnak segtsgvel bemutatjuk ezen fogalmak vals az egyes rendszerfejlesztsi lpsekhez kthet tartalmt. Ezek utn egy gyors ttekintst adunk a programozsi nyel-vek fejldsrl, generciirl, majd a leggyakrabban alkalmazott logika lersi s adat-kezelsi megkzeltseket mutatjuk be. A ksbbi fejezetekben ltni fogjuk, hogy egy-egy rendszer ezen nyelvek, lersmdok kombincija segtsgvel pl fel.

6.1. Rendszertervezs alapok A Rational Unified Process (RUP) egy igen elterjedt s npszer rendszerfejlesztsi meto-dolgia mellyel jelen trgy hallgatja mr megismerkedett a Rendszerfejleszts cm tan-trgy keretben. gy itt most csak azon aspektusokat tekintjk t melyek szksgesek a jegyzet megrtshez.

A RUP a rendszerfejleszts folyamatt kt dimenzi mentn taglalja: az egyik az id-belisget veszi alapul s ngy fzison t valstja meg a fejlesztst a msik dimenzi ezzel prhuzamos az egyes fzisokban kisebb vagy nagyobb sllyal megjelen eljrsokra bontja a munkt. Az egyes eljrsok sorn a problma lersnak absztrakcis szintje egyre alacso-nyabb lesz egyre kzelebb kerl a konkrt megvalstshoz alkalmazott krnyezethez. A fejleszt produktivitst nagyban befolysolja, hogy ezen folyamat sorn mekkora az ltala hasznlt eszkztr ltal biztostott absztrakcis szint. Az adott keretrendszer ltal biztostott absztrakcis szintet els krben maga a keretrendszer ltal hasznlt programozsi nyelv vagy nyelvek hatrozzk meg, msodik krben pedig maga a keretrendszer ltal megval-stott funkcionalits.

Az itercik szmnak nvekedsvel a RUP fle folyamat sorn kt egymstl tbb-kevsb jl elklnl terletet dolgoz fel. Az egyik terlet arrl szl, hogy a rendszer milyen adatokkal fog foglalkozni ezeket hogyan brzolja, itt milyen knyszerek vannak magbl az adatbl fakadan. A msik terlet a rendszer mkdsvel az ltala megvals-



tott funkcionalitssal foglalkozik. Eme terletek feldertsre megfelel absztrakcis szinten trtn lersra szmos mdszertan, modellez eszkz, megkzelts ltezik.

13. bra

A RUP eljrs lpseit a 13. bra szemllteti. Az egyes lpsek alatt a legtbb esetben jl elklnthet az adat s a logika brzolshoz hasznlt absztrakcis szint. Az zleti modellezs esetben a feladat a konkrt cltartomny megrtse, lersa gy a folyamatok mind a kezelt adatok, fogalmak szempontjbl. A kvetelmnyek kidolgozsnl mr egy absztrakcis szinttel alacsonyabban (a szoftverhez viszonytva) kivlasztott hasznlati esetekkel s ezen hasznlati esetek kztti esemnyfolyamokkal foglalkoznak. Az elemzs fzisban a hasznlati eseteket preczebb, pontosabb lersa segtsgvel absztrakt osztlyo-kat kpeznek s ezek interakcijt pontostjk. A tervezs folyamn az absztrakt osztlyok-bl egyrszt konkrt domain model msrszt alrendszerek s ezen alrendszerek kztti protokollok lesznek. Ezen elemek kerlnek megvalstsra s integrlsra. Mint lthatjuk nem mindegy, hogy a kivlasztott nyelv, felhasznlt fejleszt eszkz milyen absztrakcis szint nyjtsra

Documents

BILICKI VILMOS: PROGRAMRENDSZEREK FEJLESZTÉSE