poniedziałek, 24 lutego 2014

Introduce to SOA. Chapter 1.

SOA - według niektórych największa ściema ostatnich lat w informatyce. Inni podpisują prawię wszystko po ten termin. Przez co wielu uprawia dyfuzje semantyczną zjawisko opisane przez Fowlera.
Czym jest SOA (service oriented architecture) - to po prostu styl tworzenia systemów informatycznych oparty na iteracjach luźno powiązanych, samodzielnych komponentów, które to świadczą pewne usługi (services).
Każda usługa dostarcza pewne zachowania opisane przez kontrakt (contracts). Te składają się z komunikatów (messages) wykrywanych w adresach czyli punktach końcowych (endpoints)
Zachowanie usług wynika z pewnej polityki czy restrykcji zwanych policies.
Regulacje te są zewnętrze wobec usługi.
Kontrakty i komunikaty są wykorzystywane poprzez zewnętrzych klientów - konsumentów usług.(service consumers).


 źródło : soa.sys-con.com













Generalnie jak miałeś do czynienia w WS dostrzeżesz szybko pewne analogie.
Stosują WebServices możemy  integrować usługi od równych producentów, tworzyć systemy bezstanowe i skalowalne, implementować i wiązać usługi w różnych środowiskach.

SOA to również :
 - orientacja na usługi (service orientation)
 - enkapsulacja logiki
 - luźne powiązania (loose couplings) - powiązania tylko na zasadzie wzajemnej świadomości

 - kontraktowość - stosowanie się do uzgodnień w kwestii komunikacji, zdefiniowanych w opisach

 - autonomia - każda usługa kontroluję swoją własną logikę, która jest mocno odseparowana od reszty 'świata'

 - abstrakcja - usługi ukrywają przez klientem elementu logiki

 - reużywalność - usługi budowane są z myślą jak największej uniwersalności oraz wielkokrotnego użycia

 - komponowalność - może istnieć koordynator, który umożliwi łączenie usług w kolekcje, stanowiące jedną spójną całość biznesową

 - bezstanowość - usługi nie powinny opierać się na jakimkolwiek stanie.

 - wykrywalność - usługi powinny być zaprojektowane intuicyjnie by za pomocą dostępnych komponentów można było je wykryć i użyć do zadanego zadania.

- dostarcza jakość usług (QoS - Quality of Service) czyli :
  - zdolność do realizowania usług w sposób bezpieczny

  - niezawodnej komunikacji, oraz gwarancji dostarczenia w przypadku 
niedostarczenia wiadomości usługa powinna dostarczyć odpowiednie powiadomienie

  - wydajność : narzut SOAP , Ws-Security oraz przetwarzanie XML nie powinno stanowić znaczącego narzutu na ogólną wydajność usługi

 -  transakcyjność poprzez integralność określonych zadań biznesowych oraz gwarancję wykonania odpowiedniego kodu w przypadku niepowodzenia wykonywanego zadania

- bazuje na otwartych standardach (SOAP, WSDL, XML, XSD etc)


ESB picture : source : http://www.thecloudcomputingaustralia.com/

Następny twór mocno powiązany z SOA to ESB. Jest to efektywny sposób realizacji usług. Dużą analogią będzie wzorzec Observer z głównego katalogu GoF.
Aplikacje łączą się z szyną - rejestrują swoje usługi, subskrybują i publikują komunikaty. ESB pozwala uwolnić się od sieci powiązań każdy-z-każdym pomiędzy aplikacjami, separuje dostawcę od odbiorcy usług oraz  zapewnia przejrzystość usług. Nie dostrzeżemy tu kłębka, plątaniny połączeń i integracji p2p.
W przypadku n usług, liczba połączeń systemu opartego na  ESB wynosi n, w porównaniu z n(n−1)/2 w przypadku połączeń bezpośrednich.

Ważne jest również to, że zadaniem ESB jest zapewnienie solidnego, odpornego na awarię i wiarygodnego systemu wymiany komunikatów.
Routing między komponentami odbywa się poprzez zastosowanie wzorców EIP dzięki czemu programista może łatwo odgadnąć zamiary projektanta systemu. Warunek jest jeden musi znać te wzorce.

Funkcje ESB: 
- routing komunikatów
- transformacje wiadomości
- monitoring
- security
- mediacja wiadomości
- JBI (Java Business Integration) (Apache ServiceMix)

Zalety ESB :
- dobrze zdefiniowana architektura
- łatwość podpięcia nowego systemu
- niezawodność
- łatwość skalowania
- rozproszenie
- luźne wiązania
- uniezależnienie od lokacji
- uniezależnienie od formatu wiadomości i protokołu
- mediacja wiadomości
- zcentralizowane zarządzanie

Wady ESB : 
 - duży narzut na początkowy setup
 - duża złożoność - rozwój

Tip : Apache ServiceMix, Apache Karaf, Mule


źródło : docs.huihoo.com  

źródło : www.uml.org.cn



 
















Opis korelacji jest z grubsza następujący :

Service consumer stosuje się do policy, wiąże się z endpointem, rozumie kontrakt oraz wysyła czy odbiera komunikaty

Service zarządzana jest przez policy, udostępnia endpointy, implementuje kontrakt i wysyła lub odbiera wiadomości.

Jak możemy się domyślać główną cechą SOA jest usługa. Powinna ona świadczyć jakąś funkcję biznesową oraz implementować wszystkie opisane dla niej kontrakty.
Ważne jest to, że musimy tworzyć usługi samowystarczalne (service autonomy)
 

Kontrakt opisuje definiuje komunikaty obsługiwane przez usługę. Kontrakt może mieć charakter jednostronny - skierowany tylko w jednym kierunku lub dwu strony zorientowany na komunikację z jednym lub grupą innych komponentów.

TIP :Mówiąc kontrakt myśl interfejs.

Punkt końcowy jest taki id (URI) zasób w którym osadzona jest dana usługa.
Stąd też możesz pobrać sobie kontrakt.

TIP : analogia np /services/pay?wsdl 

Komunikat to swego rodzaju jednostka komunikacji. Forma przekazu może być różna od JMS, po REST, SOAP czy SMTP.

Komunikat składa się z nagłówka (header) i treści (body). Nagłówek niesie cześć informacyjną dla innych komponentów bądź struktury, pomaga w routingu komunikatów czy w implementacji wzorca Request-Reply

MEP

Wzorzec Request-Reply wchodzi w skład katalogu wzorców wymiany komunikatów oraz w skład katalogu EIP (patrz Camel post)
- możesz zadać pytanie i otrzymać odpowiedź - Request/Reply
- możesz zostawić wiadomość z zapytaniem i swoim numerem telefonu i oczekiwać odpowiedzi Request/Reaction
- możesz prowadzić obszerną korespondencję z handlowcem wymieniając maile za czym Twój problem zostanie rozwiązany Saga


Komunikaty jednokierunkowe (one-way, fire-and-forget) -  dane są wysyłane tylko od wywołującego operację  (brak wartości zwracanej)

Komunikaty dwukierunkowe (two-way, request/reply) - dane są przesyłane do komponentu w momencie wykonania metody, wówczas komponent ma czas na wykonanie dodatkowych czynności, po zakończeniu których wysyła odpowiedz z powrotem do pytającego (bazuje na polu JMSCorrelationID).
 
Policy (regulacje) -  stanowią separację pomiędzy specyfikacją dynamiczną a statyczną. Definiują zasady tworzenia usług, konsumowanych przez klientów.
Określają własności dynamiczne jak bezpieczeństwo, audyt czy SLA. Umożliwiają późniejszą łatwą rekonfiguracje.

Konsumenci usług komunikują się z usługami poprzez komunikaty. Korzystają z usług zdefiniowanych w systemie w obrębie SOA.

Orkiestracja (orchestration) - logika centralnego sterowania, która umożliwia współdziałanie i przepływ informacji pomiędzy dwoma lub więcej systemami.
Często spotykamy to samo znaczenie pod terminem (hub-and-spoke) .
Usługa narzędzia orkiestracji ułatwia scalanie skomplikowanych procesów biznesowych. Orkiestracja nadaje procesom reprezentację w skali przedsiębiorstwa, wspiera federacyjność i propaguje zorientowanie na usługi.

SOA -> zalety : 

 - reużywalność (reusability)
 - zdolność adaptacyją (adaptability)
 - łatwość utrzymania (maintainability)
 - uniknięcie systemów spaghetii
 - zrozumienie wymagań biznesu, wymiana kompomentów
 - zmniejszony wysiłek integracji systemów
 - łatwiejszy proces automatyzacji procesów biznesowych
 - zredukowanie przestojów  - alternatywne drogi przepływów danych

Wady :
 - trudne tworzenie systemów opartych na SOA


Podobnie jak w modelu REST tak i w SOA możemy określić dojrzałość zaimplementowanych usług:



źródło : www.enterprise-architecture.info



Wzorce dotyczące bezpieczeństwa oraz standardy Ws-Security :

Mój mindMap : (security problems) (trochę już nieaktualny ale zawsze.:) )
 













































 - Secured Message
 - Secured Infrastructure
 - Service Firewall
 - Identity Provider
 - Service Monitor
 - XML Signature
 - XML Encryption
 - SAML
 - WS-Trust
 - SSL (Secure Socket Layer)
 - WS-Security
 - Single Sign-On (SSO)
 - Auth2
 - CSRF (cross-site request forgery)
 - STRIDE czyli potencjalne zagrożenia jak  :
    - podszywanie (spoofing)
    - fałszowanie (tampering)
    - odrzucenie komunikatu (repudiation)
    - ujawnienie informacji (information disclosure)
    - odmowę usługi (denial service)
    - podniesienie uprawnień (elevation of privilege)

 - budowanie bloków bezpieczeństwa jak :
   - poufność (confidentiality)
   - uwierzytalnianie (authentication)
   - autoryzacja (authrization)
   - spójność  (consistency)
   - integralność (integrity)
   - niezaprzeczalność (non-repudiation)
   - dostępność (availability
   - oraz katalog potencjalnych ataków. 

Dokładny opis problemów, rodzajów ataków oraz rozwinięcie  powyższych terminów -> to wszystko znajdziesz tutaj

Przykłady z wykorzystaniem Apache CXF znajdziesz tutaj

Katalog wzorców umieszczam poniżej:


Opis pozostałych standardów WS
  - związany z orkiestracją WS-BPEL (Business Process Execution Language)
  - WS-Addressing
  - WS-ReliableMessaging
  - WS-Policy
  - WS-MetadataExchange
  - WS-Notification
  - WS-Eventing


znajdziesz tutaj

Podsumowanie : Ten post miał za zadanie wprowadzić Cię  w świat SOA.
Albo może inaczej przybliżyć terminy związane z usługami.
Jak już zdążyłeś zauważyć mówiąc SOA , a mając na myśli standardowe podejście WebServices popełniałeś wielki błąd.
WebServices a SOA ma się tak jak koń do wielbłąda. Podobieństwo jest takie, że zarówno jeden jak i drugi  'człapie' na czterech nogach.

SOA != WS-* + SOAP + UDDI + WSDLs

Generalnie projektowanie systemów SOA wymaga wiedzy i wprawy. Znajomość ESB i wzorców EIP oraz SOA często stanowi totalne podwaliny aby cokolwiek zacząć implementować.
W dalszych postach z cyklu SOA i okolice dowiesz się jak projektować prawdziwe komponenty i usługi SOA.

Aha jeszcze jedna ważna rzecz.
Nie uważam, że SOA to recepta na wszystko. Fajnie jednak poznać wszystkie podejścia, ponieważ takie postępowanie otwiera Twój umysł na inne standardy i rozwiązania.
Ja np z nauki o SOA dostałem solidną porcję wiedzy jak projektować systemy w oparciu o WS oraz jak zabezpieczać takie systemy (security problems).

cdn


Brak komentarzy:

Prześlij komentarz