Komponentowa technologia CCM

Klasa Sklep deklaruje implementację interfejsu. Interfejs ten definiuje meto-dę service(), przyjmującą parametr typu ServiceManager. Parametr pełniący rolę obiektu-kontekstu, zostaje przekazany komponentowi przez kontener w mo-mencie jego tworzenia poprzez wywołanie metody service(). Obiekt ServiceMa-nager wyszukuje komponenty w rejestrze kontenera poprzez metodę lookup(), która korzystając z przekazanego jej klucza komponentu wyszukuje go w reje-strze. Dzięki temu komponent Klient może uzyskać referencję do zależnego komponentu Sklep. Rola komponentu w wyszukaniu zależności polega tu więc na całkowitym uzależnieniu tego procesu od komponentu ponieważ komponent, który nie wywoła metody lookup(), nie otrzyma wymaganej zależności [7].

2.3. Komponentowa technologia CCM

COBRA Component Model – CCM stanowi rozwinięcie wcześniej wprowa-dzonego standardu dla systemów heterogenicznych, który pozwala na współ-pracę aplikacji w środowisku WWW niezależnie od platformy, języka progra-mowania, formatu i struktury danych. Model CCM odnoszony jest do standardu COBRA 3 i determinuje ramy współpracy komponentów rozproszonych pro-gramów w bardziej uniwersalnym zakresie niż operacje, które wynikają z moż-liwości komponentów standardu EJB. Mechanizm pracy CCM zapewnia usługi poprzez dobrze zdefiniowane interfejsy, zwane portami odnoszone do współ-pracy z kontenerami komponentów. Kontener taki oferuje zbiór usług wynika-jący z użytych komponentów i w rozproszonym środowisku przesuwa usługi z pojedynczych komponentów na kontenery komponentów, co wiąże się z istot-nym uproszczeniem struktur programowych wykorzystywanych we wcześniej-szym klasycznym podejściu COBRA [8].

Komponenty CCM kooperują wzajemnie poprzez tzw. ports. Wyróżniane są tu pokazane na rys 1 następujące rodzaje ports:

ƒ facets – definiujące interfejsy zapewniające na zasadzie punkt do punktu użycie metody inwokacji określonych komponentów z innych komponen-tów,

public interface Serviceable {

public void service(ServiceManager manager);

}

public class Sklep implements Servicseable { private ServiceManager manager = null;

private Klient klient = null;

}

public void service(ServiceManager manger) { this.manager = manager;

this. klient = (Klient) manager.lookup(“Klient”);

} }

Lucjan Grochowski 28

ƒ receptables – uzależniające interfejsy określonych komponentów punkt do punktu z innych komponentów,

ƒ event sources / sinks – pozwalające na wymianę informacji między jed-nym lub kilkoma komponentami.

Rys. 1. Komponent CCM z zaznaczonymi charakterystycznymi portami

Kontener w podejściu CCM determinuje środowisko pracy dla jednego lub kilku komponentów określonych notacją zdarzeń, transakcjami, bezpieczeń-stwem itp. Każdy kontener jest odpowiedzialny za inicjowanie i zarządzanie określonymi atrybutami komponentu oraz powiązania danego komponentu z in-nymi poprzez usługi pośrednie tzw. middleware services.

W rozproszonym systemie sieciowym każdy komponent może być konfigu-rowany na różne sposoby. Ponieważ jednak w indywidualnych komponentach liczba konfigurowanych parametrów i opcji wzrasta, w podejściu CCM dla cha-rakteryzowania meta-danych definiuje się grupy komponentów. Stanowią one tzw. assembly entities determinujące abstrakcyjny serwer komponentów, który dokonuje agregacji fizycznych obiektów w logiczne obiekty opisujące rozpro-szone usługi i podsystemy.

W podejściu CCM pociąga to za sobą standaryzację sposobów implementa-cji komponentów odnoszonych do pakietów komponentów z wyróżnionymi własnościami funkcjonalnymi oraz mechanizmami ich użycia. Te ostatnie od-noszą się do tzw. Dynamic Link Library i meta-danych opisujących właściwości w kontekście zastosowań. Pozwala to na wygenerowanie szkieletu implementa-cji komponentów określonej aplikaimplementa-cji, która automatycznie może być zarządza-na przez wykorzystanie tzw. Component Implementation Definition Language (CIDL).

Jest to równoważne budowie swoistej fabryki kreowania kontenerów wraz z ich środowiskiem wykonawczym, demonstruje to rys. 2.

Interfejs komponentu

Facets

Event sources Event

sinks

Atrybuty

Receptacle s

Porty oferowane

Komponent CCM

Porty żądane

Programowanie komponentowe w środowisku WWW 29

Rys. 2. Implementacja komponentów CCM z wykorzystaniem języka CIDL

2.4. Komponentowa technologia .NET

Technologia .NET lansowana jest przez Microsoft jako następca technologii Component Object Model COM oraz jej kolejnej wersji DCOM / COM + . Technologię tą tworzy platforma programistyczna obejmująca środowisko uru-chomieniowe zwane Common Language Runtime – (CLR) oraz biblioteki klas zapewniające funkcjonalność dla tworzonych aplikacji. Charakterystyczną ce-chą tej technologii jest brak powiązań z jednym językiem programowania; pro-gramy mogą być pisane praktycznie w każdym języku wysokiego poziomu dostosowanym do aplikacji sieciowych. Podstawową rolą platformy .NET jest zarządzanie kodami aplikacji, pamięcią i zabezpieczeniami odnoszonymi do środowiska programistycznego działającego tak po stronie serwerów WWW, jak i pracującego na komputerach zawierających implementacje platformy .NET typowo adresowane do aplikacji Microsoftu.

W skład platformy wchodzą kompilatory:

ƒ języków wysokiego poziomu – standardowo C++ / CLI, C#, Visual Basic .NET oraz J# (C#, Java # są wariantami języków C i Java opracowanych przez Microsoft),

ƒ zarządzanych kodów.

Stosowane tu metody kompilacji są podobne do zastosowanych w Javie, gdyż

ƒ kompilatory kompilują najpierw kod źródłowy do postaci uniwersalnego kodu pośredniego zwanego CLI,

PLIKI CIDL

Kompilator CIDL

Repozytorium interfejsów

Kod źródła Kod wygenerowany

Kod wygenerowany Kod wygenerowany

Komponent implementacji - kod źródła

KOMPILATOR KOMPILATOR Kod źródłowy klienta

Program komponentu

Program klienta

Kod wykonywany Kod wykonywany

Lucjan Grochowski 30

ƒ kod CLI, z kolei, jest kompilowany do kodu maszynowego od momentu pierwszego wywołania. Realizowane to jest w czasie wprowadzania kodu przez dołączenie do każdej metody modułu tymczasowego fragmentu kodu, który przekazuje sterowanie do kompilatora i jest zastępowany przez skompilowany kod. Nosi to nazwę kompilacji w locie.

Podstawowymi blokami platformy .NET są bloki CLR, CTS i CSL. Pierwszy z nich odpowiada za lokalizowanie, wczytywanie i zarządzanie typami danych, drugi odpowiada za opis danych udostępnianych przez środowisko uruchomie-niowe a trzeci stanowi zbiór zasad definiujących podzbiór wspólnych typów zgodności kodu binarnego z kompilatorami .NET.

Platformę .NET wyróżnia wprowadzenie pośredniego kodu Common Language Infrastructure zapewniające każdemu językowi programowania dostęp do bi-bliotek .NET. Warunkiem jednak jest tutaj spełnianie przez takie języki wymo-gów standardów obiektowości. Dla podkreślenia spełniania tych standardów wprowadza się do takich języków niekiedy przyrostek .NET np. Visual Basic.NET, JavaScript.NET itp., ale równorzędnie z tym wymogi te spełniają również wa-rianty języków w wersji Microsoftu C#, Java#..., a także inne języki, w których nie wprowadza się żadnych dodatkowych oznaczeń.

Dodać można, że platforma .NET pociągnęła za sobą powstanie kilku po-chodnych technologii, z których najistotniejsze to ADO.NET ułatwiająca dostęp do baz danych oraz ASP.NET adresowana do budowy dynamicznych stron WWW.

Implementacje .NET adresowane są przede wszystkim do platform oznacza-nych jako Microsoft.NET Framework, Novell.Mono i DotGNU Portable.NET.

Pozwalają one na pracę w środowisku programistycznych, z których najbardziej popularne jest zintegrowane środowisko programistyczne Visual Studio 2005 Express obejmujące : Visual Basic 2005 Express Edition, Visual C# 2005 Express Edition, Visual C++ 2005 Express Edition, Visual J# 2005 Express Edition, Visual Web Developer 2005 Express Edition, SQL Server 2005 Express Edition.

Wersje .NET Framework są stale jeszcze rozwijane, ostatnia z nich to .NET Framework 4.0.

3. Wnioski

W artykule przedstawiono w przeglądowym zarysie obecny stan trendów tworzenia oprogramowania, które staje się w wielu obszarach zorientowane na programowanie sieciowe lokowane w WWW. Zaprezentowano, jako najbardziej reprezentatywne do wytyczonego celu, mechanizmy budowy i wykorzystywa-nia komponentów odnoszonych do technologii Enterprise Java Beans, COBRA Component Model oraz technologii firmy Microsoftu .NET. Rozważania po-przedziło zdefiniowanie pojęcia komponentu w kontekście wcześniej wprowa-dzonego na rynek oprogramowania obiektowego, akcentując, że podejście komponentowe jest kolejnym etapem rozwoju współczesnych metod

oprogra-Programowanie komponentowe w środowisku WWW 31 mowania. Pokazano, że komponent jest konfigurowalną jednostką wielokrotnego użytku, a zasadą jego wykorzystania jest instytucja kontenerów programowych pozwalająca na tworzenie pożądanych konfiguracji programowych i zarządzania cyklami życia komponentów. Zaprezentowane mechanizmy programowania kom-ponentowego potraktowano jako dojrzały technicznie etap wykorzystywania metod oprogramowania nie negując przy tym bardziej zaawansowanych, no-wych mechanizmów programowania odnoszących się, np. do metod takich jak Web Semantic. Te ostatnie są wprawdzie bardziej zaawansowane, ale nie osią-gnęły one stopnia dojrzałości pozwalającego na szersze implementacje, zwłasz-cza implementacje biznesowe.

L

:

[1] Cox B.J., Novobilski A.J., Object-Oriented Programming: An Evolutionary Approach, 2nd ed. Addison-Wesley, 1991.

[2] COBRA Component Model, W3C references.

[3] Heineman G.T., Councill W.T., Component-Based Software Engineering:

Putting the Pieces Together, Addison-Wesley Professional, Reading 2001.

[4] Meyer B., Object-Oriented Software Construction, 2nd ed. Prentice Hall, 1997.

[5] Szyperski C., Component Software, ACM Press/ Addison-Wesley, England, 1998.

[6] Szyperski C., Component Software: Beyond Object-Oriented Programming, 2nd ed. Addison-Wesley Professional, Boston 2002.

[7] Veryard R., Component-based business: plug and play, Springer, London 2001.

[8] Zieliński K., Zagadnienia konstrukcji oprogramowania komponentowego, art. w portalu e-Informatyka.pl, http://www.e-informatyka.pl/ article/show-bw/475.

COMPONENT PROGRAMMING IN WWW ENVIRONMENT