Komponens modellek. 3. Előadás (első fele)

Átírás

1 Komponens modellek 3. Előadás (első fele)

2 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).

3 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:

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

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

6 Komponens modellek Object Management Group (OMG) CORBA Microsoft COM/DCOM Sun Microsystems EJB

7 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

8 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

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

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

11 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).

12 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)

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

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

15 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.)

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

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

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

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

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

21 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

22 Java2EE Egy architektúra komponens alapú, többrétegű vállalati alkalmazások fejlesztésére J2EE architektúra:

23 Ö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.