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