Powiązanie usług

Luźne powiązanie usług (ang. loose coupling) oznacza dążenie do tego, aby projektant nowej usługi nie musiał czynić żadnych założeń, co do działania usług powiązanych. Powinna mu wystarczyć znajomość kontraktu. Projektowane usługi w żadnym stopniu nie powinny bazować na skutkach ubocznych działania innych usług, współdzielonych strukturach pamięci ani założeniach, co do specyficznego zachowania technologii, w której usługa została stworzona czy udostępniona.

Osiągnięciu luźnego powiązania między usługami sprzyja stosowanie standardowych mechanizmów komunikacji, opisu danych i usług. Pomagają one uniezależnić usługi od konkretnej platformy czy technologii, w której zostały stworzone i udostępnić je wszystkim potencjalnym zainteresowanym, niezależnie od środowiska, w którym działają.

Luźne powiązanie usług a także precyzyjna definicja kontraktu w architekturze usługowej są środkami do zapewnienia dużej odporności środowiska na zmiany. Po pierwsze, nowe funkcjonalności mogą być wdrażane mniejszymi porcjami (pojedyncze usługi) i nie powinny mieć żadnego wpływu na działania wcześniej uruchomionych funkcjonalności. Po drugie, w przypadku modyfikacji czy wymiany istniejących usług jest znacznie łatwiej ustalić, które funkcjonalności są od nich zależne i w związku z tym narażone na ewentualne błędy. W przypadku, gdy następują jakieś zmiany w systemach, z których korzystają usługi, znacznie łatwiej jest to ukryć przed użytkownikiem końcowym. Jeżeli nie naruszymy kontraktu, to modyfikacja implementacji usług powinna pozostać niezauważona.

Kolejna kwestia, istotna w podejściu SOA, to możliwość budowania nowych usług z wykorzystaniem funkcjonalności usług istniejących. W ten sposób na bazie usług podstawowych powstają usługi złożone (ang. composite services).

Podejście SOA promuje wielokrotne wykorzystywanie tych samych usług. Usługi powinny być projektowane tak, aby mogły być wykorzystywane przez wiele systemów konsumujących usługi. Z drugiej strony, należy dążyć także do tego, aby w przypadku budowy bardziej skomplikowanych funkcjonalności wykorzystywać gotowe usługi, zamiast ponownie implementować te same lub bardzo podobne funkcjonalności w nowych usługach. Jeśli takich, już istniejących, usług nie znajdziemy, a widać że budowana nowa usługa wymaga fragmentów funkcjonalności, które mają sens jako autonomiczne jednostki, warto wyodrębnić te funkcjonalności do odrębnych usług.

Przy konsekwentnym stosowaniu tej reguły otrzymamy wiele warstw wywołujących się wzajemnie usług, które pozwalają realizować coraz bardziej skomplikowaną logikę. Warstwami tymi mogą być na przykład: usługi adapterowe, integracyjne, biznesowe.

Usługi z poszczególnych warstw będą się różnić między sobą zarówno rodzajem logiki, jak i często sposobem jej implementacji. O ile usługi adapterowe będą zawierały więcej logiki technicznej i mogą wymagać implementacji w technologii systemu czy źródła danych, do którego będą się odwoływać, to usługi wyższych warstw będą zawierały coraz więcej logiki integracyjnej i biznesowej. Wskazane jest, aby usługi najwyższych poziomów implementować w językach wyższego poziomu (a nie na przykład w Javie czy C++). Ponad usługami biznesowymi często wprowadza się jeszcze warstwę procesów modelowanych i wykonywanych w narzędziach klasy BPM (Business Process Management), aby zapewnić automatyzację całych procesów biznesowych organizacji.

Kwestie technologiczne

Standardami najczęściej kojarzonymi z SOA jest, bez wątpienia, grupa standardów definiujących WebServices, czyli usługi sieciowe. Skojarzenie to jest jak najbardziej właściwe, gdyż WebServices dobrze nadają się do realizacji architektury SOA.

Wspomniane standardy zakładają udostępnianie funkcjonalności systemów w postaci usług o precyzyjnie zdefiniowanym interfejsie, niezależnym od środowiska i technologii, w której dana funkcjonalność jest zaimplementowana.