dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl

Budowa obiektowych aplikacji sieciowych dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl

Zagadnienia Obiektowe technologie programowania rozproszonego o DCOM, o Java RMI, o Corba. Środowisko.Net, interfejs programowy Winsock.Net. Przykład programu klient-serwer UDP Echo (język C#).

Component Object Model (COM) COM+ Distributed Component Object Model (DCOM) 3

Co to jest COM+? COM+ jest rozszerzeniem technologii komponentowej COM (Component Object Model), umożliwiającą budowę usług z wykorzystaniem Microsoft Transaction Server (MTS). Obiekty COM+ służą do: buforowania danych (resource pooling), rozłączania aplikacji, publikowania zdarzeń (event publication), obsługi transakcji rozproszonych. Typy aplikacji COM+: serwer, proxy (klient), biblioteka. W środowisku.net obiekty COM+ są zdefiniowane w obszarze nazw System.EnterpriseServices. 4

Microsoft Transaction Server Microsoft Transaction Server (MTS) służy do: kolejkowania wiadomości, zarządzania pamięcią, zarządzania wątkami, zarządzania zdarzeniami.

Usługi COM+ Usługi COM+: Automatic Transaction Processing. BYOT (Bring Your Own Transaction), usługa pozwala na definiowanie dziedziczenia między transakcjami. Just-in-Time Activation, usługa aktywuje obiekt, gdy ten wywołuje metodę, deaktywuje go gdy metoda zwróci wartość. Loosely Coupled Events, usługa służy do zarządzania zdarzeniami. Object Construction, usługa przekazuje wartość typu string do tworzonego obiektu. Object Pooling, usługa kolejkuje obiekty. Private Components, chroni komponenty przed wywołaniem przez zewnętrzne procesy. Queued Components, odpowiada za asynchroniczne kolejkowanie wiadomości. Role-Based Security. SOAP Service. Synchronization, zarządza procesami współbieżnymi. Services without Components, pozwala aplikacjom korzystać z usług COM+ które nie mają zaimplementowanych ServicedComponent object lub nie mają skonfigurowanego katalogu COM+.

Distributed Component Object Model (DCOM) DCOM model, technologia firmy Microsoft służąca do budowy systemów rozproszonych (distributed systems). Obiekty DCOM mogą komunikować się między sobą poprzez sieci internetowe. DCOM jest rozszerzeniem modelu COM. Technologia COM/DCOM jest niezależna od języka implementacji. Język i kompilator MIDL (Microsoft Interface Definition Language) służy do specyfikowania interfejsów między serwerem a klientem, definiowania metod i obiektów COM/DCOM.

Distributed Component Object Model (DCOM) Podstawowe pojęcia modelu COM/DCOM: klient serwer - interfejs program, który wywołuje metody na serwerze COM/DCOM. program, który udostępnia obiekty COM/DCOM klientowi. wskazuje na grupę funkcji, które są wywoływane za pomocą obiektów COM/DCOM. klasa COM/DCOM obiekt COM/DCOM zwana ko-klasą, definiuje obiekt, który implementuje interfejsy COM/DCOM. instancja ko-klasy, klasa COM/DCOM. marshaling przekazywanie danych (parametrów) między klientem a serwerem COM/DCOM. Marshaling jest mechanizmem zbierania i formatowania danych w celu przesłania ich do innego procesu.

Klient, serwer, proxy Klient przekazuje (marshals) i odbiera (un-marshals) dane za pomocą obiektu proxy. Obiekt proxy dostarcza te same interfejsy co COM/DCOM serwer ale ich nie implementuje (implementacja jest na serwerze). Serwery są komponentami pasywnymi, tzn. odpowiadają tylko na żądania klienta. Klient: uruchamia, aktywuje serwer, żąda obiektu DCOM i interfejsu (podaje CLSID, IID), wywołuje metody na serwerze, zwalnia interfejsy, może zamknąć lub zdeaktywować serwer.

Obiekty COM/DCOM muszą być unikalne w skali świata. Globally Unique Identifier Liczby służące do numerowania obiektów COM/DCOM nazywają się UUID, Universally Unique Identifier (Open Software Foundation). GUID, Globally Unique Identifier (Microsoft). GUID jest liczbą z zakresu 0-2^128. Przykład GUID'a zapisanego w układzie szesnastkowym "50709330-F93A-11D0-BCE4-204C4F4F5020". Ponieważ, GUID jest 128 bitowym typem danych, w języku C++ do zapisu GUID ów stosuje się strukturę typedef struct _GUID { unsigned long Data1; unsigned short Data2; unsigned short Data3; unsigned char Data4[8]; } GUID;

Globally Unique Identifier Do identyfikacji klas i interfejsów stosuje się różne typu GUID ów: CLSID, Class ID, GUID jednoznacznie identyfikujący klasę DCOM którą klient chce użyć. IID, Interface ID, GUID identyfikujący interfejs. Program służący do generowania GUID ów nazywa się guidgen.exe. Program służący do rejestrowania obiektów COM/DCOM w rejestrach nazywa się regsvr32. Przykład. Rejestracja komponentu proxy stub marshalserverps.dll. \> regsvr32 marshalserverps.dll

Komponenty DCOM Komponenty biorące udział w komunikacji między klientem a serwerem DCOM. Komponenty DCOM do komunikacji wykorzystują protokół Remote Procedure Call R. Thurlow, RPC: Remote Procedure Call Protocol Specification Version 2, RFC 5531. M. Eisler, RPCSEC_GSS Version 2, RFC 5403. GSS-API - Generic Security Services Application Programming Interface. Komponenty COM do komunikacji wykorzystują protokół LPC (Local Procedure Call). Service Control Manager (SCM) - służy do odnajdywania komponentów DCOM, uruchamia i zatrzymuje serwer COM/DCOM, wywołuje Interfejsy COM/DCOM, zarządza komunikacją między procesami. Np. SCM wykorzystuje do uruchomienia serwera interfejs IremoteActivation, wywołując na serwerze funkcje RPC RemoteActivate(). Uwaga: DCOM client stub - proxy, sever stub - stub Java RMI, Corba client stub - stub, sever stub - skeleton.

Protokół Remote Procedure Call A.R. Thurlow, RPC: Remote Procedure Call Protocol Specification Version 2,RFC 5531, May 2009. Protokól RPC został opracowany w celu wykonywania rozproszonych obliczeń. B. J. Nelson, Remote procedure call. Tech. Rep. CSL-81-9, Xerox Palo Alto Research Center, Palo Alto, Calif. 1981. Funkcje protokołu RPC: specyfikacja procedur RPC, obsługa mechanizmu kojarzenia zapytań i odpowiedzi, obsługa mechanizmu uwierzytelnienia klienta i serwera RPC. Portokół RPC korzysta w warstwie transportowej z protokołów TCP i UDP.

Protokół Remote Procedure Call Źródło. A.D. Birrell, B. J. Nelson, Implementing Remote Procedure Calls, XEROX CSL-83-7, October 1983.

Protokół Remote Procedure Call Źródło. A.D. Birrell, B. J. Nelson, Implementing Remote Procedure Calls, XEROX CSL-83-7, October 1983.

Protokół Remote Procedure Call OXID resolution: The process of obtaining the remote procedure call (RPC) binding information that is required to communicate with the object exporter. object exporter: An object container (for example, process, machine, thread) in an object server. Object exporters are callable using RPC interfaces, and they are responsible for dispatching calls to the objects they contain. object resolver: A service in an object server that supports instantiating objects, obtaining remote procedure call (RPC) binding information for object exporters, and managing object lifetimes. Źródło. MSDN, Distributed Component Object Model (DCOM) Remote Protocol Specification, 2012.

Klient żąda aktywowania obiektu na serwerze, wywołanie ORPC Źródło. MSDN, Distributed Component Object Model (DCOM) Remote Protocol Specification, 2012.

Klient żąda nowego interfejsu dla utworzonego obiektu na serwerze, wywołanie ORPC Źródło. MSDN, Distributed Component Object Model (DCOM) Remote Protocol Specification, 2012. REMQI_REQ: An ORPC call to the IRemUnknown::RemQueryInterface method on the Remote Unknown of the object exporter containing the existing object reference. ORPC_REQ: An ORPC call to the object exporter on the new interface identified by the IPID. REMREL_REQ: An ORPC call to the IRemUnknown::RemRelease method of the object exporter containing the existing object reference.

Klient pinguje serwer w celu utrzymania życia obiektu Źródło. MSDN, Distributed Component Object Model (DCOM) Remote Protocol Specification, 2012.

Java Remote Method Invocation

Java Remote Method Invocation Technologia Java RMI została opracowana tak, aby budowa aplikacji rozproszonych była podobna do budowy aplikacji niesieciowych, obowiązywała ta sama składnia i semantyka, można było posługiwać się lokalnymi obiektami Javy. Specyfikacja Java RMI http://download.oracle.com/javase/6/docs/platform/rmi/spec/rmitoc.html Typowa aplikacja RMI składają się z dwóch komponentów serwera i klienta. Serwer tworzy obiekty i udostępnia je klientowi poprzez referencje. Klient może poprzez referencje wywoływać zdalnie metody danego obiektu. Java RMI jest mechanizmem pozwalającym klientowi i serwerowi komunikować się (przekazywać parametry do zdalnych obiektów i odbierać zwracane wartości przez zdalnie wywołane metody).

Wywoływanie metod na serwerze RMI W Java RMI definicja zachowania systemu w procesie generowania usługi sieciowej (remote service) jest określona za pomocą interfejsów Javy (Java interface). Implementacja zachowania systemu i usługi jest zapisana w klasie i wykonywana na serwerze. Aby klient RMI mógł wywołać metodę na serwerze RMI musi: zlokalizować zdalny obiekt, skomunikować się z nim, przekazać parametry, odebrać dane, pobrać definicję klas z serwerów. Server RMI odwołuje się do rejestrów aby skojarzyć (bind) zdalny obiekt z jego nazwą. Klient RMI szuka obiektów po ich nazwach w rejestrach serwera RMI aby wywołać metodę obiektu na serwerze. Klient i serwer RMI mogą pobrać np. z serwera WWW definicję klas. Źródło. http://download.oracle.com/javase/6/docs/platform/rmi/spec/rmi-objmodel2.html

Lokalizacja obiektów Java RMI Klient odnajduje serwer i obiekty za pomocą: standardowych usług katalogowych (DNS) lub usług, Java Naming and Directory Interface, RMI Registry, port 1099.

Interfejsy Javy W Java RMI istnieją dwa typy klas które mogą implementować interfejs. Pierwszy typ implementuje zachowanie interfejsu, wówczas program wykonywalny jest uruchamiany na serwerze. Drugi typ klasy implementuje interfejs jako klasa proxy, klasa uruchamiana jest przez klienta.

Warstwy Java RMI Implementacja Java RMI zbudowana jest na trzech warstwach (abstraction layers): warstwa Stub and Skeleton. W tej warstwie przechwytywane są metody wywołane przez klienta i przekierowywane do serwera (remote RMI service). warstwa zdalnej referencji (Remote Reference Layer). W tej warstwie odbywa się interpretacja i zarządzanie referencjami do obiektów serwera utworzonymi przez klienta, budowane jest połączenie unicastowe (1-1). Aktywowanie nieaktywnych (uśpionych) obiektów serwera następuje za pomocą ROA (Remote Object Activation). warstwa transportowa, obsługa połączenia TCP między wirtualnymi maszynami Javy. Ponad protokołem TCP, RMI stosuje protokół JRMP (Java Remote Method Protocol). Opracowywana wersja RMI-IIOP implementuje protokoły OMG stosowane w Corbie Internet Inter-ORB Protocol i IIOP. W tej warstwie może też być zaimplementowana transmisja bezpołączeniowa w protokole UDP.

Szablon proxy Szablon proxy. Interfejs jest implementowany jako stub (klasa typu proxy), uruchamiany na hoście klienta, RealSubject jest klasą implementującą usługę na serwerze. Skeleton jest klasą pomocniczą, służy do obsługi komunikacji między stubem a obiektami serwera.

Co to jest WinSock? Windows Sockets jest implementacja gniazd BSD (University of California-Berkeley Sockets API). 1993 - edycja WinSock wersja 1.1. 1996 - WinSock wersja 2.0. Windows Sockets jest interfejsem programowym warstwy transportowej modelu OSI pozwalającym budować aplikacje sieciowe oparte o protokoły rodziny TCP/IP. Windows Sockets 2 definiuje interfejsy komunikacyjne do obsługi wielu standardów i usług: DNS, NetWare Service Advertising Protocol (SAP) name provider, standard X.509 (PKI), Quality of service, transmisji w trybie multicast, multipoint.

.Net WinSock Obszar nazw System.Net.Sockets Klasa UdpClient, IPEndPoint Obiekty klasy UdpClient dostraczają usług w protokole User Datagram Protocol. Obiekt klasy IPEndPoint reprezentuje odbiorcę danych poprzez jego adres IP i numer portu.

.Net WinSock. Aplikacja UdpEchoClient. 1. Przypisanie wartości parametrom początkowym. Parametry: ServerName, ServerPort, SendMessage. String server = m40.math.uni.opole.pl ; // nazwa lub adres IP serwera int servport = 7; // port serwera byte[] SendMessage = Encoding.ASCII.GetBytes( Hello );//konwersja stringu Hello na tab. obiektów 2. Utworzenie obiektu Client. UdpClient client = new UdpClient(); 3. Wysłanie wiadomości żądanie Echa. client.send(sendmessage, SendMessage.Length, server, servport); 4. Utworzenie obiektu IPEndPoint. IPEndPoint remoteipendpoint = new IPEndPoint(IPAddress.Any, 0);

.Net WinSock. Aplikacja UdpEchoClient. 5. Odebranie odpowiedzi Echa. byte[] rcvpacket = client.receive(ref remoteipendpoint); 6. Zamknięcie obiektu Client. client.close();

1. Przypisanie wartości parametrom początkowym..net WinSock. Aplikacja UdpEchoServer. int servport = 7; UdpClient client = null; 2. Utworzenie obiektu client. client = new UdpClient(servPort); 3. Utworzenie obiektu IPEndPoint. IPEndPoint remoteipendpoint = new IPEndPoint(IPAddress.Any, 0); for (;;) // serwer odbiera datagramy w nieskończonej pętli. 4. Odebranie wiadomości żądanie Echa. byte[] bytebuffer = client.receive(ref remoteipendpoint); 5. Wysłanie odpowiedzi Echa (wysłanie wiadomości Echo replay). client.send(bytebuffer, bytebuffer.length, remoteipendpoint); Console.WriteLine("echoed {0} bytes.", bytebuffer.length);