Architektura aplikacji

internetowych

Przygotowali:

Mirosław Klimek

Kamil Krajewski

Treść prezentacji

W ramach tej prezentacji zostaną
poruszone następujące zagadnienia:
 SOA
 ESB
 SaaS

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

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

Architektura aplikacji

internetowych

3

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

4

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

5

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
 Dojrzałość udostępnianych usług
 Pojedyncza implementacja danej funkcjonalności

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

6

IMPLEMENTACJE ROZPROSZONYCH KOMPONENTÓW

USŁUGOWYCH

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

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

7

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.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

8

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

9

CORBA - ARCHITEKTURA

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

10

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(Object Management
Architecture)
 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

11

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

12

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

13

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

14

OBIEKTY 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

15

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

16

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

17

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

18

CZYM JEST EJB?

 EJB jest częścią specyfikacji/platformy
J2EE
 EJB komponent po stronie serwera
 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

19

EJB W ARCHITEKTURZE JEE

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

20

RODZAJE EJB

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

21

RODZAJE EJB

Session EJB:
Reprezentuje pojedynczego klienta
aplikacji.
Entity EJB:
Entity Bean reprezentuje obiekt
biznesowy.
Message Driven Bean:
Reprezentuje lekki komponent
używany do komunikacji.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

22

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

23

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

24

ARCHITEKTURA USŁUG SIECIOWYCH

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

25

WYWOŁANIE WEB SEVICES

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

SOAP

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

28

CECHY SOAP

 Jest protokołem warstwy aplikacji w modelu OSI i
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 firewalle.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

29

STRUKTURA LOGICZNA SOAP

Reprezentacja RPC (SOAP RPC
representation) – określa reguły
opisu zdalnych procedur i ich
odpowiedzi.

Zasady kodowania (SOAP
encoding rules) – możliwość
definiowania typów
wykorzystywanych przez
aplikację.

Koperta (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.

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

<soap:Envelope>

<header>

</header>

<soap:Body>

<NazwaTagu1>

<Element1> … </Element1>

</NazwaTagu1>

</soap:Body>

</soap:Envelope>

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

32

WYWOŁYWANIE KOMPONENTÓW

Protokół SOAP umożliwia wywoływanie
komponentów Web Service w dwóch trybach:
 Remote Procedure Call (RPC) - wywołanie ma

charakter tradycyjny – komponentowi
przekazywana jest lista parametrów formalnych
wraz z ich bieżącymi wartościami

 Dokumentowym (document-oriented) - usługa

otrzymuje tylko jeden parametr wywołania,
którym jest dokument XML.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

33

SOAP - KOMUNIKACJA

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

34

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

35

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

36

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

37

STRUKTURA ZNACZNIKÓW DOKUMENTU WSDL

 <definitions> otacza
całą zawartość
dokumentu;

 <service> wraz z
<port> definiują adresy
punktów dostępowych
dla usługi;

 <portType> służą do
deklaracji funkcji
biznesowych
oferowanych przez
usług;

 <binding> określają
metody kodowania
parametrów wywołania i
parametrów zwrotnych
usługi.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

38

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

39

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

40

CEL UDDI

Uproszczenia dystrybucji dokumentów
WSDL i semantyki komponentów
usługowych web services ;
 Żeby 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

41

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

42

CYKL ŻYCIA UŁSUGI WEB SERVICES

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

43

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

44

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

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

45

RÓŻNICE POMIĘDZY ACHITEKTRAMI

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

46

Architektury RPC Część klienta

Część serwera

CORBA

Stub (pieniek)

Skeleton (szkielet)

DCOM

Proxy

(pośrednik)

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
www.omg.org

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

47

Szyna usług przedsiębiorstwa (ang.

Enterprise Service Bus, ESB)

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Co to jest ESB?

ESB jest to model architektury oprogramowania
używany do projektowania oraz implementacji
interakcji i komunikacji pomiędzy wzajemnie
zależnymi aplikacjami w SOA. Ma możliwość
łączenia wielu punktów końcowych i stosowany
jest

głównie

do

integracji

różnorodnego

oprogramowania biznesowego

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Model wdrożeniowy ESB

Model wdrożeniowy ESB to
zintegrowana

sieć

współpracujących

węzłów

usług, rozwijanych w formie
zasobników usług. Zasobniki
usług

są

podłączone

do

topologii szyny logicznej przez
serwery

komunikacyjne.

Koncepcja tego rozwiązania
jest wzorowana na szynach
komputerów (hardware bus)

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Komunikacja w ESB

Aplikacje współdziałają za pośrednictwem wiadomości
XML, które wchodzą i wychodzą do/z zasobników usług
przez punkty końcowe aplikacji. Dlatego nie trzeba
martwić się o protokoły komunikacyjne i fizyczne
rozmieszczenie.
Dzięki takiemu rozwiązaniu usługi mogą być rozszerzane,
przemieszczane lub podmieniane bez przerywania pracy
systemów biznesowych.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Komunikacja w ESB

Używając

arkuszy

stylu

XML,

ESB

może

transformować zawartość wiadomości z jednego
formatu

na

inny.

Aplikacje

nie

muszą

dostosowywać się do określonego formatu, a dane
nie muszą być przesyłane do centralnego miejsca
w celu transformacji. ESB traktuje wszystkie
aplikacje jako usługi, niezależnie od tego, jak są
one podłączone do szyny.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Jak to działa?

Każda usługa jest opisana we wspólnym katalogu.
Projektanci dołączają aplikacje poprzez wyszukanie
usługi w katalogu i zgrywanie interakcji usług.
ESB używa inteligentnego rutingu do wykonywania
takiego zgrania. Istnieje coś w rodzaju przewodnika
XML zawierającego punkt początkowy i określający
wymaganą

sekwencję

usług,

przez

które

wiadomość musi przejść w celu skompletowania
całego procesu.
Ruting wiadomości można zmieniać zgodnie z
zawartością

wiadomości

oraz

zdarzeniami

zachodzącymi w czasie rzeczywistym

.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Oprogramowanie jako usługa (ang.

Software as a Service, SaaS)

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Co to jest SaaS?

Software as a Service, czyli oprogramowanie jako
usługa, jest to model biznesowy i wdrożeniowy
tworzenia

i

udostępniania

aplikacji.

Oprogramowanie SaaS wdrażane jest jako usługa
dostępna na żądanie, przez sieć (najczęściej
Internet) i stanowi przykład aplikacji rozproszonej.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS a tradycyjne oprogramowanie

W przeciwieństwie do standardowego modelu
udostępniania oprogramowania przedsiębiorstwo,
które zakupuje nowe oprogramowanie musi
zainwestować, także w infrastrukturę sprzętową i
zasoby ludzkie.
Przy korzystaniu z aplikacji SaaS firma nie musi
inwestować w sprzęt - aplikacja działa w chmurze,
na zdalnych serwerach dostawcy oprogramowania,
klient potrzebuje jedynie dostępu do Internetu.
Oprogramowanie takie opłaca się przeważnie na
zasadzie okresowych subskrypcji.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Klienci SaaS

Klienci rozwiązania SaaS nazywani są tenantami. Nie
należy tego pojęcia mylić z użytkownikami aplikacji -
tenantami są przeważnie całe organizacje (firmy,
korporacje),

każdy

z

tenantów

posiada

swoich

pracowników, czy klientów, i to oni dopiero stanowią
użytkowników końcowych, do których skierowana jest
aplikacja SaaS.
Przykładową aplikacją SaaS dostępą na rynku jest
oferowane darmowo Google Apps.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Architektura SaaS

Z architekturalnego punktu widzenia aplikacje
SaaS zgodne są z wielowarstwowym modelem
aplikacji rozproszonej jednak wyróżniono pewne
cechy

charakteryzujące

większość

dobrze

zaprojektowanych rozwiązań SaaS:

Multitenancy - jest to możliwość obsługi wielu
tenantów przez pojedynczą instancję aplikacji, przy
czym zapewniona jest izolacja pomiędzy różnymi
tenantami.

System

musi

być

więc

tak

zaprojektowany,

aby

współdzielić

zasoby

wchodzące w jego skład, a jednocześnie zachować
separację i umiejętność odróżnienia danych
poszczególnych tenantów.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Architektura SaaS

Z architekturalnego punktu widzenia aplikacje
SaaS zgodne są z wielowarstwowym modelem
aplikacji rozproszonej
Wyróżniono

pewne

cechy

charakteryzujące

większość dobrze zaprojektowanych rozwiązań
SaaS:

Konfigurowalność - tenanci często potrzebują
aplikacji dostosowanej do ich potrzeb lub
wymogów korporacyjnych. Oczywiście nie jest
możliwe zapewnienie tego bezpośrednio na
poziomie kodu - aplikacja ma służyć wielu
tenantom na raz. Dlatego dobrze zaprojektowane
aplikacje udostępniają możliwość konfiguracji
opartej na zewnętrznych ustawieniach, dzięki
czemu tenanci są w stanie dostosować ich wygląd i
zachowanie dla swoich użytkowników.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Architektura SaaS

Z architekturalnego punktu widzenia aplikacje
SaaS zgodne są z wielowarstwowym modelem
aplikacji rozproszonej
Wyróżniono

pewne

cechy

charakteryzujące

większość dobrze zaprojektowanych rozwiązań
SaaS:

Skalowalność - oznacza umiejętność łatwej
adaptacji

oprogramowania

do

zwiększonego

wykorzystania (na przykład przy wzroście liczby
użytkowników) i współbieżności poprzez efektywne
wykorzystanie dostępnych oraz dodatkowych
zasobów,

optymalizację

przetwarzania

w

obszarach krytycznych i bezstanowość. Ma ona
krytyczne znaczenie, gdyż liczba użytkowników
aplikacji SaaS może rosnąć bardzo szybko.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Architektura aplikacji SaaS

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Aplikacje

SaaS

charakteryzują

się

warstwą

dystrybucji. Chociaż nie jest to warstwa specyficzna
jedynie dla SaaS – charakteryzuje ona większość
aplikacji klasy enterprise – to ma ona zasadnicze
znaczenie dla tej architektury. Dzięki warstwie
dystrybucji możliwe jest zastosowanie mechanizmów
równoważenia obciążenia (load balancing) w celu
dynamicznego przekierowania nadchodzących żądań
na inne instalacje, co zapewnia wysoką skalowalność
i odpowiedni poziom jakości usług w systemach
obsługujących wielu tenantów.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Wiele rodzajów usług należących do warstwy
aplikacji i wspierających właściwą funkcjonalność
udostępnianych jest przez platformę dostępną po
stronie klienta kupującego aplikację – w SaaS to
dostawca aplikacji musi je zapewnić, dlatego też
zostały

one

uwzględnione

na

diagramie

architektury. Do usług tych należą:
- warstwa równoważenia obciążenia i zarządzania

ruchem kierowanym do aplikacji (load balancer)

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Wiele rodzajów usług należących do warstwy
aplikacji i wspierających właściwą funkcjonalność
udostępnianych jest przez platformę dostępną po
stronie klienta kupującego aplikację – w SaaS to
dostawca aplikacji musi je zapewnić, dlatego też
zostały

one

uwzględnione

na

diagramie

architektury. Do usług tych należą:
- warstwa

autoryzacji

i

bezpieczeństwa

(rozbudowana w stosunku do standardowych
rozwiązań o mechanizmy multitenancy, dzięki
którym użytkownicy mają dostęp jedynie do
danych dostępnych dla ich tenantów)

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Wiele rodzajów usług należących do warstwy
aplikacji i wspierających właściwą funkcjonalność
udostępnianych jest przez platformę dostępną po
stronie klienta kupującego aplikację – w SaaS to
dostawca aplikacji musi je zapewnić, dlatego też
zostały

one

uwzględnione

na

diagramie

architektury. Do usług tych należą:
- warstwa integrująca aplikację z systemami

zastanymi (legacy systems), czyli w przypadku
np. z innymi systemami SaaS

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Wiele rodzajów usług należących do warstwy
aplikacji i wspierających właściwą funkcjonalność
udostępnianych jest przez platformę dostępną po
stronie klienta kupującego aplikację – w SaaS to
dostawca aplikacji musi je zapewnić, dlatego też
zostały

one

uwzględnione

na

diagramie

architektury. Do usług tych należą:
- warstwa monitoringu nadzorującą obciążenie i

zachowanie aplikacji.

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

SaaS – warstwa dystrybucji

Do warstw nowych, specyficznych jedynie dla
SaaS, należą:
- warstwa umożliwiająca automatyczną rejestrację

i dynamiczną alokację zasobów dla nowego
tenanta (provisioning)

- warstwa zajmująca się pomiarem aktualnego

wykorzystania zasobów przez danych tenantów i
zgodnie z nim naliczająca opłaty (pay-as-you-
use).

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

Mirosław

Klimek

Kamil

Krajewski

Dziękujemy za uwagę!