Slajd 1

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

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

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

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

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

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 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.
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

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

ARCHITEKTURA USŁUG SIECIOWYCH

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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

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

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

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

<soap:Envelope>

<header>

</header>

<soap:Body>

<NazwaTagu1>

<Element1> … </Element1>

</NazwaTagu1>

</soap:Body>

</soap:Envelope>

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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

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

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

 <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

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

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

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

CYKL ŻYCIA UŁSUGI WEB SERVICES

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

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

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

RÓŻNICE POMIĘDZY ACHITEKTRAMI

Aplikacje
Internetowe semestr
zimowy 2011/2012

Architektura aplikacji

internetowych

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)

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

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

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

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

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

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

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

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

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

one

uwzględnione

diagramie

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

autoryzacji

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

one

uwzględnione

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

one

uwzględnione

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

Document Outline