Slajd 1

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

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

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

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

IMPLEMENTACJE ROZPROSZONYCH KOMPONENTÓW

USŁUGOWYCH

 CORBA;
 DCOM;
 EJB;
 Web Services;

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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

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

CORBA - ARCHITEKTURA

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Klient

Implementacja obiektów

(reprezentacja i przechowywanie

obiektów; realizacja dostępu i usług)

Wołania

dynamiczne

(RPC)

Pieniek

IDL

(IDL stub)

Interfejs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ARCHITEKTURA USŁUG SIECIOWYCH

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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

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

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

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

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

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

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

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

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

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

STRUKTURA ZNACZNIKÓW DOKUMENTU WSDL

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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

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

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

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

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

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

CYKL ŻYCIA UŁSUGI WEB SERVICES

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

ZALEŻNOŚĆ MIĘDZY TECHNOLOGIAMI UDDI A WSDL

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

RÓŻNICE

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Architektury

RPC

Część klienta Część serwera

CORBA

Stub (pieniek)

Skeleton (szkielet)

DCOM

Stub (pieniek)

Usługi sieciowe

oparte na XML

Service Proxy

(pośrednik)

Service

Implementation

Template (szablon

implementacji

usługi)

Document Outline