Budowa obiektowych aplikacji sieciowych

Transkrypt

Budowa obiektowych aplikacji sieciowych
dr Zbigniew Lipiński
Instytut Matematyki i Informatyki
ul. Oleska 48
50-204 Opole
[email protected]
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+ .
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.
Podstawowe pojęcia modelu COM/DCOM:
klient –
program, który wywołuje metody na serwerze COM/DCOM.
serwer -
program, który udostępnia obiekty COM/DCOM klientowi.
interfejs –
wskazuje na grupę funkcji, które są wywoływane za pomocą obiektów COM/DCOM.
klasa COM/DCOM –
zwana ko-klasą, definiuje obiekt, który implementuje interfejsy COM/DCOM.
obiekt 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.
Globally Unique Identifier
Obiekty COM/DCOM muszą być unikalne w skali świata.
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
Java RMI, Corba
client stub - proxy,
client stub - stub,
sever 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.
Źródło. A.D. Birrell, B. J. Nelson, Implementing Remote Procedure Calls, XEROX CSL-83-7, October 1983.
Źródło. A.D. Birrell, B. J. Nelson, Implementing Remote Procedure Calls, XEROX CSL-83-7, October 1983.
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
Klient żąda nowego interfejsu dla utworzonego obiektu na serwerze,
wywołanie ORPC
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
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();
.Net WinSock. Aplikacja UdpEchoServer.
1. Przypisanie wartości parametrom początkowym.
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);

Budowa obiektowych aplikacji sieciowych

Transkrypt

Podobne dokumenty

Plan wykładu

Marcin Skowronek - Studia Informatica

Instrukcja - Home Page of Ireneusz (Irek) SZCZEŚNIAK