SOA
SOA (SERVICE-ORIENTED ARCHITECTURE) -
architektura zorientowana na usługi. Komponenty
usługowe są luźno związane z aplikacją sterującą,
nazywaną też konsumentem usług (Service
Consumer), a ponadto mogą być współdzielone
przez wiele aplikacji. Zwykle komponenty
usługowe są implementowane i udostępniane
przez niezależne podmioty, nazywane dostawcami
usług (Service Providers). Łączność pomiędzy
aplikacją sterującą a komponentami usługowymi
odbywa się za pośrednictwem sieci Internet.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Mirosław
Klimek
Kamil
Krajewski
Architektura aplikacji
internetowych
ARCHITEKTURA ZORIENTOWANA NA
USŁUGI (SOA)
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
2
IDEA SOA
Jest to koncepcja tworzenia systemów
oprogramowania na podstawie dobrze
zdefiniowanych serwisów/usług. Pojęcie SOA
obejmuje całość sposobów przetwarzania informacji,
metod organizacji serwisów oraz technicznych
podstaw ich funkcjonowania. Poprzez pojęcie serwisu
rozumiemy tutaj element oprogramowania o dobrze
wyspecyfikowanym interfejsie realizującym określone
funkcje. Serwis jest to więc zwykle coś więcej niż
komponent, często realizowany na podstawie kilku
komponentów poprzez udostępnienie ich
najważniejszej funkcjonalności. Współpraca serwisów
odbywa się przy wykorzystaniu ustandaryzowanych
sposobów komunikacji np. SOAP. Same serwisy jak i
sposoby komunikacji są zdefiniowane na dość
wysokim poziomie abstrakcji, w sposób niezależny od
używanych języków programowania, architektur
komputerów, systemów operacyjnych. Wszystko to
sprawia, że problemy integracji (znane chociażby z
programowania komponentowego) w architekturze
SOA nie występują.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
3
HISTORIA SOA
SOA ma swój początek o wiele wcześniej niż mogłoby się
wydawać, mianowicie w latach 60 ubiegłego wieku. W
roku 1968 w niemieckim mieście Garmisch odbyła się
konferencja na której amerykański inżynier Malcolm
Douglas McIlroy wygłosił odczyt pod tytułem “Mass
Produced Software Components”. Idea budowania
oprogramowania z mniejszych elementów była już znana
o wiele wcześniej - wszak elementami tymi mogą być np.
funkcje lub obiekty. Każdy z tych elementów może być
traktowany jako pewnego rodzaju “czarna skrzynka”.
Umożliwia ona w sposób kontrolowany dostęp do pewnej
funkcjonalności (zachowania, danych) poprzez dobrze
sprecyzowany interfejs. W przypadku funkcji interfejsem
tym jest jej nagłówek a zachowaniem ciało, w przypadku
obiektu odpowiednio deklaracja interfejsu oraz jego
implementacja. Również programowanie komponentowe
wprowadzone przez McIlroy'a wpisuje się w koncepcje
“czarnych skrzynek”, ale wyróżnia się mniejszą
ziarnistością niż np. programowanie obiektowe.
Komponent jest zwykle dużym modułem programowym,
zrealizowanym najczęściej z połączenia grupy obiektów,
które pracują razem w celu udostępnienia pewnej
funkcjonalności.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
4
CECHY SOA
ponowne użytkowanie już stworzonych
usług, odpowiednia ziarnistość i podział na
moduły
zgodność ze standardami, zarówno ogólnymi
jak i specyficznymi dla danej organizacji
identyfikacja i kategoryzacja usług, ich
monitorowanie i śledzenie
definiowanie kontraktów pomiędzy usługami
oddzielenie logiki biznesowej od używanych
technologii
zarządzanie cyklem życia komponentów
efektywne użytkowanie zasobów
systemowych
dojrzałość udostępnianych usług
pojedyncza implementacja danej
funkcjonalności
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
5
IMPLEMENTACJE ROZPROSZONYCH
KOMPONENTÓW USŁUGOWYCH
CORBA;
DCOM;
EJB;
Web Services;
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
6
CORBA
CORBA(COMMON OBJECT REQUEST
BROKER ARCHITECTURE) jest to
architektura, które umożliwia komunikacje
obiektom zlokalizowanym na różnych
maszynach, różnych systemach
operacyjnych, różnych architekturach
sprzętowych komunikacje miedzy sobą.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
7
CEL
zapobiec chaosowi;
zmniejszyć koszty związane z
tworzeniem aplikacji rozproszonych;
standard uniwersalnej architektury
komunikacji obiektów rozproszonych
stworzony przez OMG (Object
Management Group).
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
8
CORBA - ARCHITEKTURA
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
9
Klient
Implementacja obiektów
(reprezentacja i przechowywanie
obiektów; realizacja dostępu i usług)
Wołania
dynamiczne
(RPC)
Pieniek
IDL
(IDL stub)
Interfejs
do
pośrednika
ORB
Szkielet obiektów
(IDL skeleton)
Adapter
obiektów
Rdzeń Pośrednika (ORB core)
Dynamiczny
Szkielet Interfejsu
Takie samo dla wszystkich ORB
Pieńki i szkielety
specyficzne dla interfejsów
Może być wiele adapterów obiektów
Prywatne interfejsy ORB
CECHY ARCHITEKTURY CORBA
Model pojęciowy OMA
Język IDL (Interface Definition
Language - abstrakcyjny język
obiektowy)
Wiązania do wielu języków
programowania
Automatyczne generowanie kodu
pieńków (stubs) i szkieletów (skeletons)
Transparentność lokalizacji obiektów i
usług
Wspólne usługi i udogodnienia CORBA
Niezależność od sprzedawców
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
10
PODSUMOWANIE CORBA
-korzysta z IIOP(Internet Inter-ORB
Protocol) – protokół implementujący
system wymiany danych dla protokołu
TCP/IP
- CORBA jest otwartym standardem
- może łączyć się z EJB, Web Service,
DCOM
- obiekty programowe zgodne ze
standardem CORBA są przenośne
- Stub-Skeleton generowane są z IDL
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
11
DCOM
DCOM (Distributed Component Object
Model) — interfejs programistyczny
realizujący rozproszony obiektowy model
składników. Jest opatentowaną
technologią firmy Microsoft służącą do
budowania składników programowych i
zapewniania komunikacji między nimi w
sieci lokalnej lub Internecie. Do
transmisji danych między komponentami
wykorzystywane są wówczas protokoły
TCP/IP oraz HTTP. DCOM został
rozwinięty z COM co jest odpowiedzią na
rozwijanie się CORBA.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
12
DCOM
Technologia 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 .
Klient przekazuje i odbiera dane za pomocą obiektu Proxy.
Obiekt Proxy dostarcza te same interfejsy co DCOM serwer
ale
ich nie implementuje (implementacja jest na serwerze).
Serwery są komponentami pasywnymi, tzn. odpowiadają
tylko na
żądania klienta.
Klient uruchamia i aktywuje serwer następnie żąda
obiektu DCOM i
interfejsu. Wywołuje metody na serwerze po czym zwalnia
interfejsy,
może zamknąć lub zdeaktywować serwer.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
13
DCOM
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).
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
14
DCOM
RPC (Remote Procedure Calls) – protokół służący do
komunikacji pomiędzy komponentami DCOM
(SCM) Service Control Manager - służy do
odnajdywania komponentów DCOM, uruchamia i
zatrzymuje serwer DCOM, wywołuje Interfejsy
DCOM , zarządza komunikacją między procesami.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
15
PDSUMOWANIE DCOM
-DCOM jest stworzony przez Microsoft
-Każdy obiekt posiada GUID(Global
Unique ID)
-Proxy i Interfejsy generowane są z MIDL
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
16
EJB
Enterprise JavaBeans (EJB) -
technologia "po stronie serwera" będąca
jednym z elementów specyfikacji JEE /
J2EE. Na EJB można spojrzeć jak na
podzbiór możliwości Javy w kontekście
zarządzania beanami - ziarnami EJB -
udostępniających im usługi jak
transakcyjność, trwałość, rozproszenie,
bezpieczeństwo, wielodostęp, itp.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
17
CZYM JEST EJB?
- EJB jest częścią specyfikacji/platformy
J2EE
- EJB komponent po stronie serwera
- EJB enkapsuluje logikę/obiekty
biznesowe
- EJB ma uprościć proces wytwarzania
oprogramowania
- EJB – to również cienki klient
- Możliwość zakupienia gotowych
komponentów
EJB od innych dostawców
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
18
EJB W ARCHITEKTURZE JEE
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
19
Aplikacje Internetowe
semestr zimowy
2011/2012
Architektura aplikacji
internetowych
20
RODZAJE EJB
Session EJB:
- Reprezentuje pojedynczego klienta
aplikacji.
- Session Bean nie jest dzielony
pomiędzy
klientami.
- Session Bean nie jest persystentny
( istnieje
second storage)
- Kiedy klient kończy połączenie Session
Bean
jest zwalniany (pooling, zwolnienie
zasobu)
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
21
RODZAJE EJB
Entity EJB
- Entity Bean reprezentuje obiekt biznesowy.
- Entity Bean jest z natury persystentny (z
reguły
obiektowi Entity Bean odpowiada tabela w
Relacyjnej bazie danych).
- Posiada klucz główny
- Może pozostawać w związkach z innymi
Entity
Beans
- Może być dzielony pomiędzy wielu klientów
Aplikacje Internetowe
semestr zimowy
2011/2012
Architektura aplikacji
internetowych
22
RODZAJE EJB
Message Driven Bean
- W odróżnieniu do poprzednich pozwala
przetwarzać komunikaty asynchronicznie
- Działa podobnie do Listnera zdarzeń –
otrzymuje JMS message zamiast event
- Komunikat może być wysłany przez dowolny
komponent J2EE (klienta, Enterprise
JavaBeana, komponent Webowy)
- Klient nie wywołuje M-D Beana przez
jakikolwiek Interfejs.
- Każdy M-D Bean jest równoważny (jest
bezstanowy)
- Jest efektywniejszy niż inne Beany – nie jest
odejmowana konwersacja z serwerem.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
23
PODSUMOWANIE EJB
– pozwala tworzyć model obiektowy
– łatwiejsze w przyswojeniu
– większa funkcjonalność (komponenty
encyjne)
– szybsze tworzenie oprogramowania
– proxy generowane jest przez bean
interfejs
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
24
WEB SERVICE
Web Services (usługi sieciowe) to
technologia konstrukcji rozproszonych
komponentów usługowych,
stanowiących podstawę dla realizacji
aplikacji biznesowych w architekturze
zorientowanej na usługi. Zgodnie z
powszechnie akceptowaną definicją,
usługa Web Service to zwarty,
samodokumentujący się komponent
programowy, który może być przez
swojego twórcę zarejestrowany w sieci
komputerowej, a następnie przez twórcę
aplikacji-konsumenta odkryty
i wywołany w trybie zdalnego
wykonania.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
25
WYWOŁANIE WEB SEVICES
Wywołania komponentów usługowych Web
Services mogą mieć charakter synchroniczny
lub asynchroniczny.
W trybie wywołania synchronicznego aplikacja
klienta wysyła żądanie uruchomienia zdalnej
funkcji biznesowej i wstrzymuje pracę aż do
chwili otrzymania wyników jej realizacji. Tryb
ten może opierać się na komunikacji HTTP,
HTTPS, RMI/IIOP, SMTP, itp.
W trybie wywołania asynchronicznego
aplikacja klienta wysyła żądanie uruchomienia
zdalnej funkcji biznesowej lecz nie oczekuje na
jej wynik, kontynuując działanie. Tryb ten może
opierać się na komunikacji HTTPR, JMS, IBM
MQSeries Messaging, MS Messaging, itp.
Zwykle tryb synchroniczny jest
wykorzystywany przez komponenty RPC,
natomiast tryb asynchroniczny – przez
komponenty dokumentowe.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
26
PROTOKŁY WEB SERVICE
Web Service(usługi sieciowe)
wykorzystuje szereg rozwiązań
informatycznych, m.in.:
- SOAP – służący do przekazywania
zdalnych wywołań,
- WSDL – służący do dystrybucji
parametrów połączeń sieciowych,
- UDDI – służący do rejestracji
udostępnianych komponentów
usługowych
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
27
ARCHITEKTURA USŁUG SIECIOWYCH
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
28
SOAP
SOAP (ang.) Simple Object Access
Protocol – protokół wywoływania
zdalnego dostępu do obiektów,
wykorzystujący XML do kodowania
wywołań i najczęściej protokołów HTTP,
RMI, HTTPS lub RPC do ich przenoszenia,
możliwe jest jednak wykorzystanie
innych protokołów do transportu danych.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
29
CECHY 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.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
30
BUDOWA KOMUNIKATÓW SOAP
Podstawowymi znacznikami
wykorzystywanymi do budowy
komunikatów SOAP są:
<Envelope> – otacza cały komunikat;
<Header> – zawiera informacje
nagłówkowe; <Body> – zawiera
informacje o żądaniu i odpowiedzi;
<Fault> – opisuje błędy, jakie
wystąpiły podczas przetwarzania
wywołania
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
31
PRZYKŁAD
<soap:Envelope>
<header>
</header>
<soap:Body>
<NazwaTagu1>
<Element1> … </Element1>
</NazwaTagu1>
</soap:Body>
</soap:Envelope>
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
32
LOGICZNY PODZIAŁ SOAP
Kopertę (SOAP envelope) - jest to
definicja opisująca co znajduje się w
wiadomości, dla kogo jest przeznaczona i
czy wiadomość jest obowiązkowa lub
opcjonalna.
Zasady kodowania (SOAP encoding
rules) – możliwość definiowania typów
wykorzystywanych przez aplikację.
Reprezentacja RPC (SOAP RPC
representation) – określa reguły opisu
zdalnych procedur i ich odpowiedzi.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
33
STRUKTURA LOGICZNA SOAP
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
34
WYWOŁYWANIE KOMPONENTÓW WEB
SEVICE
Protokół SOAP umożliwia wywoływanie
komponentów Web Service w dwóch
trybach:
1.Remote Procedure Call (RPC)
2.Dokumentowym (document-oriented).
Tryby te różnią się formą przekazywania
parametrów.
W trybie RPC wywołanie ma charakter
tradycyjny -
komponentowi przekazywana jest lista
parametrów formalnych wraz z ich
bieżącymi wartościami. W trybie
dokumentowym usługa otrzymuje tylko
jeden parametr wywołania, którym jest
dokument XML.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
35
SOAP - KOMUNIKACJA
Wiadomość jest podstawową komunikacją
jednokierunkową
pomiędzy nadawcą, a odbiorcą. Wiadomość SOAP
może
wykorzystać rożne protokoły jako medium
transportowe (np.
HTTP).
Aplikacja SOAP, która odebrała wiadomość SOAP
musi ją
przetworzyć zgodnie z zasadami:
1. Rozpoznać wszystkie części wiadomości.
2. Zdecydować, czy wszystkie części wiadomości są
wspierane
przez aplikację.
3. Jeżeli aplikacja nie jest adresatem wiadomości to
musi ją
przekazać do adresata.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
36
RESET
REST (Representational State Transfer) to
architektura programowania opierająca się
na bezstanowej wymianie komunikatów w
środowisku rozproszonym, wykorzystująca
formaty XML i JSON (JavaScript Object
Notation).
RESET jest alternatywą przyciężkich
komunikatów SOAP.
Zastosowania webowe:
- preferencja usług REST (Google Data API,
Amazon WS)
- usługi sieciowe REST są de facto
rozszerzeniem Web
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
37
RESET
Polega na prostym przesyłaniu XML’a z
wykorzystaniem protokołu HTTP.
Usługa jest wywoływana poprzez
zapytanie do dokładnego adresu URL.
Metodą HTTP
(GET, POST, PUT i DELETE) przesyłane są
parametry wywołania. Usługa odpowiada
zwracając zwykły dokument XML z
wynikami zapytania.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
38
WSDL
WSDL (Web Services Description
Language) to język znaczników XML
służący do opisu technicznych
parametrów połączenia sieciowego
aplikacji-klienta z komponentem Web
Service.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
39
STRUKTURA ZNACZNIKÓW
DOKUMENTU WSDL
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
40
BUDOWA WSDL
Role wymienionych znaczników są
następujące:
-znacznik <definitions> otacza całą
zawartość dokumentu;
- znaczniki <service> wraz ze
znacznikami <port> definiują adresy
punktów dostępowych dla usługi;
-znaczniki <portType> służą do deklaracji
funkcji biznesowych oferowanych przez
usług;
- znaczniki <binding> określają metody
kodowania parametrów wywołania i
parametrów zwrotnych usługi.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
41
PRZYKŁAD 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>
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
42
UDDI
UDDI (Universal Description, Discovery, and
Integration) to usługa udostępniająca klientom
mechanizmy dynamicznego wyszukiwania innych usług
Web. UDDI stanowi interfejs umożliwiający dynamiczne
połączenie się z usługą udostępnianą przez innego
usługodawcę. Rejestry UDDI zawierają:
- White Pages: informacje o webservices na bazie nazwy
usługodawcy, jego adresu, kategorii biznesowej czy
informacji technicznej itp. (czyli adresy i kontakty);
- Yellow Pages: operacje dotyczące usługi WEB, tj.
rejestracji, wyszukiwania i korzystania z usługi
(klasyfikacje przemysłowe)
;
- Green Pages: szczegóły udostępniane przez
niskopoziomowe API
(opisy usług).
UDDI posiadają dwa rodzaje klientów: usługodawców
publikujących swoje usługi oraz klientów pragnących
skorzystać z tych usług.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
43
CEL UDDI
W celu uproszczenia dystrybucji
dokumentów WSDL i semantyki
komponentów usługowych Web
Services a także aby dostępne
komponenty były rejestrowane w
specjalizowanej bazie danych, która
może być następnie przeszukiwana
przez twórców aplikacji-klientów lub
przez same aplikacje-klientów z
zamiarem odkrycia potrzebnych
komponentów.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
44
CYKL ŻYCIA UDDI
Dostęp do rejestru UDDI jest zwykle
możliwy zarówno poprzez interfejs HTML,
jak i poprzez interfejs programistyczny
(biblioteka JAXR-API). Cykl życia usługi Web
Service z punktu widzenia jej deklaracji w
rejestrze UDDI:
1.Twórca komponentu implementuje
komponent usługowy Web Service i
rejestruje go w UDDI.
2. Twórca klienta wyszukuje opisu
komponentu usługowego Web Service w
UDDI i implementuje aplikację-klienta.
3.Uruchomiona aplikacja-klient dokonuje
zdalnego
wywołania komponentu usługowego Web
Service.
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
45
DISCO
DISCO (Discovery) to protokół, który
umożliwia odnajdowanie usług Web
Services.
Witryna internetowa powinna
opublikować dokumenty DISCO
zawierające adresy URL oraz opisy WSDL
dla udostępnianych usług web.
Dokumenty DISCO zawierają odniesienia
do innych witryn oraz innych
dokumentów DISCO co umożliwia
przeszukiwanie drzew katalogów itp..
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
46
CYKL ŻYCIA UŁSUGI WEB SERVICES
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
47
ZALEŻNOŚĆ MIĘDZY TECHNOLOGIAMI UDDI
A WSDL
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
48
RÓŻNICE
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
49
Architektury
RPC
Część klienta Część serwera
CORBA
Stub (pieniek)
Skeleton (szkielet)
DCOM
Stub (pieniek)
Stub (pieniek)
Usługi sieciowe
oparte na XML
Service Proxy
(pośrednik)
Service
Implementation
Template (szablon
implementacji
usługi)
LITERATURA
http://uddi.xml.org
http://pl.wikipedia.org
http://www.networld.pl/artykuly/347213
_3/Podstawy.bezpieczenstwa.SOA.html
Aplikacje
Internetowe semestr
zimowy 2011/2012
Architektura aplikacji
internetowych
50
Aplikacje Internetowe
semestr zimowy
2011/2012
Architektura aplikacji
internetowych
51