Jeśli SOA, to z głową

SOA daje jeszcze jedną możliwość. Jeżeli rzeczywiście najpierw powstały kontrakty, potem implementacje - to w zasadzie system może "dynamicznie" składać poszczególne elementy infrastruktury. Wydaje się, że w związku z tym może nastąpić wielki powrót koncepcji UDDI, ale nie na zasadzie katalogu usług. Chodzi raczej o UDDI jako warstwę abstrakcji/wirtualizacji pośredniczącą w dostępie do usług i maskującą ich niedomagania. Inna sprawa, że centralne repozytorium usług i kontraktów i tak staje się potrzebne, tyle że z nieco innych powodów, np. aby te informacje były dostępne dla różnych zespołów, by nie dublować pracy, albo też na potrzeby wdrożenia ITIL.

Powszechny dziś model bez UDDI, w którym brak dynamicznego określania, jaka usługa będzie wywołana, wymusza odpowiednie zarządzanie na poziomie usług. A przecież nawet w przypadku jednolitych systemów pojawia się problem ze zdefiniowaniem aplikacji działającej prawidłowo. W praktyce chodzi o ustalenie, w którym momencie należy podjąć jakieś drastyczne operacje administracyjne, by umożliwić wykonanie procesu. Dziedzina określana jako SOA Governance jest na razie wspominana tylko w pracach analitycznych.

SOA w istotnym stopniu pozwala dostosowywać interfejs użytkownika. Dzięki temu, że medium komunikacyjnym jest usługa Web i towarzyszący jej kontrakt, sposób interakcji z systemem jest w zasadzie dosyć dowolny. Istnieją już nawet aplikacje, których producenci dają klientom dowolność, jaki rodzaj interfejsu chcą nadać wdrażanej aplikacji. Czy będzie to terminal, portal WWW, czy aplikacja z formatkami, sposób komunikacji i tak będzie taki sam. Przykładem może tu być planowana integracja mySAP z Office 2007 (Duet). Aplikacją umożliwiającą dostęp do systemu ERP będzie pakiet biurowy.

Niedawno IBM ogłosił wsparcie dla usług Web i koncepcji SOA na platformie Z/OS (mainframe). IBM Rational Cobol Generation generuje aplikacje na podstawie języka Enterprise Generation Language, który jest tłumaczony na COBOL. Dzięki temu w naturalny sposób udostępniana jest usługa na tej platformie, co na pewno uprości ewentualną integrację z "dużymi" systemami (a przy okazji pozwoli im odgrywać dalej istotną rolę, jeśli SOA rzeczywiście stanie się "głównym" nurtem tworzenia aplikacji). Innymi słowy, aplikacje działające na systemach mainframe będą w rozumieniu SOA spełniać rolę "usług transakcyjnych".

Architektura zamiast systemu

Użytkowników niezadowolonych z wykorzystywanego systemu ERP można znaleźć bardzo łatwo. Nawet gdy konkretna aplikacja ma dobre rozwiązania w jakimś obszarze działań, pozostałe moduły bywają mniej doskonałe i dotyczy to praktycznie dowolnego systemu zintegrowanego. Łączenie istniejących systemów wspomagających zarządzanie odbywa się dziś głównie na poziomie raportów. Integracja operacyjna dużych aplikacji wciąż jest rzadkością, co wynika z mnóstwa problemów towarzyszących wdrażaniu i utrzymywaniu środowisk integracyjnych.

Oracle ma przed sobą wielkie wyzwanie. Projekt Fusion ma ujednolicić naprawdę dużą gamę produktów przejętych na przestrzeni ostatnich dwóch lat. SAP zwalcza tymczasem narosły przez lata problem monolityczności swojego rozwiązania i stara się wyodrębnić z niego zbiory funkcjonalności, które będą nadawać się do traktowania jako usługi w ramach architektury SOA. Microsoft nie ogłasza długofalowych planów związanych z MBS. To nie przypadek - wiadomo, że projekt Green, czyli wysoko poziomowe API przeznaczone do tworzenia systemów biznesowych, podlega obecnie dużym zmianom. Z różnych pogłosek wynika, że prawdopodobnie będzie tworzone nowe rozwiązanie, jednak na pewno nie pojawi się ono wcześniej niż za 2-3 lata.

W takim układzie na rynku powstaje miejsce dla wyspecjalizowanych firm, które dysponując naprawdę dużą wiedzą branżową zaoferują najlepszy komponent realizujący konkretną funkcjonalność. Pozostaje jednak pytanie o kształt kontraktów dla elementów pisanych zgodnie z założeniami SOA, by integrator mógł złożyć z takich modułów kompletne rozwiązanie.

Wykorzystując swoją pozycję rynkową w dziedzinie aplikacji i wiedząc jednocześnie, że nic nie trwa wiecznie, SAP chce "uciec do przodu" i oferować architekturę, umożliwiając innym firmom włączanie do niej aplikacji specjalistycznych na określonych zasadach. Centralnym punktem tej strategii jest platforma NetWeaver, która jest pewnego rodzaju łącznikiem między aplikacjami SAP a runtime systemu ERP. To także "jądro" różnych odmian systemów SAP.

Jeżeli takie podejście zostanie uznane przez rynek, SAP zachowa pozycję rynkową, choć już niekoniecznie dzięki aplikacjom. Podobnie, jak się wydaje, będzie chciał działać Microsoft i Oracle, ale czy mniejsze specjalistyczne firmy na tym skorzystają - niekoniecznie, bowiem kontrakt narzuca filozofię działania całości systemu, która w różnych systemach jest różna.

Wnioski niejednoznaczne

Od czasu początków popularyzacji koncepcji Web Service krąży powiedzenie: "Standardy są wspaniałe. Każdy powinien mieć choć jeden". Niestety, takie podejście powoduje, że o ile udaje się ustalić podstawowe technikalia związane z komunikacją, to im mechanizmy są bardziej skomplikowane i powiązane z procesami biznesowymi, tym jest więcej sposobów wyrażenia tej samej informacji.

Tak więc, choć zasady budowy systemów SOA są znane, nadal trudno znaleźć otwartą architekturę SOA, złożoną z kawałków pochodzących od różnych dostawców bez wyrafinowanego rozwiązania integracyjnego. Dodając do tego potencjalne problemy z SLA, "zintegrowany system od jednego dostawcy" wydaje się sensownym wyborem.

Można też spojrzeć z drugiej strony. Nawet gdy system pochodzi od jednego dostawcy, który przyjął ustalony sposób generowania kontraktów (i standardów komunikacyjnych), "ułożenie" takiego rozwiązania w architekturze SOA przynosi wiele korzyści - zarówno twórcy rozwiązania, jak i ostatecznie - klientowi. Modułową architekturę ma już chyba każdy system dostępny na rynku.

Ale co z takiej organizacji ostatecznie wynika? Tak czy owak trzeba zainstalować 90% dużego systemu z niepotrzebnymi modułami tylko po to, by mieć np. bardziej rozbudowany system sprzedaży. Równocześnie w ramach negocjacji handlowych klient dowiaduje się, że musi zapłacić "odrobinę" więcej, niż by wynikało jedynie z faktu zakupu modułu XYZ.

Jeżeli natomiast wymiana informacji następuje zgodnie z założeniami SOA, aplikacja jest naprawdę elastyczna i poszczególne moduły są niezależne. Wtedy łatwo można "podmienić" funkcjonalność bez "ruszania" reszty systemu. Dodatkową korzyścią jest to, że testy w środowisku operacyjnym przed ostatecznym startem nowego elementu są znacznie szybsze, bo w zasadzie zmiany dotyczą tylko wyizolowanego modułu usługi.