Kiedy się sprawdza?
- Piotr Pękała,
- 07.07.2009
Główną zaletą podejścia SOA jest przygotowanie organizacji na zmiany, o których nie wiemy zbyt dużo w momencie tworzenia rozwiązania.
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ę.