Komponens-absztrakció

1. Komponens-absztrakció

2. Objektum-orientált paradigma korlátai • Feltételezés az interfészekről:1. öröklés és aggregáció alkalmazható,2. közös programozási nyelvi környezet. • De! Sok alkalmazás többnyelvű,többféle paradigma szerint felépülő környezetben fut.MINDEZ MAGASABB SZINTŰ ABSZTRAKCIÓTFELTÉTELEZ.

3. Az OO paradigma indirekt módon kis és relatív homogén részekhez vezet, amelyeket össze kell kapcsolni kódolással. Ez jelentős hibaforrás. • Komponens absztrakció: Nagy egységek összecsomagolása, amely esetenként heterogén, kész elemekből épül fel. Magasabb szintű képesség adódik.

4. Komponens-absztrakció • Példa: Tipikus eset, hogy szükség lehet különböző objektum-hívásokra, eseményekre, amelyek válaszokat generálnak, tranzakciókra, amelyek kezelik és elrendezik az állapotváltozásokat, hibatűrési képességre, amely kezeli a hibákat. • Ilyen alkotó elemek általában készen kaphatók, de elkülönülten és gondosan kell őket összeilleszteni, hogy egy alkalmazás komplett modulját képezzék.

5. Komponens alapú paradigma • Komponens: szoftver rendszer körülhatárolt része, amely specifikus szolgáltatást, vagy szolgáltatások halmazát valósítja meg. • Komponens modell definiálja: 1. komponens tulajdonságait, pl. verzió, függőségi viszonyok más komponensektől, komponens azonosító, működési politikák;2. exportált interfészek halmazát;3. csomagolás, összeállítás, szétterítés és futtatási időbeni kezelését a komponens példányoknak.

6. Objektumok és komponensek elkülönítő tulajdonságai • 1. Komponenstöbbszörös láthatósága és transzparens navigációja különböző láthatóságai között. Objektum: egy interfész implementációja, amely más objektum interfésszel csak az öröklés szempontjából hozható összefüggésbe.

7. 2. Kiterjeszthetőség. Komponens magasabb szintű absztrakció, ezért az öröklés kevésbé kritikus a többformátumúság eléréséhez.Objektum: installációs egység, típust, interfészt és működést határol be. Problémához tartozó, esetleg fizikai entitást modellez. Tipikusan valamely program nyelven lett implementálva és jól definiált objektum-együttműködési szabályokat követ.

8. Komponens: Nem szükséges, hogy osztálynak feleljen meg, nem szükséges, hogy speciális program nyelven legyen implementálva, nem kell, hogy binárisan kompatibilis legyen más komponensekkel. Komponens úgy tekinthető, mint olyan szolgáltatást nyújtó, amely helyettesíthető ekvivalens komponenssel, amely más program nyelven van implementálva. Ezt a kiterjeszthetőséget az ExtensionInterface tervezési sablon biztosítja, amely szabványos protokollt definiál együttműködő komponensek csoportjának létrehozására, összeállítására és fejlesztésére.

9. 3. Magas szintű végrehajtási környezet. Objektum. Direkt függés az infrastruktúrától korlátozhatja az objektum szolgáltatásinak elkülönült fejlesztését a végrehajtás alapjául szolgáló infrastruktúra fejlesztésétől.Komponens. A modell definiálja a végrehajtási környezetet - a konténert -, amely magasabb szintű absztrakció, mint az objektum-végrehajtási környezet. A konténer végrehajtási környezet a vezérlés egy további szintje, ahol polisziket definiálhatunk és érvényesíthetünk futási időben.

10. CORBA 2.x Object Management ArchitectureAlap eleme az interfész. Művelet hívás az interfészen elkülönül az interfész implementációjától. Definiálja, a kliens hogyan látja és fér hozzá a szerver által nyújtott szolgáltatáshoz.

11. CORBA 2.x OMA korlátai: • 1. Funkcionális elhatárolás hiánya. A modell minden interfészt kliens szerver kontraktusnak tekint. A modell nem tartalmaz szabványos összerakási mechanizmust, amely leválasztaná a függőségeket az együttműködő objektum implementációktól. • 2. Generikus applikációs szerver szabvány hiánya. CORBA 2.x szabványosítja az objektum implementáció és az ORB kommunikációját. De a felhasználónak kell meghatároznia az objektum implementációt az ORB felett, valamint az ORB és az implementáció interakcióját.

12. 3. Szoftver konfigurálási és szétterítési szabvány hiánya. Nincs szabványos mód az osztott alkalmazás komponenseinek szétterítésére és indítására távolról a CORBA 2.x specifikációban.

13. CORBA Komponens Modell (CCM Middleware) áttekitése • CCM eredmények: 1. Virtuális határt von nagyobb alkalmazói komponensek köré, amelyek jól definiált interfészeken keresztül kommunikálnak. 2. Szabványos konténer mechanizmust definiál, amely ahhoz szükséges, hogy a komponenseket generikus komponens szerverekben hajtsuk végre. 3. Infrastruktúrát specifikál komponensek összerakásához, csomagolásához és szétterítéséhez elosztott környezetben.

14. Kliens szempontból a CCM komponens egy kiterjesztett CORBA objektum, amely beskatulyáz különféle interakciós modelleket különböző interfészek és kapcsoló műveletek segítségével. • Szerver szempontból a CCM komponens az implementáció egy olyan egysége, amely függetlenül installálható és példányosíthatóolyan szabványos alkalmazói szerver végrehajtási környezetben, mint amilyet a CCM specifikáció meghatároz.

15. Komponens nagyobb alkotó elem, mint az objektum. Interakciói leegyszerűsítik és automatikussá teszik a komponens konstrukció és a kompozíció eszközeit, valamint a komponens alkalmazásokba történő beillesztését.

16. Komponens felépítése • Komponens implementációs entitás, amely portok halmazát definiálja, amin keresztül a komponensek képesek együttműködni. Ezeket a portokat interfészeknek és kapcsolódási pontoknak nevezik. • Portoknak nevezzük a következő interfészeket és kapcsolódási pontokat:1. Facet: névvel ellátott interfész, amely metódus hívásokat szolgál ki más komponensek felől szinkron módon.

17. 2. Receptacle: névvel ellátott kapcsolódási pont valamely szinkron facet-hez, amelye egy más komponens nyújt.3. Esemény forrás és elnyelő. Alapvetően esemény-üzenetek küldésére és fogdására alkalmas aszinkron módon.Komponensnek lehetnek attribútumai, amelyek névvel ellátott paraméterek. Ezek a paraméterek később konfigurálhatók olyan meta adatok segítségével, amelyeket a komponenshez rendelt file-ok tartalmaznak.

18. CCM konténer • Konténerszerver oldali végrehajtási környezetet definiál komponens implementációk számára. A komponens implementációkat executor-oknak nevezzük.Konténer különböző, előre definiált eszközöket és műveleteket tartalmaz, amelyek segítségével a komponens stratégiákhoz és szolgáltatásokhoz férhet hozzá. Ilyenekhez pl. mint: perzisztencia, eseményjelzés, tranzakciók, terheléskiegyenlítés, titkosítás, stb.

19. Minden konténer futási idő stratégiákat és polisziket definiál, pl.: eseménytovábbítás, komponens használat stratégiák. Komponens feladata a kezelt komponenseknek futtatási környezet inicializálása és szolgáltatása. Minden komponens implementációhoz XML-ben specifikált meta adat tartozik, amely meghatározza a kívánt konténer stratégiákat és polisziket.

20. CCM ComponentImplementation Framework (CIF) • Automatikusan generálja a komponens implementáció vázát és a perzisztens állapotkezelő mechanizmust a ComponentImplementationDefinitionLanguage (CIDL) alkalmazásával. A CCM csomagolási eszköz a komponens implementációhoz XML alapú meta adatot csatol. A CCM összeállítási eszköz XML alapú meta adatokat használ a komponens összerakásának leírására. A meta adat specifikálja a komponens helyét a komponensek interakcióját, amely alapján kialakul egy összerakott alkalmazás.A CCM szétrakási eszköz a komponens összerakási és összeállítás meta adatait használja az alkalmazás részeink szétrakására és inicializálásra.

21. A CCM programozási paradigma fejlesztői lépései • 1. Komponens tervező. Definiálja a komponens szerepét, együttműködését más komponensekkel. Definiálja a komponens portokat. • 2. Komponens kivitelező. Kialakítja a komponens implementációt, specifikálja a futási időbeli támogatási igényt meta adatok segítségével. Ezeket komponens leíróknak nevezzük. • 3.Komponens csomagoló. • 4. Komponens összeállító. • 5. Rendszerszétrakó.