SOA: marzenia o wspólnym języku biznesu i IT

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.

Główne protokoły SOA w przedsiębiorstwie Wiele implementacji protokołów dla web services i architekt

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.

SOA: marzenia o wspólnym języku biznesu i IT

Proces składania zamówień w środowisku SOA

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)?


TOP 200