Między marzeniem a faktem

Co to jest SOA, czyli nie całkiem poważny słownik informatyka 2.0.

Co to jest SOA, czyli nie całkiem poważny słownik informatyka 2.0.

Żadna inna koncepcja ze świata informatyki nie obrosła taką liczbą mitów jak SOA. Fakty mieszają się z obietnicami, wizje z realnie istniejącymi technologiami, dobre pomysły ze złymi i niesprawdzonymi. Nie jest dziwne, że menedżerowie informatyki mają dziś mętlik w głowach. Spróbujmy podsumować kluczowe elementy.

Usługa internetowa (Web Service): Teoretycznie - oddzielenie definicji interfejsu od implementacji i technologii, opisanie go za pomocą standardu i umieszczenie w sieci. W praktyce - przeniesienie paradygmatu obiektowego i komponentowego z poziomu języka programowania i jednej platformy na poziom Internetu i intranetu, nic więcej. Uwaga: do sieciowego opóźnienia dodaj 100 ms.

Asynchroniczność: Wywołanie usługi SOA, które nie czeka na zakończenie. Teoretycznie - odpowiedź na kłopoty z internetową łącznością i dostępnością serwisów. W praktyce - budowa aplikacji korzystających z asynchronicznych wywołań wymaga napisania wielu z nich od nowa.

Architektura zdarzeniowa (Event-Driven Architecture): Podobno następca SOA. Zdecydowanie w kategorii "obietnice"; także pole do starej jak sama informatyka zabawy w "kto pierwszy wyznaczy niekompatybilny standard i zmusi innych do stosowania go".

Szyna usług (Enterprise Service Bus): Warstwa komunikacyjna dla wywołań SOA - aby wywołujący nie musiał się martwić, gdzie jest wywoływany. Ma rozplątywać "architekturę spaghetti", w praktyce przenosi ją na inny poziom. Kolejne 100 ms do wywołania.

Mashup: Aplikacja biznesowa skomponowana z serwisów SOA. Szczytna i potrzebna idea, ale na razie działa głównie w PowerPoincie.

Tożsamość (Identity): Warstwa SOA pozwalająca zapewnić "przezroczystą" autoryzację użytkowników i aplikacji w serwisach. Realnie - pole walki na śmierć i życie pomiędzy producentami technologii. Każdy głośno mówi, że chce wspierać "otwarty i neutralny standard" i robi dokładnie odwrotnie: stara się sabotować wspólne wysiłki i zmusić innych do przyjęcia swoich standardów.

Ontologia: Schemat dziedziny, w której działają usługi internetowe. Bez doktoratu z logiki oraz dwóch wolnych tygodni nie razbieriosz.

Agent: Nie, nie ten z list publikowanych przez IPN ani nie Smith z "Matrixa". Autonomiczny program, który realizuje za pomocą usług internetowych zadanie na zlecenie w ramach jasno zdefiniowanych kompetencji. Na razie - pieśń przyszłości.

OASIS: Dobry duch SOA. Organizacja odpowiedzialna za definiowanie i utrzymanie standardów. Choć jest krytykowana za swoje podejście do patentów i własności intelektualnej, w praktyce OASIS stoi na straży rynkowej równowagi pomiędzy zaciekle zwalczającymi się dostawcami technologii SOA.

XML: Choć niektórzy twierdzą, że to nowy rozmiar extra-medium large (i snują przypuszczenia, o który rozmiar chodzi...), to jednak w praktyce XML jest językiem, w którym można zapisać wszystko - byle tylko ktoś to potrafił odczytać i zinterpretować.

SOAP: Nie mylić z operą mydlaną. Wielu twierdzi, że SOAP to taka mniejsza CORBA; inni - że to tylko sposób na obejście firewalli, które mają pozamykane porty inne niż 80. Protokół dostępu do obiektów i usług sieciowych, fundament serwisów SOA.

Architektura korporacyjna (Enterprise Architecture): Mylnie utożsamiana z infrastrukturą. Realnie, architektura korporacyjna to opis aktualnego i (przede wszystkim) przyszłego funkcjonowania biznesu, ze szczególnym uwzględnieniem procesów i aplikacji. Termin nie do końca jeszcze opisany i rozumiany, ale którego znaczenia nie sposób pominąć.

Główny architekt: Człowiek w grubych okularach, który mówi projektantom procesów, usług i aplikacji SOA, jak i z czego mają budować swoje zabawki, by na końcu złożyły się w spójny obraz (patrz: architektura korporacyjna). Najbardziej niedowartościowana postać w organizacji - osoba o wpływie i odpowiedzialności porównywalnej z CEO, której - nie wiedzieć czemu - płaci się ułamek prezesowskiej pensji.

Bezpieczeństwo: Terra incognita i pięta achillesowa SOA. Aktualny stan to gdzieś pomiędzy prostym szyfrowaniem na poziomie https oraz tzw. password security (czyli autoryzowania się za każdym razem od nowa). Stan docelowy - z grubsza zdefiniowany standardami WS-*(patrz: OASIS).

Ład (Governance): Jedno z wielu zadań dla Głównego architekta, za które jest on wynagradzany w sposób nieproporcjonalny do znaczenia. Ład w usługach internetowych - a więc trzymanie się pewnych założeń i standardów przy konstruowaniu, opisywaniu i publikowaniu - ma mniej więcej takie znaczenie, jak przestrzeganie norm budowlanych przy stawianiu wieżowca. Na razie mało kto dostrzega znaczenie zapewnienia ładu w usługach internetowych.

SGML (Structured Generic Markup Language): Metajęzyk, matka wszystkich języków SOA: XML, WSDL, HTTP, SAML itd. Solidny kawał dobrej, teoretycznej roboty, której na co dzień nikt nie docenia, ale bez której nie byłoby żadnego postępu.

Przestawienie organizacji na SOA (SOA adoption): Droga, w którą wszyscy się wybieramy, dla której na razie brakuje map i przewodników, ale o której nieuchronności jesteśmy przekonani. Zmieni się nam, bagatela: architektura systemów, sposób budowania aplikacji, narzędzia, infrastruktura oraz kwalifikacje personelu. Żaden zdrowo myślący i rozliczany z kwartalnych wyników menedżer nie podjąłby takiego ryzyka - dlatego cały proces muszą przeprowadzić informatycy.

Transakcja SOA: Gwarancja, że jak pieniądze zejdą z jednego konta, to wejdą na inne - nawet w epoce Web 2.0. Transakcja SOA wykonywana jest w środowiskach heterogenicznych i rozproszonych. Do tego - potencjalnie asynchronicznie. Nic więc dziwnego, że takie transakcje na razie istnieją głównie w postaci dokumentów opisujących standardy (np. WS-Coordination).

Zwinność (agility): Po to właśnie robimy SOA - żeby pozwolić naszemu biznesowi elastycznie ("zwinnie") reagować na wymagania rynku. Słowo często używane także w kontekście wewnętrznych procesów działu informatyki: prowadząc projekty tzw. zwinnymi metodykami pozwalamy klientowi cieszyć się efektami szybciej niż tworząc rozwiązania w sposób standardowy ("ciężki"), zaś sam efekt jest bliższy oczekiwaniom tegoż klienta.

TCO (Total Cost of Ownership): Kolejny dobry powód, by robić SOA. Koszty utrzymania systemów są wysokie m.in. właśnie dlatego, że aplikacje są silnie z sobą powiązane i mało elastyczne.

Refactoring: Technika, która pozwoli użyć SOA do obniżenia TCO. A więc: dorabiamy do istniejącego systemu interfejs SOA. Następnie "uczymy" wszystkie powiązane aplikacje, aby korzystały z nowego interfejsu, zamiast odwoływać się bezpośrednio do implementacji. A potem wymieniamy implementację, wstawiając w to miejsce technologie dziesięć razy tańsze. Proste?