Sieci Komputerowe Budowa aplikacji sieciowych.

Transkrypt

Sieci Komputerowe
Budowa aplikacji sieciowych.
dr Zbigniew Lipiński
Instytut Matematyki i Informatyki
ul. Oleska 48
50-204 Opole
[email protected]
Zagadnienia
Obiektowe technologie programowania rozproszonego: DCOM, Java RMI, Corba.
Interfejs programowy Winsock.
Przykład programu klient-serwer UDP Echo (język C,C++).
Środowisko .Net, interfejs programowy Winsock.
Przykład programu klient-serwer UDP Echo (język C#).
Komunikacja z bazami danych, obiekty ADO.
Przykład programu: SqlQuerry (język ASP).
Usługi WWW (web servcies).
Standard Corba.
Z. Lipiński, Instytut Matematyki i Informatyki, Uniwersytet Opolski, Sieci Komputerowe
Co to jest COM+?
COM+ jest rozszerzeniem technologii komponentowej COM, 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ługa transakcji rozproszonych.
Typy aplikacji COM+:
•
serwer.
•
proxy (klient).
•
biblioteka.
W środowisku .Net obiekty COM+ są zdefiniowane w obszarze nazw System.EnterpriseServices.
3
Co to jest COM+?
MTS słuŜy od kolejkowania wiadomości, zarządzania pamięcią, zarządzania wątkami, zarządzania
zdarzeniami.
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 (manages object-based events).
•
Object Construction, usługa przekazuje wartość typu string do tworzonego obiektu.
•
Object Pooling, usługa kolejkuje obiekty (provides a pool of ready-made objects).
•
Private Components, chroni komponenty przed wywołaniem przez zewnętrzne procesy (protects
components from out-of-process calls).
•
Queued Components, odpowiada za asynchroniczne kolejkowanie wiadomości (provides
asynchronous message queuing).
•
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+ .
Co to jest 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 .
Podstawowe pojęcia technologii 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 – mechanizm zbierania i formatowania danych w celu przesłania ich
do innego procesu.
Co to jest Distributed Component Object Model ?
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.
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;
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 biorące udział w komunikacji między klientem a serwerem DCOM.
Komponenty DCOM do komunikacji wykorzystują protokół RPC (Remote Procedure Calls).
Komponenty COM do komunikacji wykorzystują protokół LPC (Local Procedure Calls).
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().
Co to jest Java RMI?
Java RMI jest technologią pozwalającą na budowę aplikacji rozproszonych.
Technologia Java RMI została opracowana tak, aby budowa aplikacji
•
była podobna do budowy aplikacji niesieciowych,
•
posługiwania się lokalnymi obiektami Javy,
•
obowiązywała ta sama składnia i semantyka.
Istotą technologii RMI jest to, Ŝe interfejsy określają zachowanie obiektów a klasy definiują
implementację.
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.
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 na hoście klienta.
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
klineta, 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.
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 obsługi komunikacji między stubem a obiektami serwera.
Klient odnajduje uslugi (serwer) za pomocą standardowych usług katalogowych lub usług
- Java Naming and Directory Interface.
- RMI Registry, port 1099.
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.
Co to jest WinSock?
W skład specyfikacji WinSock2 wchodzą:
- WinSock 2 API (budowa aplikacji)
- WinSock 2 Service Provider Interface (udostępnianie interfejsów WinSock 2 róŜnym protokołom
transportowym).
Komponenty Windows Open System Architecture (WOSA):
- WinSock Service Provider Interface (SPI), nazwy funkcji zaczynają się od ‘WSP’
- WinSock Provider Upcall, nazwy funkcji zaczynają się od ‘WPU’.
Nazwy funkcji Windows Sockets 2 zaczynają się do WSA.
Przykład:
WinSock 1.1: connect()
WinSock 2.0: WSAConnect().
Co to jest WinSock?
Przykładowe funkcje WinSock API:
WSAStartup() funkcja inicjuje uŜycie przez proces biblioteki WS2_32.DLL.
socket() funkcja tworzy gniazdo o określonym typie.
gethostbyname() funkcja pobiera nazwę hosta z bazy hosta.
connect() funkcja buduje połączenie do określonego gniazda.
send() –
funkcja wysyła dane do połączonego gniazda.
sendto()funkcja wysyła dane do konkretnego odbiorcy.
closesocket() –
funkcja zamyka gniazdo.
WSACleanup() –
funkcja kończy uŜycie biblioteki WS2_32.DLL.
bind() funkcja kojarzy adres lokalny hosta z gniazdem.
recvfrom() funkcja odbiera datagramy i przechowuje adres nadawcy
WSAGetLastError()- funkcja zwraca status błędu ostatniej nieudanej operacji.
Struktury WinSock API:
WSADATA struktura zawiera informacje o implementacji gniazd (Windows Sockets).
sockaddr_in struktura zawiera adres IP i numer portu odbiorcy danych.
hostent struktura jest uŜywana przez funkcje do przechowywania informacji o hoście.
Co to jest WinSock? Aplikacja UdpEchoClient. Język C, C++.
1.
Instrukcje preprocesorowe:
#include <winsock2.h>
#include <iostream>
using namespace std;
#define
#define
#define
#define
DEFAULT_PORT
DEFAULT_COUNT
DEFAULT_BUFFER_LENGTH
DEFAULT_RECIPIENT
5150
1
1
"10.60.17.109"
2. Funkcja main(). Definiowanie i inicjowanie zmiennych i obiektów.
WSADATA
SOCKET
char
int
SOCKADDR_IN
int
DWORD
char
wsd;
s;
*sendbuf = NULL;
iRet, dwRecipientSize;
recipient;
iPort
= DEFAULT_PORT;
// Numer portu odbiorcy
dwCount = DEFAULT_COUNT,
// Liczba wiadomosci do wyslania
dwLength = DEFAULT_BUFFER_LENGTH;
// Dlugosc bufora do wysylania
chRecipient[128]= DEFAULT_RECIPIENT; // Adres IP lub nazwa hosta odbiorcy
Co to jest WinSock? Aplikacja UdpEchoClient. Język C, C++.
WSAStartup(MAKEWORD(2, 2), &wsd);
s = socket(AF_INET, SOCK_DGRAM, 0);
recipient.sin_family = AF_INET;
recipient.sin_port = htons((short)iPort);
recipient.sin_addr.s_addr = inet_addr(chRecipient);
sendbuf = new char;
memset(sendbuf, 'Q', dwLength);
connect(s, (SOCKADDR *)&recipient, sizeof(recipient));
connect
iRet = send(s, sendbuf, dwLength, 0);
cout << "Do " << inet_ntoa(recipient.sin_addr) << " wyslano wiadomosc: " << *sendbuf << endl;
dwRecipientSize = sizeof(recipient);
iRet = recvfrom(s, sendbuf, dwLength, 0, (SOCKADDR *)&recipient, (int*) &dwRecipientSize);
cout << "Od " << inet_ntoa(recipient.sin_addr) << " odebrano wiadomosc: " << *sendbuf <<
endl;
closesocket(s);
delete sendbuf;
WSACleanup();
Co to jest WinSock? Aplikacja UdpEchoServer. Język C, C++.
1.
Instrukcje preprocesorowe.
#include <winsock2.h>
#include <iostream>
using namespace std;
#define DEFAULT_PORT
#define DEFAULT_COUNT
#define DEFAULT_BUFFER_LENGTH
5150
1
1 // 4096
2. Funkcja main(). Definiowanie i inicjowanie zmiennych i obiektów.
WSADATA
SOCKET
char
int
DWORD
SOCKADDR_IN
int
DWORD
char
wsd;
s;
*recvbuf = NULL;
iRet;
dwSenderSize;
sender, local;
iPort
= DEFAULT_PORT;
// Numer portu odbiorcy
dwCount = DEFAULT_COUNT,
// Liczba wiadomości do odebrania
dwLength = DEFAULT_BUFFER_LENGTH; // Długość bufora do obioru
chInterface[32];
// IP hosta do obioru datagramów
Co to jest WinSock? Aplikacja UdpEchoServer. Język C, C++.
WSAStartup(MAKEWORD(2,2), &wsd);
s = socket(AF_INET, SOCK_DGRAM, 0);
local.sin_family = AF_INET;
local.sin_port = htons((short)iPort);
local.sin_addr.s_addr = htonl(INADDR_ANY);
bind(s, (SOCKADDR *)&local, sizeof(local));
recvbuf = new char;
dwSenderSize = sizeof(sender);
iRet = recvfrom(s, recvbuf, dwLength, 0, (SOCKADDR *)&sender, (int*) &dwSenderSize);
cout << "Od " << inet_ntoa(sender.sin_addr) << " odebrano wiadomosc: " << *recvbuf << endl;
memset(recvbuf, 'Z', dwLength);
connect(s, (SOCKADDR *)&sender, sizeof(sender));
iRet = send(s, recvbuf, dwLength, 0);
cout << " Do " << inet_ntoa(sender.sin_addr) << " wyslano wiadomosc: " << *recvbuf << endl;
closesocket(s);
delete recvbuf;
WSACleanup();
Programowanie aplikacji sieciowych w .Net. WinSock
Obszar nazw System.Net.Sockets
Klasa UdpClient, IPEndPoint
Obiekt klasy UdpClient dostraczają usług w protokole User Datagram Protocol.
Obiekt klasy IPEndPoint reperezentuje 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 wiadomosci ‘Ŝądanie Echa’.
client.Send(sendPacket, sendPacket.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);
Co to jest ADO, ActiveX Data Objects?
ADO jest
•
technologią firmy Microsoft.
•
komponentem Active-X (ACTIVE eXchange).
•
automatycznie instalowany z serwerem www Microsoft IIS.
•
interfejsem programowym dostępu do baz danych.
Kontrolka Active-X - wcześniejsza nazwa kontrolka OLE, jest przykładem obiektu typu COM,
komponent realizujący określoną funkcjonalność, który moŜe być zagnieŜdŜany w aplikacje, okna
dialogowe, strony HTML.
Plik z rozszerzeniem *.ocx
Obiekty ADO:
ADO Command
ADO Connection
ADO Error
ADO Field
ADO Parameter
ADO Property
ADO Record
ADO Recordset
ADO Stream
ADO DataTypes
Co to jest ActiveX Data Objects?
Obiekt Command – stosowany do wykonania kwerend do bazy danych w celu utworzenia, uaktualnienia,
dodania, pobrania, usunięcia (create, add, retrieve, delete, update) rekordu.
JeŜeli kwerenda słuŜyła do pobrania danych, to dane są zwracane jako obiekt RecordSet (zbiór rekordów).
Oznacza to, Ŝe aby odzyskać dane z obiektu (RecordSet) naleŜy posłuŜyć się metodami, zdarzeniami,
properties, collections, obiektu Recordset.
Przykład uŜycia:
ProgID
set objCommand=Server.CreateObject("ADODB.command")
Obiekt Connection –obiekt słuŜy do budowy i otwarcia połączenia z baza danych.
Przykład uŜycia:
ProgID
set objConnection=Server.CreateObject("ADODB.connection")
Obiekt Error - obiekt zawiera dane o błędach powstałych przy wykonaniu pojedynczych operacji
na bazie danych.
Przykład uŜycia:
for each objErr in objConn.Errors
response.write(objErr.Description )
response.write(objErr.HelpContext)
response.write(objErr.HelpFile)
response.write(objErr.NativeError)
response.write(objErr.Number)
response.write(objErr.Source)
response.write(objErr.SQLState)
next
Obiekt Field – obiekt przechowuje informacje o kolumnie danych w obiekcie Recordset.
Przykład uŜycia:
set objField=Server.CreateObject("ADODB.field")
Obiekt Parameter – obiekt słuŜy do uzyskania informacji o parametrach uŜytych w procedurach
składowanych (stored procedures) lub kwerendach.
Cztery typy parametrów: input, output, input/output, return.
Przykład składni:
objectname.property
objectname.method
Obiekt Property - obiekt reprezentuje dynamiczne charakterystyki obiektów ADO zdefiniowanych
dla róŜnych typów baz danych (db providers).
Przykład uŜycia:
set objProperty=Server.CreateObject("ADODB.property")
Obiekt Record (ADO ver. 2.5) – obiekt słuŜy do przechowania wiersza danych z Recordsetu,
katalogu lub pliku.
Przykład uŜycia:
objectname.property
objectname.method
Obiekt Recordset - obiekt słuŜy do przechowywania danych (zbioru rekordów) z tabeli. Obiekt
Recordset składa się z rekordów i kolumn (pól, ang. Fields).
Recordset moŜe uaktualnić dane na dwa sposoby: immediate updating, batch updating.
Przykład uŜycia:
set objRecordset=Server.CreateObject("ADODB.recordset")
Obiekt Stream (ADO version 2.5) – obiekt stosowany do czytania, zapisywania, zarządzania
strumieniem danych.
Kursory ADO są parametrami metod obiektów ADO.
Kursory definiują usługi kursora (cursor service).
Typy kursorów ADO:
Dynamic cursor – pozwala na przegląd operacji dodania, zmiany, usunięcia wykonane przez innego
uŜytkownika.
Keyset cursor – usługa podobna do usługi kursora ‘dynamic’, za wyjątkiem: braku moŜliwości
przeglądania operacji dodania przez innego uŜytkownika, braku dostępu do rekordów które inny
uŜyytkownik usunął. Dane zmienione przez innego uŜytkownika są widoczne.
Static cursor – pozwala dokonać ‘statycznego’ kopiowania rekordsetów w celu znalezienia danych
lub wygenerowania raportów. Operacje dodania, zmiany, usunięcia wykonane przez innego
uŜytkownika są niewidoczne.
Typ kurosora dostępny tylko dla obiektów typu klient rekordset.
Forward-only cursor – pozwala przejrzeć rekordset. Operacje dodania, zmiany, usunięcia wykonane
przez innego uŜytkownika są niewidoczne.
Kursor Forward-only moŜe być ustawiony poprzez property ‘CursorType’ lub poprzez parametr
‘CursorType’ w metodzie Open().
Proces budowy połączenia z bazą danych za pomocą obiektów ADO:
1.
Utworzenie połączenia ADO z bazą danych.
2.
Otwarcie połączenia.
3.
Utworzenie recordseta.
4.
Otwarcie recordseta.
5.
Pobranie danych do recordseta.
6.
Zamknięcie recordseta.
7.
Zamknięcie połączenia.
1-2. Utworzenie i otwarcie połączenia z bazą danych. Baza northwind.mdb.
set conn=Server.CreateObject("ADODB.Connection")
conn.Provider="Microsoft.Jet.OLEDB.4.0"
conn.Open "c:/webdata/northwind.mdb”
Utworzenie i otwarcie połączenia z bazą danych za pomocą komponentu ODBC.
set conn=Server.CreateObject("ADODB.Connection")
conn.Open "northwind"
3. Utworzenie recordseta.
set rs=Server.CreateObject("ADODB.recordset")
4-5. Otwarcie i pobranie danych do recordseta.
Czytanie dnych z rekordseta.
rs.Open "Select * from Customers", conn
for each x in rs.fields
response.write(x.name)
response.write(" = ")
response.write(x.value)
next
6. Zamknięcie recordseta.
rs.close
7. Zamknięcie połączenia.
conn.close
Co to jest ASP?
ASP oznacza skrót Active Server Pages
ASP jest programem wykonywanym przez komponent IIS (Internet Information Services).
Plik *.asp moŜe zawierać: tagi języka HTML, XML, skrytpy (VB scirpt, Java script, ….) .
Skrypty w plikach *.asp są wykonywane na serwerze.
śądane strony *.asp przez przegladarkę internetową są przekazywane przez serwer WWW do silnika ASP,
skrypty są wykonywane i do klienta (przegladarki internetowej) zwracane są dane w formie HTML bez skryptów.
Zaletą takiego rozwiązania jest, Ŝe przeglądarki internetowe nie muszą obsługiwać Ŝadnych języków
skryptowych.
Co to jest ASP?
Skrypty w plikach ASP zawarte są między znakami <% a… %>.
Przykład pliku *.asp.
<html>
<body>
<%
response.write("Hello World!")
%>
</body>
</html>
Co to jest ASP?
Domyślnym językiem skryptowym dla stron ASP jest VBScript.
Aby zagnieździć skrypty pisane w innych językach naleŜy uŜyć atrybutu language.
<%@ language="javascript"%>
<html>
<body>
<%
Response.Write("Hello World!")
%>
</body>
</html>
Co to jest ASP?
Przykład: strona www wykonana w ASP.
<html>
<body>
<%
dim h
h=hour(now())
response.write("<p>" & now())
response.write("</p>")
If h<12 then
response.write("Jest przed południem")
else
response.write("Jest po południu!")
end if
%>
</body>
</html>
Usługi WWW
Web Services Architecture, W3C Working Group Note 11 February 2004
Usługa WWW (ang. web service) jest systemem aplikacyjnym zaprojektowanym w celu wspamogania
wymiany danych między węzłami w sieciach komputerowych. System aplikacyjny usługi WWW posiada
interfejs zaprojekowany w języku WSDL. Inne systemy aplikacyjne wymieniają wiadomości z systemem
usługi WWW za pomocą protokołu SOAP (tzn. wiadomości przesyłane są za pomocą protokołu HTTP,
dane są w formacie XML).
Formalną definicję usługi WWW moŜna znaleźć w specyfikacji języka WSDL http://www.w3.org/TR/wsdl
Usługa WWW korzysta z następujących protokołów i standardów:
• HTTP (ang. HyperText Transfer Protocol)
• SOAP (ang. Simple Object Access Protocol)
• UDDI (ang. Universal Description, Discovery and Integration)
• HTML (ang. HyperText Markup Language)
• XML
(ang. eXtensible Markup Language) (xml, xml dtd, xml schema)
• WSDL (ang. Web Services Description Language)
Simple Object Access Protocol (SOAP)
SOAP jest protokolem słuŜącym aplikacjom sieciowym na wymianę danych w protokole HTTP w których
struktura danych określona jest w formacie XML.
SOAP jest elementem architektury projektu Microsoft .NET.
Większość aplikacji sieciowych komunikuje się w Internecie wykorzystując standardowe komponenty takie,
jak obiekty DCOM, obiekty CORBA. Obiekty te korzystają z protokolu RPC (ang. Remote Procedure
Calls). Wadą tego sposobu komunikacji jest to, Ŝe firewalle i serwery proxy blokują tego typu komunikację.
Firewalle i serwery proxy zazwyczaj nie blokują komunikacji w protokole HTTP, tzn. port nasłuchiwania
serwera www jest zazwyczaj otwarty. Protokół SOAP zostal stworzony przez firmę Microsoft w celu
wymiany danych w protokole HTTP i foramcie XML.
Cechy protokołu SOAP
• jest protokołem warstwy aplikacji w modelu OSI,
• jest protokołem zaprojektowanym do komunikacji w Internecie,
• definiuje format przesyłanych wiadomości,
• jest protokołem niezaleŜnym od platformy systemowej,
• jest niezaleŜny od języka implementacji usługi WWW,
• jest oparty o język XML,
• nie jest blokowany przez firewall’e.
Wiadomość SOAP ma strukturę dokumentu XML i zawiera następujące elementy (tagi):
• envelope, zawiera treść wiadomości,
• header, element opcjonaly, zawiera informacje nagłówkowe,
• body, zawiera zapytanie i odpowiedź.
Podstawowe zasady skladni protokolu SOAP:
• wiadomość SOAP musi być w formacie XML,
• wiadomość SOAP musi zawierac tag SOAP Envelope,
• wiadomość SOAP moŜe zawierać tag SOAP Header,
• wiadomość SOAP musi zawierać tag SOAP Body,
• wiadomość SOAP musi korzystać z obszaru nazw SOAP Envelope,
• wiadomość SOAP musi korzystać z obszaru nazw SOAP encoding,
• wiadomość SOAP nie musi zawierać odnośnikow do dokumentow DTD,
• wiadomość SOAP nie musi zawierać instrukcji xml (ang. XML Processing Instructions).
Przykład: struktura widomości SOAP.
Pełna struktura widomości SOAP opisana jest w specyfikacji SOAP http://www.w3.org/TR/soap/
<soap:Envelope>
<soap:Body>
<NazwaTagu1>
<Element1> … </Element1>
</NazwaTagu1>
</soap:Body>
</soap:Envelope>
Web Services Description Language
Dokument WSDL słuŜy do opisu usługi WWW.
Dokument WSDL umoŜliwia odnalezienie usługi WWW w Internecie.
Dokument WSDL jest dokumentem XML.
Specyfikacja języka WSDL znajduje się pod adresem http://www.w3.org/TR/wsdl/
Struktura dokumentu WSDL:
<portType>
operacje wykonywane przez usługę WWW
<message>
wiadomosci wykorzystywane przez usługę WWW
<types>
typy danych wykorzystywane przez usługę WWW
<binding>
protokoly komunikacyjne wykorzystywane przez usługę WWW.
Przyklad: prosty dokument wsdl.
<definitions>
<types> definition of types........</types>
<message> definition of a message....</message>
<portType> definition of a port.......</portType>
<binding> definition of a binding....</binding>
</definitions>
Usługa WWW: Silnia
1. Uruchomić serwer WWW (Microsoft IIS).
2. Umieścić w katalogu \wwwroot\ plik silnia.asmx (C:\Inetpub\wwwroot\silnia.asmx )
3. Utworzyć Web Service Proxy.
\>wsdl http://adresSerweraWWW/silnia.asmx
wynik: silnia.cs
4. Utworzyć dynamicznie dołączaną biblitekę silnia.dll, tzn. skompilować plik silnia.cs.
C:\Inetpub\wwwroot >csc /t:library silnia.cs
wynik: silnia.dll
5. Skompilować program SilniaTest.cs z linkiem do biblioteki silnia.dll
C:\Inetpub\wwwroot> csc /r:silnia.dll SilniaTest.cs
Rezultat: SilniaTest.exe
6. Test usługi WWW.
Uruchomić program SilniaTest.exe (plik silnia.dll umieścić w tym samym katalogu co SilniaTest.exe ).
C:\> SilniaTest.exe 8
Rezultat:
C:\> Usluga silnia. 8! = 40320
Usługa silnia
Plik silnia.asmx
<%@ WebService Language="c#" Class="Silnia"%>
using System;
using System.Web.Services;
[WebService(Namespace="http://localhost/")]
public class Silnia : WebService
{
[WebMethod]
public int silnia(int n)
{
if (n == 0)
return 1;
else
return (n * silnia(n - 1));
}
}
Plik silnia.cs
//-----------------------------------------------------------------------------// <auto-generated>
//
This code was generated by a tool.
//
Runtime Version:2.0.50727.3603
//
//
Changes to this file may cause incorrect behavior and will be lost if
//
the code is regenerated.
// </auto-generated>
//-----------------------------------------------------------------------------using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
//
// This source code was auto-generated by wsdl, Version=2.0.50727.3038.
//
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.3038")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name="SilniaSoap", Namespace="http://localhost/")]
public partial class Silnia : System.Web.Services.Protocols.SoapHttpClientProtocol {
private System.Threading.SendOrPostCallback silniaOperationCompleted;
/// <remarks/>
public Silnia() {
this.Url = "http://localhost/silnia.asmx";
}
Plik silnia.cs
/// <remarks/>
public event silniaCompletedEventHandler silniaCompleted;
/// <remarks/>
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://localhost/silnia",
RequestNamespace="http://localhost/", ResponseNamespace="http://localhost/",
Use=System.Web.Services.Description.SoapBindingUse.Literal,
ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
public int silnia(int n) {
object[] results = this.Invoke("silnia", new object[] {
n});
return ((int)(results[0]));
}
/// <remarks/>
public System.IAsyncResult Beginsilnia(int n, System.AsyncCallback callback, object asyncState) {
return this.BeginInvoke("silnia", new object[] {
n}, callback, asyncState);
}
/// <remarks/>
public int Endsilnia(System.IAsyncResult asyncResult) {
object[] results = this.EndInvoke(asyncResult);
return ((int)(results[0]));
}
/// <remarks/>
public void silniaAsync(int n) {
this.silniaAsync(n, null);
}
Plik silnia.cs
/// <remarks/>
public void silniaAsync(int n, object userState) {
if ((this.silniaOperationCompleted == null)) {
this.silniaOperationCompleted = new
System.Threading.SendOrPostCallback(this.OnsilniaOperationCompleted);
}
this.InvokeAsync("silnia", new object[] {
n}, this.silniaOperationCompleted, userState);
}
private void OnsilniaOperationCompleted(object arg) {
if ((this.silniaCompleted != null)) {
System.Web.Services.Protocols.InvokeCompletedEventArgs invokeArgs =
((System.Web.Services.Protocols.InvokeCompletedEventArgs)(arg));
this.silniaCompleted(this, new silniaCompletedEventArgs(invokeArgs.Results, invokeArgs.Error,
invokeArgs.Cancelled, invokeArgs.UserState));
}
}
/// <remarks/>
public new void CancelAsync(object userState) {
base.CancelAsync(userState);
}
}
Plik silnia.cs
/// <remarks/>
public delegate void silniaCompletedEventHandler(object sender, silniaCompletedEventArgs e);
/// <remarks/>
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
public partial class silniaCompletedEventArgs : System.ComponentModel.AsyncCompletedEventArgs {
private object[] results;
internal silniaCompletedEventArgs(object[] results, System.Exception exception, bool cancelled, object
userState) :
base(exception, cancelled, userState) {
this.results = results;
}
/// <remarks/>
public int Result {
get {
this.RaiseExceptionIfNecessary();
return ((int)(this.results[0]));
}
}
}
Usługa silnia
Plik SilniaTest.cs
using System;
class SilniaTest
{
public static void Main(string[] argv)
{
Silnia ms = new Silnia();
int n = Convert.ToInt16(argv[0]);
int wynik = ms.silnia(n);
Console.WriteLine("Usługa silnia. {0}! = {1}",n, wynik );
}
}
Usługa silnia
Usługa silnia
Usługa silnia
Plik silnia.asmx
Standard Corba
CORBA jest komercyjnym standardem Object Management Group (OMG).
http://www.omg.org/
Głównym celem grupy OMG jest upowszechnianie technologii zorientowanych obiektowo słuŜących
budowie duŜych, rozproszonych systemów informatycznych.
Aby zrealizować swoją misję OMG stworzyła Model Referencyjny OMA (Object Management
Architecture Reference Model) definiujący standard architektury rozproszonych systemów
Informatycznych, podstawy dla innych standardów i specyfikacji:
•
Meta Object Facility (MOF) specification,
•
Unified Modeling Language (UML) specification,
•
XML Metadata Interchange (XMI) specification,
•
Common Warehouse Metamodel (CWM) specification,
•
Common Object Request Broker Architecture (CORBA) specification,
ułatwiających tworzenia aplikacji w środowisku rozproszonym.
Standard Corba
W modelu referencyjnym OMA komponenty systemu: klient, serwer, baza danych, interfejs są
obiektami.
Obiektem jest dowolna encja która dostarcza usług Ŝądanych przez klienta.
Główną zasadą modelu OMA jest to, Ŝe kaŜdy obiekt jest albo obiektem Ŝądającym usługi (klientem),
obiektem realizującym usługę (serwerem) lub jednym i drugim.
Podstawowym elementem architektury w modelu OMA jest broker poprzez który obiekty komunikują
się między sobą.
Komunikacja między obiektami odbywa sie poprzez interfejsy.
Standard Corba
System rozproszony to system typu klient-serwer w którym występuje duŜa ilość klientów i serwerów
(multitier client-server system).
Corba jest implementacją warstwy pośredniej (middleware layer) w trójwarstwowej architekturze
systemu informatycznego:
•
Warstwa Prezentacji (Presentation Layer)
•
Warstwa Pośrednia (middleware, Buisness Logic Layer)
•
Warstwa Danych (Data Layer).
Technologia wykorzystana do opracowania standardu Corby jest:
•
zorientowana obiektowo
•
oparta o zorientowane obiektowo interfejsy, interfejsy oddzielone są od implementacji obiektów
(obiektów w części klienta, serwera, brokera)
•
niezaleŜna od platformy systemowej
•
niezaleŜna od języka w którym implementowane są aplikacje (klient, serwer)
•
niezaleŜna od lokalizacji klienta i serwera. Zadaniem brokera jest odebrać zapytanie (request) od
klienta, znaleźć serwer, przekazać zapytanie na serwer, przekazać odpowiedź klientowi.
Standard Corba
Zadania brokera:
•
zarządzanie połączeniem klient-serwer
•
zarządzanie pamięcią
•
przekazywanie zapytań i odpowiedzi między klientem a serwerem
•
kontrola dostępu do usług
•
obsługa błędów w komunikacji między klientem a serwerem
•
zarządzanie jakością połączenia (QoS ).
Standard Corba
W modelu OMA rozróŜnia się cztery kategorie interfejsów:
•
Object Services, interfejsy wykorzystywane przez aplikacje pracujące w środowisku
rozproszonym.
•
Common Facilities, interfejsy do usług wykorzystywanych przez aplikacje niezaleŜnie od
ich komercyjnego zastosowania.
•
Domain Interfaces, interfejsy specyficzne dla aplikacji z konkretnych podobszarach
funkcjonalnych.
•
Application Interfaces, niestandaryzowane interfejsy dla konkretnych aplikacji.
Model Referencyjny OMA rozróŜnia cztery kategorie obiektów:
•
Obiekty ORB (Object Request Broker)
•
Obiekty usług (CORBAservices)
•
Obiekty standardowych usług (Common Facilities - CORBAfacilities)
•
Obiekty aplikacji (Application Objects)
Standard Corba
Obiekty Corby są to obiekty z interfejsami zdefiniowanymi w języku IDL.
Obiekty Corby mają róŜną reprezentację po stronie serwera i klienta:
•
Implementacja Obiektów Corby po stronie serwera nazywa sie servant’em (aplikacja ‘serwującą’
usługi). Serwer uŜywa obiektów Corby zaimplementowanych w konkretnym języku (np. C++, Java).
Klasa w której zaimplementowany jest dany obiekt Corby nazywa sie ‘implementation class’.
Servant jest instancja klasy implementującej (implementation class) Obiekt Corby w konkretnej
aplikacji (uwaga: servant nie jest Obiektem Corby, jest implementacja obiektu Corby).
•
Klient tworzy obiekt proxy w celu wykorzystania obiektów na serwerze (servant’ow).
Klient który chce wykorzystać obiekt zaimplementowany przez serwer (wywołać servant’a) przekazuje
wszystkie zapytania (requests) poprzez brokera (ORB).
Standard Corba
Schemat generowania zapytań (requests) przez klienta do serwera wygląda następująco:
•
klient wywołuje lokalnie metodę na obiekcie proxy
•
ORB ‘pakuje’ parametry z jakimi została wywołana dana metoda i przekazuje na server
•
ORB wywołuje właściwą metodę na servan’cie
•
ORB zwraca wynik działania metody na serwerze do klienta.
Servant musi być połączony z ORB tak, aby ORB mógł wywoływać metody na servan’cie gdy
klient generuje zapytanie (request). To połączenie jest realizowane poprzez Portable Object
Adapter (POA).
POA decyduje który servant będzie wywołany gdy przychodzi request od klienta i wywołuje
danego servant’a.
Konfiguracja i kontrola polaczenia servant-ORB odbywa sie za pomocą POA Manager’ów.
Standard Corba
Fazy tworzenia sie obiektu POA na serwerze i budowy komunikacji z servant’em:
•
Aplikacja na serwerze pobiera referencje od root POA.
•
Aplikacja tworzy Policy dla tworzonego POA (przykłady policies: thread policy, lifespan
policy, object uniquenes policy).
•
Aplikacja tworzy ‘child’ POA z root POA (za pomocą metody create_POA() ).
•
Tworzenie i aktywowanie servanta.
•
Aktywowanie POA Managera (POA Manager to obiekt który kontroluje stan POA, tzn.
kontroluje czy Ŝadania klienta są kolejkowane, przetwarzane czy odrzucone).
Aktywowanie POA Managera następuje poprzez wywołanie metody activate():
rootPOA.the_POAManager().activate();
Standard Corba
Policy (Policies) to zbiór obiektów przypisanych root POA do kontroli zachowań POA i obiektów którymi
POA zarządza (POA wygenerowane z POA rodzica nie dziedziczą Policy).
W wersji specyfikacji Corba 2.0 dodano protokół Internet inter-ORB Protocol (IIOP) wykorzystujący do
przesyłania widomości przez Internet.
Protokół IIOP jest implementacją dla TCP/IP abstrakcyjnego protokołu General inter-ORB protocol (GIOP),
tzn. IIOP wykorzystuje rodzinę protokołów TCP/IP poniŜej warsty Sesji modelu OSI.
Standard Corba
Standard Corby obejmuje następujące specyfikacje:
•
Specyfikacja brokera, Object Request Broker (ORB) Core Specification
•
Specyfikacja protokołów komunikacyjnych GIP, IIOP (Interoperbillity GIOP, IIOP Specification)
•
Specyfikacja języka IDL (Interface Definition Languae spcification)
•
Specyfikacje ‘mapowania’ języka IDL na języki programowania (np. C++, Java, Smaltalk, Ada, ...)
•
Specyfikacja interfejsów SII, DII (Static Interface Invocation, Dynamic Invocation Interface
specification)
•
Specyfikacja interfejsów SSI, DSI (Static Skeleton Interface, Dynamic Skeleton Interface)
•
Specyfikacje POA (Portable Object Adapter specification)
•
Zbiór specyfikacji serwisów Corby.
Brokerzy i narzędzia Corby
Przykładowe narzędzia (kompilatory IDL, brokerzy) do budowy aplikacji w Corbie:
•
Progress® Orbacus, Progress® Orbix
http://web.progress.com/
•
Visibroker®
http://www.borland.com/
Zgodny ze specyfikacją Corba 3.0.
Interpeter IDL dla Java, C+, C#.
•
The Inter-Language Unification system (ILU) is a multi-language object interface system
ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
•
omniORB,
http://omniorb.sourceforge.net/
•
MICO,
http://www.mico.org/

Sieci Komputerowe Budowa aplikacji sieciowych.

Transkrypt

Podobne dokumenty

Schemat blokowy dla algorytmu iteracyjnego i rekurencyjnego

Istnienie średnich czasowych oraz ich interpretacja fizyczna Prof. dr

egzamin pisemny - test cz.I

Opolski Związek Piłki Nożnej Zgoda na rozpowszechnianie