Na wstępie trzeba powiedzieć, czym SOA nie jest. Na pewno nie jest nowością. Pomysł architektury usługowej zrodził się wiele lat temu. SOA nie jest technologią samą w sobie. Nie jest synonimem Web Services i XML, choć ma z nimi wiele wspólnego. Z pewnością jednak jest jedną z najbardziej obiecujących nowoczesnych metod tworzenia systemów informatycznych i zarządzania nimi.

Środowiska informatyczne były tworzone w architekturze usługowej jeszcze na długo przed upowszechnieniem języka XML i Web Services. Początków idei SOA należy szukać w koncepcjach programowych komponentów wielokrotnego użytku, w programowaniu obiektowym, systemach modularnych, czy nawet interfejsach API. Współczesna architektura SOA czerpie z tego dorobku.

Koncepcja SOA wydaje się do bólu prosta: należy wydzielić najczęściej wykorzystywane kawałki logiki aplikacji i nadać im formę niezależnych usług dostępnych w sieci. SOA odnosi się do projektowania, tworzenia, wdrożenia i zarządzania aplikacjami w formie zatomizowanych usług. Brzmi niewinnie, ale w rzeczywistości SOA to rewolucja nie tylko w podejściu do tworzenia oprogramowania, ale również jego wykorzystania w środowisku korporacyjnym. "Wszystkie usługi istniejące w ramach SOA muszą być skupione wokół potrzeb biznesu" - doda w tym miejsku każdy konsultant.

Luźne związki

Jedną z cech architektury SOA jest to, że poszczególne komponenty są ze sobą luźno powiązane. Stanowi to zasadniczą różnicę wobec tradycyjnych, sztywnych technik wymiany danych między systemami informatycznymi.

Można próbować zilustrować to analogią. Przykładem sztywnego powiązania w ramach systemu jest operacja polegająca na wciśnięciu ściennego włącznika światła, która niechybnie spowoduje rozświetlenie pomieszczenia. Kontrprzykładem obrazującym luźne powiązanie jest telefoniczne zamówienie książki w sklepie. Ani zamawiający, ani sprzedawca nie kontrolują procesu druku książki, dlatego w tym przypadku nie ma mowy o sztywnym powiązaniu.

Zamawiając książkę telefonicznie można popełnić błąd, wynikający chociażby z nieporozumienia ze sprzedawcą przyjmującym zlecenie, ale rekompensatą jest większa elastyczność w procesie obsługi. Jeśli sprzedawca błędnie zanotuje numer ISBN, może zidentyfikować zamówioną książkę po tytule, nazwisku autora, nazwie wydawnictwa czy dzięki osobistym skojarzeniom. Jeśli książka nie będzie dostępna, może też zaproponować pozycję najbliższą oczekiwaniom zamawiającego.

SOA ma być właśnie architekturą elastyczną, łatwo adaptowalną i modyfikowalną. Gdy zachodzi konieczność zmiany funkcjonalnej w oprogramowaniu, nie trzeba wymieniać całego systemu na nowy (trzymając się przykładu z włącznikiem- nie trzeba wymieniać całej instalacji elektrycznej). Wystarczy zmodyfikować zależności pomiędzy istniejącymi już usługami, ewentualnie zaabonować nową usługę, która do tej pory nie występowała w systemie. Ponadto koncepcja SOA zakłada, że zależności między poszczególnymi usługami można stosunkowo łatwo analizować i optymalizować pod kątem uzyskania największej efektywności.

SOA a Web Services

Mimo tego, że architektura SOA słusznie bywa wiązana ze strukturami XML i usługami Web, to nie są to w pełni pojęcia tożsame. Usługi typu Web Services są specyficznym podzbiorem funkcjonalności wyrosłych z idei orientacji na usługi. Do wymiany informacji Web Services wykorzystują standardowe interfejsy komunikacyjne zbudowane m.in. w oparciu o protokół SOAP i język opisu usług WSDL. Podstawą idei SOA jest rozbicie funkcjonalności oprogramowania na mniejsze elementy komunikujące się ze sobą za pośrednictwem różnego rodzaju interfejsów, przy użyciu różnych interfejsów komunikacyjnych.

Na podstawie amerykańskiego wydania Computerworld opracował Piotr Waszczuk