ProgSieciowe-15-BudowaAplikacjiSieciowych-2009-10-22

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.

COM+ jest rozszerzeniem technologii komponentowej COM (Component Object Model), umo

liwiaj

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.

rodowisku .Net obiekty COM+ s

zdefiniowane w obszarze nazw System.EnterpriseServices.

Co to jest COM+?

MTS słu

y od kolejkowania wiadomo

ci, zarz

dzania pami

, 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 COM+?

DCOM – model, technologia firmy Microsoft słu

żą

ca do budowy systemów rozproszonych (distributed

systems). Obiekty DCOM mog

komunikowa

dzy sob

poprzez sieci internetowe.

DCOM jest rozszerzeniem modelu COM.

Technologia COM/DCOM jest niezale

na od j

zyka implementacji.

zyk i kompilator MIDL (Microsoft Interface Definition Language) słu

y do specyfikowania interfejsów

dzy serwerem a klientem, definiowania metod i obiektów COM/DCOM.

Co to jest Distributed Component Object Model (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 (DCOM)?

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.

Co to jest Distributed Component Object Model ?

Obiekty COM/DCOM musz

unikalne w skali

wiata.

Liczby słu

żą

ce do numerowania obiektów COM/DCOM nazywaj

•

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

Co to jest Distributed Component Object Model ?

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

•

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

Co to jest Distributed Component Object Model ?

Komponenty DCOM do komunikacji wykorzystuj

protokół Remote Procedure Call (RPC, RFC 5513,

RPCSEC_GSS, 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

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.

Co to jest Distributed Component Object Model ?

Komponenty bior

ce udzia

w komunikacji mi

dzy klientem a serwerem DCOM.

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 wartwie transportowej z protokołów TCP i UDP.

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,

•

na było posługiwa

lokalnymi obiektami Javy.

Specyfikacja Java RMI

http://download.oracle.com/javase/6/docs/platform/rmi/spec/rmiTOC.html

Typowa aplikacja RMI składaja 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 mechnizmem pozwalaj

cym klientowi i serwerowi komunikowa

(przekazywa

parametry do

zdalnych obiektów i odbiera

zwracane warto

ci przez zdalnie wywołane metody).

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.

Co to jest Java RMI?

Aby klient RMI mógł wywoła

metod

na serwerze RMI musi:

•

zlokalizowa

zdalny obiekt ,

•

zkomunikowa

z nim (przekaza

parametry, odebra

dane),

•

pobra

definicj

klas z serwerów.

Co to jest Java RMI?

•

Server RMI odwołuje si

do rejestó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.

Klient odnajduje serwer i obiekty za pomoc

•

standardowych usług katalogowych (DNS) lub usług,

•

Java Naming and Directory Interface,

•

RMI Registry, port 1099.

ródło. http://download.oracle.com/javase/6/docs/platform/rmi/spec/rmi-objmodel2.html

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

zaimplementowana transmisja bezpoł

czeniowa w protokole UDP.

Co to jest Java RMI?

Szablon proxy.

Interfejs jest implementowany jako stub (klasa typu proxy), uruchamiany na ho

cie klienta, RealSubject jest klas

implementuj

usług

na serwerze.

Skeleton jest klas

pomocnicz

, słu

y do obsługi komunikacji mi

dzy stubem a obiektami serwera.

Co to jest Java RMI?

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.

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

od ‘WSP’

•

WinSock Provider Upcall, nazwy funkcji zaczynaj

od ‘WPU’.

Nazwy funkcji Windows Sockets 2 zaczynaj

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?

Instrukcje preprocesorowe:

Co to jest WinSock? Aplikacja UdpEchoClient. J

zyk C, C++.

WSADATA wsd;

SOCKET s;

char

*sendbuf = NULL;

int

iRet, dwRecipientSize;

SOCKADDR_IN recipient;

int

iPort = DEFAULT_PORT;

// Numer portu odbiorcy

DWORD

dwCount = DEFAULT_COUNT,

// Liczba wiadomosci do wyslania

dwLength = DEFAULT_BUFFER_LENGTH;

// Dlugosc bufora do wysylania

char

chRecipient[128]= DEFAULT_RECIPIENT;

// Adres IP lub nazwa hosta odbiorcy

#include

<winsock2.h>

#include

using namespace

std;

#define

DEFAULT_PORT 5150

#define

DEFAULT_COUNT 1

#define

DEFAULT_BUFFER_LENGTH 1

#define

DEFAULT_RECIPIENT

"10.60.17.109"

2. Funkcja main(). Definiowanie i inicjowanie zmiennych i obiektów.

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

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;

closesocke

t(s);

delete

sendbuf;

WSACleanup

();

Instrukcje preprocesorowe.

Co to jest WinSock? Aplikacja UdpEchoServer. J

zyk C, C++.

#include <winsock2.h>

#include <iostream>

using namespace

std;

#define

DEFAULT_PORT 5150

#define

DEFAULT_COUNT 1

#define

DEFAULT_BUFFER_LENGTH 1

// 4096

WSADATA

wsd;

SOCKET

char

*recvbuf = NULL;

int

iRet;

DWORD

dwSenderSize;

SOCKADDR_IN

sender, local;

int

iPort = DEFAULT_PORT;

// Numer portu odbiorcy

DWORD

dwCount = DEFAULT_COUNT,

// Liczba wiadomo

ci do odebrania

dwLength = DEFAULT_BUFFER_LENGTH;

// D

ugo

ść

bufora do obioru

char

chInterface[32];

// IP hosta do obioru datagramów

2. Funkcja main(). Definiowanie i inicjowanie zmiennych i obiektó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

();

1. Przypisanie warto

ci parametrom pocz

tkowym. Parametry:

ServerName, ServerPort, SendMessage

2. Utworzenie obiektu Client.

3. Wysłanie wiadomosci ‘

żą

danie Echa’.

4. Utworzenie obiektu IPEndPoint.

.Net. WinSock. Aplikacja UdpEchoClient.

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

UdpClient client =

new

UdpClient();

client.Send(SendMessage, SendMessage.Length, server, servPort);

IPEndPoint remoteIPEndPoint =

new

IPEndPoint(IPAddress.Any, 0);

1. Przypisanie warto

ci parametrom pocz

tkowym.

2. Utworzenie obiektu client.

3. Utworzenie obiektu IPEndPoint.

4. Odebranie wiadomo

ci “

żą

danie Echa”.

5. Wysłanie odpowiedzi Echa (wysłanie wiadomo

ci Echo replay).

int

servPort = 7;

UdpClient client =

null

;

client =

new

UdpClient(servPort);

IPEndPoint remoteIPEndPoint =

new

IPEndPoint(IPAddress.Any, 0);

for

(;;)

// serwer odbiera datagramy w niesko

czonej p

tli.

byte

[] byteBuffer = client.Receive(

ref

remoteIPEndPoint);

client.Send(byteBuffer, byteBuffer.Length, remoteIPEndPoint);

Console.WriteLine(

"echoed {0} bytes."

, byteBuffer.Length);

.Net. WinSock. Aplikacja UdpEchoServer.

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

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 ADO, 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.

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

metodami, zdarzeniami, properties,

collections, obiektu Recordset.

Przykład u

ycia.

Co to jest ActiveX Data Objects?

set objCommand=Server.CreateObject(

"ADODB.command"

)

set objConnection=Server.CreateObject(

"ADODB.connection"

)

Obiekt Connection –obiekt słu

y do budowy i otwarcia poł

czenia z baz

danych.

Przykład u

ycia.

Obiekt Error - obiekt zawiera dane o bł

dach powstałych przy wykonaniu pojedynczych operacji na bazie danych.

Przykład u

ycia.

Co to jest ActiveX Data Objects?

for

each objErr

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)

Obiekt Field – obiekt przechowuje informacje o kolumnie danych w obiekcie Recordset.

Przykład u

ycia.

set objField=Server.CreateObject(

"ADODB.field"

)

Co to jest ActiveX Data Objects?

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:

Co to jest ActiveX Data Objects?

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:

Obiekt Stream (ADO version 2.5) – obiekt stosowany do czytania, zapisywania, zarz

dzania strumieniem

danych.

set objRecordset=Server.CreateObject(

"ADODB.recordset"

)

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

ytkownik 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 kursora dost

pny tylko dla obiektów typu klient rekordset.

Forward-only cursor – pozwala przejrze

rekordset. Operacje dodania, zmiany, usuni

cia wykonane przez innego

ytkownika s

niewidoczne.

Kursor Forward-only mo

e by

ustawiony poprzez property ‘CursorType’ lub poprzez parametr ‘CursorType’ w

metodzie Open().

Co to jest ActiveX Data Objects?

Proces budowy poł

czenia z baz

danych za pomoc

obiektów ADO:

Utworzenie poł

czenia ADO z baz

danych.

Otwarcie poł

czenia.

Utworzenie recordseta.

Otwarcie recordseta.

Pobranie danych do recordseta.

Zamkni

cie recordseta.

Zamkni

cie poł

czenia.

Co to jest ActiveX Data Objects?

1-2. Utworzenie i otwarcie poł

czenia z baz

danych. Baza northwind.mdb.

Utworzenie i otwarcie poł

czenia z baz

danych za pomoc

komponentu ODBC.

set conn=Server.CreateObject(

"ADODB.Connection"

)

conn.Provider=

"Microsoft.Jet.OLEDB.4.0"

conn.Open

"c:/webdata/northwind.mdb”

set conn=Server.CreateObject(

"ADODB.Connection"

)

conn.Open

"northwind"

3. Utworzenie recordseta.

set rs=Server.CreateObject(

"ADODB.recordset"

)

Co to jest ActiveX Data Objects?

4-5. Otwarcie i pobranie danych do recordseta.

Czytanie dnych z rekordseta.

6. Zamkni

cie recordseta.

7. Zamkni

cie poł

czenia.

rs.Open

"Select * from Customers"

, conn

for each

rs.fields

response.write(x.name)

response.write(

" = "

)

response.write(x.value)

rs.close

conn.close

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

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?

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

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?

<%@ language=

"javascript"

<html>

<body>

Response.Write(

"Hello World!"

)

</body>

</html>

Domy

lnym j

zykiem skryptowym dla stron ASP jest VBScript.

Aby zagnie

dzi

skrypty pisane w innych j

zykach nale

y u

atrybutu language.

Przykład: strona www wykonana w ASP.

Co to jest 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

</body>

</html>

Usługi WWW

Web Services Architecture, W3C Working Group Note 11 February 2004

uga WWW (ang. web service) jest systemem aplikacyjnym zaprojektowanym w celu wspamagania wymiany danych

dzy w

ami w sieciach komputerowych. System aplikacyjny us

ugi WWW posiada interfejs zaprojektowany 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

ugi WWW mo

na znale

źć

w specyfikacji j

zyka WSDL

http://www.w3.org/TR/wsdl

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

żą

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.

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 formacie XML.

Simple Object Access Protocol (SOAP)

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

Simple Object Access Protocol (SOAP)

Przyk

ad: struktura widomo

ci SOAP.

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>

Podstawowe zasady skladni protokolu SOAP:

• wiadomo

ść

SOAP musi by

w formacie XML,

• wiadomo

ść

SOAP musi zawiera

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

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.

Web Services Description Language

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

Przykład. Prosty dokument wsdl.

1. Uruchomi

serwer WWW (Microsoft IIS).

2. Umie

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

bibliotek

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

w tym samym katalogu co SilniaTest.exe).

C:\> SilniaTest.exe 8

Rezultat:

C:\> Usluga silnia. 8! = 40320

Usługa WWW: Silnia

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 == 0)

return

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 ,cd. 1

/// <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, cd. 2.

/// <remarks/>

public void

silniaAsync(

int

object

userState) {

((

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

((

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, cd. 3.

/// <remarks/>

[System.CodeDom.Compiler.GeneratedCodeAttribute(

"wsdl"

"2.0.50727.3038"

)]

public delegate void

silniaCompletedEventHandler(

object

sender, silniaCompletedEventArgs e);

/// <remarks/>

[System.CodeDom.Compiler.GeneratedCodeAttribute(

"wsdl"

"2.0.50727.3038"

)]

[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]));

}

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

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

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

ęś

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

•

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

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 podobszarów 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ó

reprezentacj

po stronie serwera i klienta:

•

Implementacja Obiektów Corby po stronie serwera nazywa sie servant’em (aplikacja ‘serwuj

’ usługi). Serwer

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

żą

danie od klienta i wywołuje danego servant’a.

Konfiguracja i kontrola poł

czenia 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) wykorzystywany 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.

Standard Corba

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/

Brokerzy i narz

dzia Corby