2. szoftarch - minták

Component Configurator**

A.
Edző, Coach

B.
komponenseket futásidőben kell csatlakoztatni, cserélni vagy leállítani, anélkül hogy az alkalmazást újra kellene fordítani vagy indítani

C.
• komponensek funkcionalitása vagy teljesítménye futás közben módosításra szorulhat
• közös adminisztrációs feladatok

D.
• Válaszd szét a komponensek interfészét és implementációját.

• Biztosítsd, hogy minden komponens rendelkezzen egységes konfigurációs/interfész felülettel.

• Legyen egy központi vezérlő (Component Configurator), amely:

• betölti / inicializálja

• átmenetileg felfüggeszti

• leállítja / eltávolítja
  a komponenseket futásidőben.

E.
• Komponens – egységes interfész konfigurációra.

• Konkrét komponensek – tényleges megvalósítások.

• Komponenstár – nyilvántartja a betöltött komponenseket.

• Komponensbeállító (Coach) – betölt, felfüggeszt, leállít.

F.
• Csatolás: Coach betölti és inicializálja a komponenst, bekerül a komponenstárba.

• Használat: A komponens fut, feladatokat végez; a Coach felfüggesztheti/újraindíthatja.

• Leállítás: A komponens felszabadítja erőforrásait, a Coach eltávolítja és kiunloadolja.

G.
• Interfész–implementáció leválasztása.

• Dinamikus betöltés (pl. shared library, DLL, plugin).

• Erőforrások korrekt felszabadítása.

• Verziókezelés, kompatibilitás

H.
• Windows Service Control Manager (SCM)

• Java Applets (dinamikus betöltés)

• Bármilyen plugin-alapú rendszer

I:

Előnyök	Hátrányok
Egységes hozzáférés	Biztonsági kockázatok
Központi adminisztráció	Teljesítmény-overhead
Dinamikus konfiguráció	Bonyolult megvalósítás
Modularitás

Interceptor**

A.
Címváltozás, levéltovábbítás (Interceptor)

B.
Átlátszó módon szeretnénk új szolgáltatásokat kapcsolni egy keretrendszer belső eseményeihez, anélkül hogy a keretrendszert módosítani kellene.

C.
• Új szolgáltatások beszúrása a keretrendszer módosítása nélkül
• Ne változzon a keretrendszer eddigi működése
• A keretrendszer legyen monitorozható
• Belső eseményekhez szeretnénk logikát kötni

D.
• Definiáljunk beavatkozási pontokat (interception points).
• Minden ponthoz tartozzon egy interceptor interfész (callback metódusokkal).
• Legyen egy dispatcher, amelyhez kliensek regisztrálnak interceptorokat.
• Esemény bekövetkezésekor a dispatcher sorban meghívja a regisztrált interceptorokat.
• Kontextusobjektum biztosít hozzáférést a keretrendszer belső állapotához, ha módosítás szükséges.

E.
• Keretrendszer
• Interceptor
• Konkrét Interceptor
• Dispatcher
• Kontextusobjektum
• Alkalmazás (ami regisztrál)

F.
• Az alkalmazás létrehoz egy konkrét interceptor objektumot.
• Regisztrálja azt a megfelelő dispatcherhez.
• A keretrendszer eseményt észlel → létrehozza a megfelelő kontextusobjektumot.
• A dispatcher meghívja sorban az összes kapcsolódó interceptor callbackjét.
• A keretrendszer folytatja normál működését.

G.
• Ügyelni kell a kontextus biztosítására és határainak meghatározására
• Több interceptor sorrendjének kezelése
• Hibakezelés: egy interceptor ne akassza meg a rendszert
• Teljesítményre gyakorolt overhead minimalizálása

H.
• Komponens alapú alkalmazásszerverek
• CORBA, COM
• Böngészők (pl. Angular hibakezelés)
• Middleware rendszerek
I:

Előnyök	Hátrányok
Kiterjeszthetőség, rugalmasság	Komplex tervezés
Monitorozhatóság	Egy hibás interceptor megakaszthatja a rendszert
Újrafelhasználhatóság	Teljesítmény-overhead
Aspektus-alapú megközelítés támogatása

Extension Interface

A.
Extension Interface

B.
Olyan környezetekben hasznos, ahol a komponensek interfészei idővel fejlődnek, de a kliensek továbbra is működniük kell változtatás nélkül.

C.
• A komponensek interfészei változhatnak, de a klienskód ne törjön el
• Új funkciók hozzáadása ne bonyolítsa túl a meglévő interfészeket
• Interfész–implementáció különválasztása szükséges
• Távoli és lokális hívások egységesen történjenek

D.
• A funkciókat kiegészítő interfészekbe szervezzük (mindegyik egy logikai funkcióhalmaz).
• Ne módosítsuk a meglévő interfészeket → inkább új extension interface-t adjunk hozzá.
• A komponensek eléréséhez legyen egy component factory, amely:

• létrehozza a komponenst

• visszaad egy root interface-t, amelyen keresztül lekérhetők a további extension interfészek
  • A kliens mindig interfészeket használjon, ne az implementációt.

E.
• Komponens
• Kiegészítő (extension) interfészek
• Komponens gyár (Component Factory)
• Gyökér interfész (root interface)
• Kliens alkalmazás

F.
• A kliens a komponens gyár segítségével példányt kér
• A gyökér interfészen keresztül lekérdezi a kívánt extension interface-t
• Az extension interfész metódusain keresztül használja a komponens új funkcióit
• A komponens implementációt bármikor lecserélhetjük a kliens újrafordítása nélkül

G.
• Dönteni kell a stabil interfészstruktúrákról
• Domain-specifikus komponensmodell kialakítása
• Root interface tervezése
• Extension interfészek lekérdezésének mechanizmusa
• Factory felelősségeinek meghatározása

H.
• Microsoft COM / COM+
• CORBA 3
• EJB
• OpenDoc

I:

Előnyök	Hátrányok
Kiterjeszthetőség	Magasabb implementációs költség
Jó szemantikus szétválasztás	Teljesítmény-overhead
Polimorf megközelítés	Kliens komplexitása nő
Interfész aggregáció és delegáció

Reactor**

A.
Dispatcher, Notifier, „Telefonközpont” (Reactor)

B.
Több eseményt kell egyszerre kezelni szinkron, soros módon, hatékony és skálázható eseményvezérelt rendszerben.

C.
• Növelni kell a skálázhatóságot
• Csökkenteni kell a késleltetést
• Minimalizálni kell a szinkronizációt
• Események érkeznek párhuzamos forrásoktól → megfelelően szét kell osztani őket

D.
• Válasszuk szét a jelző események detektálását és a feldolgozásukat
• Minden eseménytípushoz legyen event handler
• Egy központi Reactor regisztrálja az eseménykezelőket
• A Reactor egy szinkron eseményelosztót (SED) használ az események várakoztatására
• Esemény érkezésekor a Reactor meghívja az adott eseményhez tartozó kezelőt

E.
• Reactor – központi dispatcher
• Synchronous Event Demultiplexer (SED)
• Event Handle – eseményleíró
• Event Handler – absztrakt kezelő
• Concrete Event Handler – konkrét kezelők implementációi

F.
• Eseménykezelők regisztrálják magukat a Reactorhoz
• A Reactor elindítja a handle_events() ciklust
• A SED blokkolva vár eseményekre
• Esemény érkezik → SED visszatér → Reactor azonosítja a megfelelő event handlert
• Meghívja a handler handle_event() műveletét
• Handler kiszolgálja az eseményt és visszatér

G.
• Event Handler interfész tervezése
• A Reactor interfész és eseményelosztási stratégia definiálása
• Megfelelő SED mechanizmus kiválasztása (pl. select, poll, epoll, IOCP)
• Döntés arról, hány Reactor instance legyen (egy vagy több)

H.
• Windows eseménykezelési rendszer
• X Windows eseménykezelés
• CORBA ORB Core
• Telekom rendszerek (Call Management)

I:

Előnyök	Hátrányok
Modularitás, újrafelhasználhatóság	Szinkron várakozás miatti blokkolás
Hordozhatóság	Nehézkes debuggolás
Kontrollált konkurenciakezelés
Egyszerű programozási modell

ACT** - Asynchronous Completion Token

A.
Active Demultiplexing, „Magic Cookie” (ACT)

B.
Aszinkron műveletekhez tartozó azonosítási token, amely összeköti a kezdeményezett műveletet a completion handlerrel.

C.
• Hogyan azonosítsuk gyorsan és egyszerűen, mely completion handler tartozik egy befejeződött aszinkron művelethez?
• Hogyan csökkentsük a kommunikációs overheadet?

D.
• Minden aszinkron híváshoz létrehozunk egy ACT objektumot, amely:
– azonosítja a műveletet
– referencia a hozzá tartozó completion handlerre
• Az ACT a befejeződéskor a completion eventtel együtt visszatér → így egyszerű a dispatching
• Az ACT lehet pointer, index, objektum, stb.
• A Proactor ennek alapján tudja, mely completion handlert kell meghívni

E.
• Service – aszinkron művelet szolgáltatója
• Initiator – művelet indítója
• Completion Handler – eredmény feldolgozója
• ACT – azonosító token

F.
• Initiator hívja a Service-t → ACT jön létre
• ACT hozzárendelődik a completion handlerhez
• A művelet befejeződik → completion event + ACT visszakerül
• Completion handler a handle_event() metódusában feldolgozza az eredményt

G.
• ACT reprezentáció: pointer / objektumreferencia / index
• ACT tárolása: implicit (OS kezeli) vagy explicit (alkalmazás tárolja)
• ACT használata callbackeken vagy sor alapú feldolgozáson keresztül
• Memóriakezelés kritikus (szivárgás veszélye)

H.
• HTTP cookie-k
• Windows, POSIX rendszerek
• CORBA demultiplexing

I:

Előnyök	Hátrányok
Egyszerűbb adatstruktúra a kezdeményezőnél	Biztonsági kérdések
Alacsony tárigény	Memóriaszivárgás veszélye
Rugalmasság
A klienseket nem befolyásolja a szerver működése

Acceptor-Connector**

A.
„Manager–Secretary” (Acceptor–Connector)

B.
Olyan rendszerekben használatos, ahol több szolgáltatási csomópont van, és el kell választani a kapcsolatfelépítés feladatát a szolgáltatás végrehajtásától.

C.
• Szolgáltatási csomópontok tehermentesítése
• Bővíthetőség biztosítása
• Kapcsolatfelépítési késleltetés minimalizálása
• Sok párhuzamos kapcsolat hatékony kezelése

D.
• A kapcsolatfelvételt külön komponensek végzik:

• Acceptor: passzív, várja a bejövő kapcsolatokat

• Connector: aktív, létrehozza a kapcsolatot
  • A szolgáltatás logikáját külön Service Handler valósítja meg
  • A kapcsolat létrejötte után a Service Handlert a Dispatcher regisztrálja és kezeli
  • A kapcsolat építés és az adatfeldolgozás fizikailag és logikailag különválik

E.
• Acceptor
• Concrete Acceptor
• Connector
• Concrete Connector
• Service Handler
• Concrete Service Handler
• Dispatcher – központi elosztó
• Transport Handle – kapcsolatot leíró erőforrás

F.
• Connector kapcsolatot kezdeményez → Acceptor fogadja
• A kapcsolat felépülésekor Service Handler példány születik
• A Dispatcher regisztrálja a Service Handlert
• A kezelési ciklus során a Dispatcher a megfelelő Service Handlerre bízza a beérkező eseményt
• A feldolgozás után a Handler visszakerül vagy megszűnik

G.
• Dispatcher implementációjához gyakran kombinálják Reactor vagy Proactor mintával
• Hibakezelés és időzítések fontosak
• Külön thread modellek kombinálása lehetséges

H.
• UNIX Network Superservers (inetd)
• Web böngészők kapcsolati rétege
• CORBA ORB rendszerek
• Nagy terhelésű szerver alkalmazások

I:

Előnyök	Hátrányok
Hordozhatóság, újrafelhasználhatóság	Többlet komplexitás
Hatékony kapcsolatkezelés	Single point of failure lehet a Dispatcher
Robusztusság	Dedikált komponensek szükségesek
Könnyű bővíthetőség

Active Object

A.
Concurrent Object, „Chef in a Restaurant” (Active Object)

B.
Olyan helyzetekben használjuk, amikor kliens egy külön szálban futó objektumot szeretne meghívni, de nem szeretnénk kézzel szinkronizálni a hívásokat és adat-hozzáférést.

C.
• Hosszú futású műveletek nem blokkolhatják a klienst
• Több kliens hívhatja egyszerre ugyanazt az objektumot → szinkronizáció kell
• A metódushívások végrehajtása és a hívás maga legyen szétválasztva

D.
• A kliens egy proxy-t hív meg
• A proxy a hívást method request objektummá alakítja
• A method request az activation listába kerül
• A scheduler egy külön szálban végrehajtja sorban a method request-eket
• A valódi logikát a servant valósítja meg
• A kliens egy future objektumot kap vissza, amin később lekérdezheti az eredményt

E.
• Client
• Proxy
• Method Request
• Concrete Method Request
• Scheduler
• Activation List
• Servant
• Future

F.
• Client meghívja a proxy-t
• Proxy létrehoz egy method request-et és berakja az activation listába
• A scheduler folyamatosan figyeli a listát, és végrehajtja a request-et a servant-on
• A future tárolja az eredményt, amit a kliens később lekérdezhet

G.
• Kritikusan fontos a thread-esedés helyes kialakítása
• A request queue kezelése
• A future objektum implementációja
• Időzítések és prioritások kezelése

H.
• Java Timer / TimerTask
• Symbian párhuzamosítás
• Siemens ACD (Automatic Call Distribution)

I:

Előnyök	Hátrányok
Párhuzamosság kihasználása egyszerűen	Performance overhead
A kliens nem blokkol	Debuggolás nehéz
Szinkronizáció átlátható	A végrehajtási sorrend eltérhet a hívási sorrendtől
Futásidejű optimalizálási lehetőség

Leader-Followers

A.
„Taxi Stands” (Leader–Followers)

B.
Több szálból álló rendszer, ahol sokféle eseményt kell kezelni, és a cél az, hogy a szálak hatékonyan osszák meg az eseménykezelést, fölösleges kontextusváltások nélkül.

C.
• Nagy mennyiségű párhuzamos esemény kezelése
• Kerülni kell a lockolási overheadet és a szálváltásokat
• Skálázhatóság és teljesítmény a cél

D.
• Legyen egy thread pool
• Egyszerre mindig egy szál a Leader — ő vár az eseményre
• A többi szál Followers, passzívan várakoznak
• Ha esemény érkezik, a Leader:
– kijelöl egy új Leadert
– elkezdi feldolgozni az eseményt
• A feldolgozás végén a korábbi Leader visszaáll a Followers sorba

E.
• Handle
• Handle Set
• Event Handler
• Concrete Event Handler
• Thread Pool

F.
• Leader szál vár az eseményre
• Esemény érkezik → Leader kiválasztja a következő Leadert
• Leader kezeli az eseményt
• Ha végzett, visszaáll Follower státuszba
• Cycle ismétlődik

G.
• Szükség van hatékony thread pool implementációra
• Ütközések kezelése (deadlock elkerülése)
• Események kiosztásának optimalizálása
• Hiba esetén ne maradjon Leader nélkül a rendszer

H.
• CORBA ORB
• Webszerverek (pl. Apache variánsok)
• Transaction monitorok
• Taxi dispatching analógiák

I:

Előnyök	Hátrányok
Nagyon hatékony concurrency modell	Rugalmatlan (leader szerep kiosztása kötött)
Minimális lockolás	Hálózati hiba esetén problémás lehet
Kevés kontextusváltás →jobb performance
Egyszerűbb programozási modell