Małymi krokami do celu

Z SOA wiązane są nadzieje na sprawną przebudowę infrastruktury IT w biegu. Im bardziej dynamiczny biznes, tym więcej może skorzystać na dobrej implementacji SOA. Także im więcej sprzymierzeńców, którzy podzielają wizję SOA, tym lepiej. Pomocne jest w szczególności pozyskanie silnych partnerów w ramach organizacji, szczególnie ze sfery zarządzania biznesowego, którzy rozumieją konieczność obniżki kosztów i przyspieszenia reakcji na zmiany w całej organizacji.

Taka wspólna wizja może być rozległa, ale opłaca się startować z małym projektem. Dobrze jest zaczynać od udostępnienia w formie usługi kilku tradycyjnych aplikacji o krytycznym znaczeniu, zapewniając na początek dostęp do ważnych danych i funkcji innym aplikacjom. Można też użyć współdzielonych usług do wyeliminowania redundancji wśród kilku trudnych do utrzymania aplikacji, których funkcjonalność się pokrywa. Takie projekty mogą przynosić widoczne korzyści m.in.:

• ograniczenie kosztów integracji infrastruktury IT i szybsze reagowanie na potrzeby;
• zwiększenie elastyczności i efektywności działania w obliczu takich wyzwań, jak: fuzje i przejęcia, konsolidacja oraz konieczność przestrzegania przepisów i regulacji prawnych;
• uproszczenie procesu tworzenia, serwisowania i eksploatacji aplikacji oraz obniżenie związanych z tym kosztów;
• zapewnienie działom IT elastyczności pozwalającej sprostać stale zmieniającym się potrzebom przedsiębiorstwa.

Należy przede wszystkim odpowiedzieć sobie na pytanie, jakie są te problemy biznesowe, które próbujemy rozwiązać, i jak się one mają do innych obszarów funkcjonalnych organizacji?

Można to osiągnąć na etapie przygotowania projektu. We współpracy ze specjalistami od biznesu trzeba przeglądnąć i zracjonalizować procesy w określonych dziedzinach. Zazwyczaj większą część takiej pracy można wykonać po stronie biznesowej, w ramach restrukturyzacji procesów. Po stronie IT należy je natomiast przeanalizować i zdecydować, gdzie ich nowa automatyzacja jest możliwa.

Każda inicjatywa SOA jest unikatowa, tak więc proces planowania może być mniej lub bardziej rozciągnięty w czasie.

Przed wdrożeniem należy dokładnie zbadać otoczenie i przyjrzeć się temu, na co ma się wpływ. Podstawową zasadą SOA, szczególnie w jej wczesnej fazie, jest skupienie się na czymś, co jest możliwe i co się ma, unikając jednocześnie praktyk czy technologii, które będą skutkować w przyszłości niemożnością współdziałania czy rozszerzania.

Nieodzowna do tego celu inwentaryzacja jest procesem wieloetapowym. Po pierwsze, należy udokumentować źródła danych i istniejące aplikacje, które będą wymagane w początkowym wdrożeniu - pamiętając o zidentyfikowaniu usług partnerskich poza zaporą ogniową, koniecznych do połączenia lub skatalogowania tak jak usługi wewnętrzne. Po drugie, należy zidentyfikować technologie, które się posiada i które będą odgrywać rolę w implementacji SOA. Jest to duży zakres prac, ale też niekoniecznie do wykonania przed projektem wstępnym. Nie może być jednak ignorowany, jeżeli to SOA jest celem, a nie ograniczony projekt.

Narzędzia SOA

Głównymi poziomami infrastruktury opartej na SOA są brokery usług, motory aranżacji, środowiska warstw pośredniczących opartych na wymianie wiadomości oraz narzędzia zarządzania na poziomie usług.

Infrastruktura brokerów zapewnia możliwość wielokrotnego użycia usług, pozwalając projektantom na budowanie nowych usług drogą definicji przepływu zadań, które łączą usługi już istniejące. Projektanci używają często graficznych narzędzi definiowania procesów, pozwalające im na specyfikowanie zadań aranżacji, zależności, routingu i kroków procesu za pomocą diagramów. Podejście to nazywa się także projektowaniem typu model-driven. Po zdefiniowaniu takie wizualne modele procesów mogą być kompilowane w definicje reguł, sterujących wykonywaniem wielostopniowych interakcji, takich jak złożone przekształcenia i reguły routingu w ramach platform heterogenicznych.

Środowiska MOM (Message-Oriented Middleware) zapewniają możliwość ponownego użycia usługi, przewidując protokoły: gwarantowanej dostawy wiadomości (reliable messaging), powiadamiania o zdarzeniach oraz publikowania i subskrypcji, które łączą punkty końcowe aplikacji heterogenicznych w szynę usługową przedsiębiorstwa.

Zarządzanie infrastrukturami na poziomie usług zapewnia monitorowanie, optymalizowanie, sterowanie i integrację rozproszonych środowisk aplikacyjnych. Bardziej rozpowszechnionym określeniem tej funkcjonalności jest WSM (Web Sentice Management). Infrastruktury WSM pomagają zapewnić: wydajność, niezawodność, dostępność, zarządzanie operacyjne, zarządzanie cyklem życia, a także bezpieczeństwo web services w ramach środowiska SOA. Aczkolwiek coraz więcej narzędzi WSM także monitoruje i egzekwuje poziom usług w środowiskach implementujących MOM i inne protokoły warstw pośredniczących, dla których "zarządzanie poziomem usług" jest pojęciem bardziej odpowiednim, niż specyficzny dla warstw pośredniczących termin WSM.

Firmy mogą implementować SOA bez funkcjonalności zarządzania poziomem usług, ale na dłuższą metę to się nie opłaca. Jeżeli SOA odniesie sukces, to będzie konieczna dostępność klasy "24/7", gwarantowana dostawa wiadomości i optymalizacja wydajności na magistrali usług, łączącej wszystkie punkty końcowe usług.

Standardy SOA

OASIS (Organization for the Advancement of Structured Information Standards) powołała dwa komitety techniczne w celu ujednolicenia różnych wizji SOA.

W kwietniu 2004 r. w ramach OASIS powołano komitet techniczny Electronic Business SOA (ebSOA), a w lutym 2005 komitet techniczny SOA reference Model (SOA-RM). Nakładanie się zakresów obu tych grup jest dość znaczne, ale generalny podział odpowiedzialności jest wyraźny.

Komitet techniczny ebSOA definiuje architekturę referencyjną, wskazówki i najlepsze praktyki dla implementacji SOA w środowiskach biznes-biznes, które implementują standardy ebXML. Komitet definiuje także "mapę drogową" dla OASIS ebXML Technical Architecture. Grupa podejmuje próbę skorelowania ebXML Technical Architecture z bieżącymi zmianami, wprowadzanymi do różnych standardów ebXML, które adresują takie wymagania B2B, jak brokery usług, gwarantowany messaging, aranżacje usług.

Zajmuje się ona także tym, jak standardy ebXML mają rozwijać się w kierunku bardziej bezpośredniej integracji z rosnącym zbiorem standardów web services definiowanych przez OASIS, W3C i gdzie indziej. Dokument ebSOA dotyczący dobrych praktyk ma pojawić się w połowie roku 2006.

Komitet SOA-RM definiuje szerszy model referencyjny, który może objąć ebXML, web services i inne środowiska implementacyjne. Jednym z głównych celów komitetu jest zdefiniowanie zestawu koncepcji SOA, elementów funkcjonalnych, wzorców architektonicznych i dobrych praktyk, które mogą być zastosowane do różnych środowisk implementacyjnych. Po nadto grupa nakreśliła istotne rozróżnienie pomiędzy implementacjami SOA o różnej złożoności:

• Simple SOA - dopuszcza pojedynczą, współdzieloną usługę, w odniesieniu do której nie ma wymagań gwarantowanego systemu przesyłania komunikatów (messaging), długookresowej aranżacji czy QoS.
• Intermediate SOA - dopuszcza wiele usług współdzielonych, które są prezentowane odbiorcy za pośrednictwem pojedynczej, "fasadowej" usługi; funkcjonują i są zarządzane w tej samej domenie administracyjnej; mogą wymagać procesów transakcyjnych, długookresowej aranżacji i QoS.
• Complex SOA - dopuszcza wiele współdzielonych usług, które funkcjonują i są zarządzane w jednej lub więcej domenach administracyjnych, wymagają gwarantowanej wymiany wiadomości, obsługi transakcji, długookresowej aranżacji i wymuszani polityk QoS w interakcji z innymi usługami.

SOA i web services

Często można usłyszeć opinię, że prawdziwa implementacja SOA wymaga pełnego stosu standardów web services, obejmującego WSDL, SOAP i UDDI.

Niemniej jednak infrastruktury SOA są implementowane dzisiaj na różnorodnych platformach i środowiskach pośredniczących, językach programowania i narzędziach projektowych. Ograniczoną formę SOA można implementować w tradycyjnych środowiskach warstw pośredniczących, takich jak CORBAczy DCOM.

Jednak takie implementacje, wykorzystujące technologie poprzedzające web services, są mocno powiązane z modelem obiektowym, metodami i API właściwymi dla poszczególnych systemów operacyjnych i platform aplikacyjnych. W konsekwencji zmiany w tych platformach mogą zakłócać współdziałanie z wykorzystującymi je usługami.

Web services są warstwą pośredniczącą i środowiskiem projektowym, które można uznać za niezależne od platformy. Umożliwiają bardziej kompletną wirtualizację usługi, jej wyabstrahowanie i wielokrotne użycie, niż jakiekolwiek wcześniejsze środowisko. Dlatego też web services są preferowanym środowiskiem dla SOA.

Problem polega jednak na tym, że kluczowe standardy usług webowych nie zostały jeszcze w pełni ukończone, ratyfikowane czy szerzej adoptowane przez dostawców i użytkowników. Według badań IDG Research Group, specjaliści IT postrzegają niekompletność i niedojrzałość standardów web services za jeden z najważniejszych czynników powstrzymujących ich przed implementacją SOAw swoich organizacjach.

Zbiór standardów usług webowych, tak jak i SOA, jest w trakcie opracowywania. Nie jest to jeszcze w pełni funkcjonalna alternatywa dla starszych protokółów middleware, zorientowanych na brokering obiektów czy wymianę komunikatów. Nie jest to też zunifikowany zestaw specyfikacji pod nadzorem i zarządzaniem jednego zespołu autorskiego. Jest on definiowany przez różne organizacje (OASIS, W3C) i różne alianse dostawców.

Ponadto istnieją znaczące różnice pomiędzy dostawcami w kwestii, które specyfikacje powinny dominować w takich obszarach, jak sfederowana tożsamość, gwarantowana wymiana wiadomości, powiadamianie o zdarzeniach i transakcje.

Nawet w obszarach funkcjonalnych, w których przemysł już wypracował standardy, mogą upłynąć lata, zanim większość dostawców zaimplementuje te standardy w swoich produktach i przebrnie przez problemy związane z różnorodną ich implementacją.

Do momentu, aż nastąpi zwrot branży w kierunku uniwersalnych, kompletnych standardów web services dla różnych poziomów funkcjonalności, usługi webowe nie będą kompletnym środowiskiem implementacyjnym dla SOA.

Nie oznacza to jednak, że nie można implementować SOA. Współużytkowanie i wielokrotne używanie można osiągnąć również w infrastrukturze niejednorodnej. Do opanowania tej opornej materii można wykorzystywać infrastrukturę elastycznej szyny usług przedsiębiorstwa (ESB), która może zapewnić niezależne odwzorowania pomiędzy różnorodnymi standardami, wersjami i implementacjami.

Produkty ESP dostarcza wielu dostawców warstw pośredniczących, jak np. IBM, Sonic Software, Tibco Software czy webMethods. Produkty ESB zapewniają niektóre lub prawie wszystkie mechanizmy niezbędne dla infrastruktury SOA:

• Obudowanie tradycyjnych środowisk w interfejsy WS-, a tym samym obsługa integracji z środowiskiem dziedziczonym;
• Zapewnienie współdziałania "każdy z każdym" poprzez brokery integracyjne, które zapewniają aranżacje, transformację i usługi routingu wśród rozproszonych usług, aplikacji i repozytoriów danych;
• Obsługa monitorowania zawartości i wymuszanie wydajności, bezpieczeństwa i innych polityk przedsiębiorstwa dotyczących ruchu web services;
• Obsługa przepływu wiadomości między rozproszonymi usługami;
• Obsługa gwarantowanej wymiany wiadomości, koordynacji transakcji i innych wzorców interakcji;
• Obsługa zdecentralizowanej wymiany wiadomość typu P2R