Komponens modellek 3. Előadás (első fele)
A komponens modellek feladata • Támogassa a szoftverrendszerek felépítését különböző funkcionális, logikai komponensekből, amelyek a számítógépes hálózatban különböző csomópontokban (nodes) helyezkedhetnek el. • A komponens alapú szoftverfejlesztést tehát a hardver és a szoftver oldaláról is támogatni kell. Az alapszoftver oldaláról a támogatás egyik fontos eleme az úgynevezett köztes réteg (middleware).
Köztes réteg (middleware) • Valahol az operációs rendszer és az alkalmazások között helyezkedik el, azokhoz hasonló szolgáltatásokat nyújt:
• Futtató környezetet biztosít • Tipikus operációsrendszer funkciókat nyújt • Összeköttetés operációsrendszer és a programozási nyelv között • Egy operációsrendszert és egy programozási nyelvet támogat • Futtatható kód előállítása kódgenerátorral • Komponensek kézi létrehozásának fontossága csökken, egymástól függetlenül fejlesztik a komponenseket.
• A komponenek lehetnek azonos hálózati végpontban vagy különbözőekben • A távoli komponensek együttműködésének megvalósítása „távoli eljáráshívásokkal” (RPC) • Valamilyen RPC minden modern komponens platformban megtalálható • A köztes rétegre épülnek rá az objektum modellek.
Komponens modellek • Object Management Group (OMG) – CORBA
• Microsoft – COM/DCOM
• Sun Microsystems – EJB
CORBA • Common Request Broker Architekture • Az első kísérlet egy objektum modell definiálására • OMG 1991 • Főbb részei: – Object Request Broker (ORB) • A CORBA „szíve”, felelős a komponensek közötti kapcsolat létrehozásáért és fenntartásáért.
– Interfészek leírása Interface Definition Language IDL nyelven • Hordozható, programozási nyelvtől és operációs rendszertől független nyelv. – IDL – célnyelvi fordítók
Object Request Broker (ORB) • Elfedi a különböző címtartományok közötti kommunikációt – Az ORB felügyelete mellett a komponensek úgy létesítenek egymással kapcsolatot, mintha mindannyian egyetlen címtartományban léteznének. – Az ORB több összetevőből áll a kliens és szerveroldalon
• Kliensoldalon – A kliens IDL kapcsolódási csonkok (Client IDL Stubs) biztosítják a kliensoldal statikus felületeit a CORBA komponens eléréséhez. • A távoli komponens helyi képviselője, proxy, amely a hozzá intézett hívásokat továbbítja a távoli szolgáltatóhoz. • Gondoskodik a paraméterek átirányításáról a szerver felé, ez az ún. marshaling.
– Az ORB felület (ORB interface) néhány hasznos helyi szolgáltatást nyújt a CORBA felhasználóinak: • Komponenshivatkozások karakterlánccá konvertálása, stb.
– A dinamikus hívási felület ( Dynamic Invocation Interface – DII ) segítségével olyan dinamikus komponenseket készíthetünk, amelyek futás alatt derítik fel a szerveroldali komponensek metódusait, és hívják meg azokat. • A DII nagyobb rugalmasságot ad futási időben, a statikus jellegű IDL csonk viszont támogatja a fordításidejű típusellenőrzést
– Az Interfész-szótár programozói felület (Iterface Repository API) futásidejű hozzáférést biztosít az interfész-szótárhoz, amely az IDL definíciók feldolgozott formáit tartalmazza. • A CORBA 2.0 esetén ORB globális azonosítókat (Repository ID) is tartalmaz, amelyek a komponenseket és interfészüket egyedileg azonosítja.
• Szerveroldalon – A szerver IDL kapcsolódási felület (Server IDL Stub) a szerver oldali komponensek által nyújtott statikus szolgáltatásokat definiálja. Ennek a vázát (skeleton) is az IDL fordító generálja. – A dinamikus kapcsolódási felület (Dynamic Skeleton Interface – DSI) a kliens oldali dinamikus hívási felület (DII) párja. Futási időben csatlakozási információt szolgáltat azokról a szerveroldali komponensekről, amelyeknek nincs IDL által definiált statikus csonkja. A DSI a bejövő üzenet paramétereiből határozza meg a komponenst és annak szolgáltatását (metódusát).
• Az objektumadapter (Object Adapter) az előző két felület implementációjához szükséges, de önállóan is használható. – Ez a futtatási környezet: • Objektumreferenciák, • Implementációs szótár kezelése.
– Minden ORB legalább egy adaptert támogat • Basic Object Adapter (BOA)
– AZ implementációs szótár (Implementation Repository) • a megvalósított szerveroldali osztályok leírását tartalmazza • Számon tartja, hogy mely objektumokat példányosították, hogyan lehet azokat azonosítani.
– Az ORB felület, amely a kliensoldali megfelelő a szerver oldalán.
Interface Definition Language (IDL) • A CORBA erősen objektum elvű rendszer – A szerverkomponensek osztályként definiálhatók, jellemzői: • Öröklődés • Kivételkezelés • Adatelrejtés (encapsulation).
• Az osztályok definiálására az IDL nyelvet használjuk – Hordozható – Programozási nyelvtől és operációs rendszertől független deklaratív nyelv, amely tehát procedurális elemeket nem tartalmaz, de támogatja • • • • •
Típusok Konstansok Adatelemek Metódusok Kivételek deklarációját.
• AZ IDL nyelven leírt interfészekből az IDL-fordító készít konkrét nyelvű kódot (pl. Java), amelyet ki kell egészíteni a metódusok szintén konkrét nyelvű megvalósításával. • Az IDL nyelv vázlatos szerkezete megtalálható például a – Java 2 Útikalauz programozóknak című könyvben (szerk. Nyékyné Gaizler Judit, ELTE TTK Hallgatói Alapítvány, Budapest, 1999.)
IDL – célnyelvi fordítók • Az IDL – Java fordító – Inputja: IDL nyelvű interfész leírás – Outputja: Java kódú program – A fordító működését a JAVA 2 tankönyv 22.3 fejezetében megtalálhatják. – Egy egyszerű, de hasznos példát találnak a CORBA használatára a fenti könyv 22.4. fejezetében. • A példában olyan objektumcsoportot kívánunk létrehozni, amelyeknek a példányai más-más szerveren helyezkednek el. • A fenti példában a kliens és a szerver a CORBA névszolgáltatásán (Naming Service) keresztül találtak egymásra.
COM/DCOM • Component Object Model - COM – A Microsoft első komponens modellje (‘93)
• COM+ – COM bővítése: tranzakciók, aszinkron üzenetek, klaszterezés kezeléseinek eszközeivel.
• Distributed COM – DCOM – A COM elosztott kiterjesztése – A DCOM kliens képes egy DCOM szerverrel kommunikálni – kliens helyettesek és szerver csonkok segítségével.
• A CORBA és a DCOM szolgáltatásai egyre jobban közelítenek egymáshoz, de az eszközrendszerükre ez nem igaz.
JavaBeans - EJB • A Java komponens modelljei – Röviden bemutatjuk a JavaBeans modellt a mai előadásban – Az EJB modell lényegét a J2EE architektúra részeként tárgyaljuk meg.
JavaBeans • A Java legegyszerűbb komponens modellje. – Első közelítésben egy JavaBean olyan újra felhasználható szoftver komponens, amely egy fejlesztő környezetben vizuálisan manipulálható.
• A JavaBeans komponens modellben – Egy komponensnek többféle, egymástól független implementációja lehet. – Egy adott komponensből több példány is létrehozható a különböző alkalmazások számára testre szabva. – A komponensek konténerek elemei lehetnek. – Egy komponens lehet konténer és ő is tartalmazhat más komponenseket. – A komponensek közötti kommunikáció és kapcsolat eseménykezeléssel és metódusok hívásával történik.
• A JavaBeans komponens modell támogatja a hierarchikus szoftverfejlesztést, ahol egyszerűbb komponensekből bonyolultabbakat tudunk létrehozni a konténerek segítségével. • Felhasználhatjuk a vizuális fejlesztő eszközök nyújtotta szolgáltatásokat. • A beanek fejlesztését megkönnyíti a Sun által kifejlesztett BeanBox fejlesztő környezet. • A JavaBeans modell támogatja a beanek testre szabását tulajdonságlisták alapján, amelyek a képernyőn megjeleníthetők.
EJB - Enterprise Java Bean • Szerver oldali elosztott komponens modell • Funkcionalitása szerint több fajtája van: – Session Bean – Enterprise Bean – MessageDriven Bean
• Futtatásukhoz alkalmazásszerver (EJB konténer szükséges) • Kontraktus az EJB és a konténer között: – interfészek halmaza – telepítési leírók
Java2EE
Egy architektúra komponens alapú, többrétegű vállalati alkalmazások fejlesztésére J2EE architektúra:
Összefoglalás • A komponens modell a komponens alapú szoftverfejlesztés egyik központi fogalma. • A komponens modellek fontos szerepet játszanak az alkalmazásfejlesztés menetében az alkalmazott architektúra és a fejlesztési platform szempontjából.
