21
Maj
07

Document Oriented Programming, SOA

Wstępniaczek

Tak żebym nie zapomniał, kilka uwag co do całości. Ktoś może zadać pytanie: po co to Document Oriented Programming? Kiedy konkrety bo na razie lejesz wodę? Konkrety będą przedstawiane sukcesywnie z każdą kolejną notką – be patient, mam też swoje życie (jeszcze). Druga uwaga, która dotyczyć będzie aktualnego odcinka (tu trochę dłużej): „obiecałem” taką a nie inną formę wpisu, jednak chyba sobie daruje. Doszedłem do wniosku, że nie ma sensu szczegółowo porównywać programowania komponentowego i SOA – jeżeli ktoś jest rozgarnięty powinien sam sobie dopowiedzieć (doczytać na guglu) czym jest programowanie komponentowe, jakie były założenia paradygmatu a jak to wygląda dzisiaj (chodzi mi o rozbieżności, a trochę ich jest). Skupię się natomiast na architekturze zorientowanej na usługi w celu pokazania, jak wiele wnosi ona do procesu tworzenia oprogramowania, czemu warto zapoznać się z charakterystyką SOA i w jaki sposób SOA ułatwia usystematyzowanie procesów myślowych (nie święci garnki lepią).

Po co SOA?
Najważniejszym paradygmatem architektury zorientowanej na usługi (SOA) jest możliwość ponownego wykorzystania zasobów. Mówiąc zasób, mam na myśli dowolny element dużego systemu, nie ograniczając się tylko do fragmentów kodu zorganizowanych w biblioteki. Reużywalność w przypadku SOA ma trochę inny charakter ze względu na pole działania aplikacji SOA-like.

diag1.png

SOA skupia się na możliwości ponownego wykorzystania wcześniej zaimplementowanych funkcjonalności. Powyższy diagram przedstawia w jaki sposób implementacje algorytmów są organizowane w struktury, które będziemy określać mianem usług. I tutaj pierwsza analogia do komponentowego podejścia do programowania: istnieje pewna pula komponentów, które są odpowiedzialne za realizację konkretnej logiki. Komponenty, tak samo jak usługi, są zarejestrowane w repozytorium – w przypadku SOA jest to rejestr usług. Nie wiedzą o swojej wzajemnej egzystencji i są od siebie zupełnie niezależne. Najważniejszą różnicą pomiędzy podejściem komponentowym i tym, które jest reprezentowane przez SOA, jest możliwość dekompozycji większego zadania na szereg mniejszych. Tworzony jest łańcuch stanowiący swego rodzaju zapis przejść pomiędzy poszczególnymi usługami, których wykonanie w odpowiedniej kolejności pozwala na realizację nawet najbardziej skomplikowanej logiki biznesowej (nie przepadam za tym terminem …).

diag2.png

Diagram powyżej w podstawowym stopniu przedstawia jak organizowane są usługi w łańcuchach, pokazuje kolejność wykonywania usług składowych w celu realizacji logiki biznesowej. Usługi numerowane od 1-3 stanowią „części składowe” usługi oznaczonej numerem 4. Usługa czwarta natomiast, może stanowić element innej, jeszcze bardziej złożonej usługi. Proces organizacji usług w łańcuchy nazwiemy definiowaniem workflow.

Ok, zorganizowaliśmy sobie usługi, stworzyliśmy kilka workflow i jest cacy. No ale co dalej? Jak wykonać wcześniej zdefiniowany workflow? Aby tego dokonać należy wprowadzić nowe pojęcie.

Kanały dostępowe
Kanałem dostępowym nazwiemy dowolną metodę dostępu do systemu zbudowanego w oparciu o architekturę SOA, dzięki której możliwe będzie wykonanie dowolnego workflow.

diag3.png

Trzeci diagram pokazuje różne metody dostępu do repozytorium workflow. Możliwe jest zatem wykonanie logiki biznesowej przy pomocy trzech różnych medium komunikacji:

  • Zdalne wywołania XML-RPC
  • WebServices – np SOAP
  • HTTP – najzwyklejsze w świecie zlecenia protokołu HTTP

Mówiąc szczerze – to jaki kanał dostępowy zostanie zaimplementowany zależy tylko od tego, czy jest możliwe jego zaimplementowanie 😉 Wyobraźmy sobie zlecanie zadań przy pomocy Gadu-Gadu – zapewniam, podpięcie protokołu Gadu-Gadu jako kanału dostępowego nie zajmie dłużej niż 2 dni pracy.

SOA jako podstawa EAI
SOA tak naprawdę istniało zawsze. Czemu więc o nim piszę? Bo nikt nie zdawał sobie sprawy z istnienia tegoż, pomimo tego, że aplikacje które tworzył, były zgodne z założeniami tej architektury. Termin SOA pojawił się stosunkowo niedawno, gdy przedsiębiorstwa zaczęły zauważać, że aplikacje które wytwarzają, można połączyć aby zaoszczędzić sobie pracy. Wtedy też urodziło się pojęcie integracji aplikacji biznesowych, które jest niczym innym jak rozwinięciem SOA o kolejną warstwę.

diag4.png

Wprowadzenie tej warstwy umożliwia ponowne wykorzystanie logiki, która jest realizowana przez zewnętrzne systemy. Jesteśmy w stanie stworzyć usługi, które będą odpowiedzialne za połączenie się z zewnętrznym systemem, wykonanie zlecenia i pobranie wyników operacji w celu ich wykorzystania przez inne usługi zdefiniowane w repozytorium. Proste – przejrzyste – bardzo ładnie dokumentowalne.

Od teraz, tworząc większy system, możemy bardzo dokładnie rozdzielić pracę pomiędzy ludzi w zespole projektowym mając pewność, że nic nagle się nie posypie i cały system pójdzie się je….ć. A jeżeli coś pójdzie nie tak – od razu będzie wiadomo kogo pociągnąć za ucho.

Krótkie podsumowanie
Przedstawione paradygmaty zostały opisane bardzo ogólnikowo, bez zbędnych ceregieli. Jest to tylko zajawka, która powinna spowodować chęć samodzielnego zgłębiania tematu przez czytelnika (tak, to do Ciebie mój drogi(a)). Czytając opracowania w sieci, musisz pamiętać o kilku rzeczach:

  • SOA to nie tylko WebServices! Jeżeli ktoś tak uważa, to jest w błędzie.
  • SOA nie jest uzależnione od języka programowania czy platformy systemowej takiej a nie innej! To od Ciebie zależy w czym będziesz tworzyć – ale nie kryję sie z własnymi przekonaniami: java rox ;>
  • SOA to w ogóle nie programowanie, to manipulacja kwadratami i połączeniami między nimi, elementów SOA można doszukiwać sie w życiu codziennym

Mam świadomość, że notka jest chaotyczna, wybaczcie, zbyt wiele czasu poświęciłem na symulacje przeprowadzane z głowie, żeby skupiać się na szczegółach. Jeżeli będą pytania – bardzo chętnie odpowiem 🙂 A no i jeszcze kilka pozycji pomocniczych – do poczytania:

  • SOA – wrzucić do gugla i czytać
  • EAI – wrzucić do gugla i czytać
  • Workflow – wrzucić do gugla i czytać

Od razu teraz zapowiadam część 3 notek. Chyba powinienem znacząc wprowadzenie do Document Oriented Programming. Opiszę skąd się wziął pomysł na nowy paradygmat, będzie kilka nawiązań do SOA i EAI, wiele się wyjaśni, to jest pewne 😉 Stay tuned 🙂

Reklamy

1 Response to “Document Oriented Programming, SOA”


  1. 1 RG7
    Maj 22, 2007 o 8:09 pm

    Programowanie komponentowe – ciekawy temat. Zobaczmy co google na ten temat mowi… 😉


Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s


%d blogerów lubi to: