Kiedy się sprawdza?

Główną zaletą podejścia SOA jest przygotowanie organizacji na zmiany, o których nie wiemy zbyt dużo w momencie tworzenia rozwiązania.

Skrót SOA pochodzi od terminu Service Oriented Architecture, który oznacza architekturę nastawioną na usługi lub opartą na usługach. Pod tym pojęciem kryje się zestaw postulatów, rekomendacji i dobrych praktyk związanych z projektowaniem architektury systemów informatycznych. Dla przypomnienia, architektura oznacza strukturę logiczną systemu lub systemów informatycznych z wyodrębnionymi głównymi elementami składowymi i powiązaniami między nimi.

Podejście SOA zakłada budowę logiki rozwiązań w postaci luźno powiązanych usług. Usługą (ang. service) może być dowolny fragment funkcjonalności przydatnej dla użytkownika. Informacje o tym, co oznacza luźne powiązanie usług, znajdują się w dalszej części materiału.

Duży nacisk w SOA kładzie się na zapewnienie szerokiej dostępności usług. Aby to osiągnąć, należy przede wszystkim oprzeć interfejsy usług i mechanizmy wywoływania usług na otwartych i szeroko wykorzystywanych standardach, takich jak na przykład: XML i HTTP/HTTPS.

Usługi muszą być tak projektowane, aby zapewnić ich odpowiednią granularność (ang. granularity). Powinny one mieć odpowiednio dużo logiki, aby stanowić spójne i autonomiczne elementy funkcjonalności. Z drugiej strony nie mogą być zbyt duże, gdyż ogranicza to możliwość ponownego wykorzystania takiej usługi w nowych scenariuszach.

W praktyce granularność usług jest mniejsza (czyli zawierają one więcej funkcjonalności) niż np. granularność metod komponentów JavaBeans, ale jednocześnie będzie pewnie dużo większa niż granularność zleceń wykonywanych w scenariuszach integracji B2B. Dobrymi przykładami publicznych usług mogą być następujące operacje:
- pobierz dane klienta;
- stwórz klienta;
- zarejestruj interakcję z klientem;
- sprawdź wiarygodność klienta.

Składniki kontraktu

Kolejnym postulatem SOA dotyczącym budowy serwisów jest ustalenie kontraktu opisującego istotne aspekty działania serwisu.

Pierwszym elementem kontraktu jest opis funkcjonalności usługi z punktu widzenia jej użytkownika. Nie jest istotne, jak ta funkcjonalność jest zaimplementowana, jakie wewnętrzne algorytmy, techniki, języki programowania itp. zostały do tego użyte. Chodzi o funkcjonalność widoczną dla klienta.

Istotnym elementem kontraktu jest również definicja formatu danych wejściowych i wyjściowych oraz ewentualnych komunikatów o błędach czy wyjątków zwracanych przez usługę.
Ostatni element kontraktu to opis kwestii operacyjnych, takich jak: czasy dostępności usługi, czasy odpowiedzi, koszt wykonania usługi.

Kontrakt w żadnym wypadku nie powinien określać aspektów implementacyjnych i technicznych rozwiązania udostępniającego usługę.