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

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

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

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

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