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.

Kiedy się sprawdza?
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ę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200