SOA: marzenia o wspólnym języku biznesu i IT
- 03.03.2008
Service Oriented Architecture (SOA) nie jest rewolucyjnie nową technologią, która będzie wymagać nauczenia się wszystkiego od początku. Jest ewolucyjnym krokiem w kierunku współdziałania, zapewniając szybką reakcję na zmieniające się wymogi biznesu i szybkie rozpoznawanie jego potrzeb. I ta cecha jest cenna dla biznesu, który zawsze marzył o technologicznej strukturze dostatecznie elastycznej w reakcjach na zmieniające się procesy biznesowe.
Service Oriented Architecture (SOA) nie jest rewolucyjnie nową technologią, która będzie wymagać nauczenia się wszystkiego od początku. Jest ewolucyjnym krokiem w kierunku współdziałania, zapewniając szybką reakcję na zmieniające się wymogi biznesu i szybkie rozpoznawanie jego potrzeb. I ta cecha jest cenna dla biznesu, który zawsze marzył o technologicznej strukturze dostatecznie elastycznej w reakcjach na zmieniające się procesy biznesowe.
SOA jest pewnym stylem architektonicznym w organizowaniu IT. Nie definiuje standardów projektowania oprogramowania i nie jest nowym językiem specyfikacji, czy też weryfikacji oprogramowania. Nie definiuje również procesu wytwarzania oprogramowania czy metodyki prowadzenia projektów.
SOA to w praktyce zbiór wzorców, które można wykorzystać do opracowania nowej architektury systemu IT. Rozwój protokołów umożliwiających komunikowanie się systemów heterogenicznych, rozpowszechnienie standardów, takich jak XML, SOAP, HTTP i WDSL, oraz rozwiązań warstwy pośredniczącej, m.in. ESB (Enterprise Service Bus), stanowi dzisiaj główny czynnik popularności SOA.
W każdej organizacji, w ramach IT funkcjonują aplikacje, które zazwyczaj ogólnie klasyfikuje się jako back-end (zaplecza) i front-end (prezentacji). Aplikacje kategorii back-end mogą być uważane za połączenie warstwy biznesowej z warstwą danych. Poziom front-end to połączenie wszystkich warstw prezentacji.
SOA dotyczy warstwy back-end i opisuje najlepsze sposoby organizacji zaplecza aplikacyjnego, zapewniając głównie wysoką elastyczność (szybsze reakcje na zmiany) i wielodostępność istniejących zasobów IT, które to cechy czynią z niej jedną z bardziej atrakcyjnych architektur przedsiębiorstwa.
W koncepcji SOA zaplecze aplikacyjne przedsiębiorstwa rozbijane jest na zestaw usług. Każda taka usługa wykonuje specyficzne zadanie biznesowe. Usługi mogą być powiązane w zestaw tworzący pewną formę procesu biznesowego. SOA oddziela logikę procesu od logiki biznesowej. Logika biznesowa udostępniana jest jako usługa. Logika procesu jest tworzona poprzez połączenie tych usług.
Procedura łączenia usług w formę procesu biznesowego nazywana jest aranżacją (orchestration). Do budowania logiki procesu używane są specjalistyczne języki, takie jak BPEL (Business Process Execution Language), natomiast silnik aranżacji zapewnia obsługę wykonawczą BPEL.
BPEL - Business Process Execution Language. Formularz XML do definiowania procesów biznesowych, które współdziałają z jednostkami zewnętrznymi za pośrednictwem web services.
JAX-WS - Java API for XML - based web services. Referencyjna implementacja dla Java API web services i aplikacji webowych XML opartych na SOAP (Simple-Object Application Protocol).
SOAP with Attachment. API, które umożliwia pisanie aplikacji wymiany komunikatów SOAP, zamiast używania tradycyjnych metod wymiany komunikatów Java.
SOAP MTOM - Message Transmission Optimization Mechanism. Metoda optymalizacji transmisji komunikatów SOAP.
WS-Addressing. Wykorzystuje elementy XML do identyfikowania punktów końcowych web services w celu zabezpieczania identyfikacji end-to-end w komunikatach.
WS-Policy. Model ogólny zapewniający składnię opisującą zasady polityki web services.
WS-Reliable Messaging. Pozwala na gwarantowane dostarczanie komunikatów pomiędzy rozproszonymi aplikacjami, nawet wtedy, kiedy zawodzi system lub sieć.
Usługa jest specyficznym zadaniem biznesowym. Pierwszym krokiem w jej budowaniu jest rozpoznanie pożądanych usług w systemie. Analityk biznesowy powinien zidentyfikować powtarzalne zadania biznesowe, a także określić ich składowe. Takie zadania mogą być eksponowane jako usługi.
Z chwilą zidentyfikowania usług, kolejnym krokiem powinna być ich implementacja. Usługi muszą być luźno powiązane i autonomiczne, aby mogły być wywoływane z klienta dowolnego typu, niezależnie od języka i platformy, w jakich zostały zaimplementowane. Jedną z dróg eksponowania usług biznesowych w technologii SOA są web services.
SOA dąży do maksymalnej powtarzalności. Istniejące logiki biznesowe mogą być eksponowane w formie usług poprzez dopisanie odpowiedniej otoczki programowej, która sprawi, że logika biznesowa będzie dostępna dla różnych systemów w środowisku heterogenicznym.
Większość zmian biznesowych jest związana z logiką procesu, a nie z logiką biznesu. Znacznie częściej wprowadzane są nowe procesy lub modyfikowane procesy istniejące, przy jednoczesnym utrzymaniu rdzenia biznesu w postaci niezmienionej. Dlatego też implementacja takich zmian wymaga jedynie modyfikacji lub utworzenia np. nowych skryptów BPEL, co zapewnia szybką reakcję na zmiany. Jeżeli trzeba dodać zadanie biznesowe, to wystarczy zaprojektować i przetestować jedynie usługę zawierającą tę logikę biznesową. W związku z tym, że architektura SOA zapewnia możliwość projektowania przyrostowego, obniża zarówno ryzyko ogólne, jak i koszt zmian.
SOA ma zapewniać zmodularyzowany system, który może elastycznie reagować na zmiany, poprawiać wydajność biznesu i umożliwiać wyzwolenie sprawności biznesu w obliczu konkurencji. Ale określenie, jakie usługi biznesowe muszą być utworzone, jak powinny funkcjonować i być zarządzane, nie jest zajęciem łatwym.
Z chwilą utworzenia usług biznesowych pojawiają się kolejne komplikacje. Jakich usług używa biznes i które są dla niego dostępne? Czy istnieją reguły zmiany, oceny i zatwierdzania usług? Jeżeli usługi ulegają zmianie, to kto odczuje tego skutki i na jakie inne usługi będzie to wpływać? Jak zaradzić sytuacjom, gdy coś idzie nie tak? Czy poziom usług spełnia wymagania QoS (Quality of Service)?