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?