Architektura zorientowana na usługi (SOA) to wzorzec architektoniczny w projektowaniu oprogramowania komputerowego, w którym komponenty aplikacji zapewniają usługi innym komponentom za pośrednictwem protokołu komunikacyjnego, zwykle w sieci. Zasady zorientowania na usługi są niezależne od jakiegokolwiek produktu, dostawcy czy technologii.
SOA po prostu ułatwia współpracę składników oprogramowania w różnych sieciach.
Usługi internetowe, które są zbudowane zgodnie z architekturą SOA, powodują, że usługi internetowe są bardziej niezależne. Same usługi internetowe mogą wymieniać dane między sobą, a ze względu na podstawowe zasady, na których są tworzone, nie wymagają żadnej interakcji międzyludzkiej, a także nie potrzebują żadnych modyfikacji kodu. Zapewnia bezproblemową interakcję między usługami sieciowymi w sieci.
SOA opiera się na kilku kluczowych zasadach, o których mowa poniżej
- Standardowa umowa serwisowa - usługi są zgodne z opisem usługi. Usługa musi mieć jakiś opis, który opisuje, o czym jest usługa. Ułatwia to aplikacjom klienckim zrozumienie działania usługi.
- Luźne sprzężenie - Mniejsza zależność od siebie. Jest to jedna z głównych cech usług sieciowych, która po prostu stwierdza, że powinna istnieć jak najmniejsza zależność między usługami sieciowymi a klientem wywołującym usługę sieciową. Jeśli więc funkcjonalność usługi zmieni się w dowolnym momencie, nie powinno to powodować awarii aplikacji klienckiej ani jej zatrzymywania.
- Abstrakcja usług - usługi ukrywają swoją logikę przed światem zewnętrznym. Usługa nie powinna ujawniać, w jaki sposób wykonuje swoją funkcjonalność; powinien po prostu poinformować aplikację kliencką o tym, co robi, a nie o tym, jak to robi.
- Możliwość ponownego wykorzystania usług - logika jest podzielona na usługi, których celem jest maksymalizacja ponownego wykorzystania. W każdej firmie programistycznej ponowne użycie jest dużym tematem, ponieważ oczywiście nie chciałoby się poświęcać czasu i wysiłku na tworzenie tego samego kodu w wielu aplikacjach, które ich wymagają. Dlatego po napisaniu kodu usługi sieciowej powinien on mieć możliwość pracy z różnymi typami aplikacji.
- Autonomia usług - usługi powinny mieć kontrolę nad logiką, którą zawierają. Usługa wie wszystko, jaką funkcjonalność oferuje, dlatego też powinna mieć pełną kontrolę nad zawartym w niej kodem.
- Bezpaństwowość usług - najlepiej byłoby, gdyby usługi były bezpaństwowe. Oznacza to, że służby nie powinny ukrywać informacji z jednego stanu do drugiego. Musiałoby to być zrobione z dowolnej aplikacji klienckiej. Przykładem może być zamówienie złożone w sklepie internetowym. Teraz możesz mieć usługę internetową, która poda cenę konkretnego przedmiotu. Jeśli jednak produkty zostaną dodane do koszyka, a strona internetowa przejdzie do strony, na której dokonujesz płatności, odpowiedzialność za przeniesienie ceny przedmiotu na stronę płatności nie powinna spoczywać na serwisie internetowym. Zamiast tego musi to zrobić aplikacja internetowa.
- Wykrywalność usług - usługi można wykryć (zwykle w rejestrze usług). Widzieliśmy to już w koncepcji UDDI, który przeprowadza rejestr, który może przechowywać informacje o usłudze sieciowej.
- Kompatybilność usług - usługi dzielą duże problemy na małe problemy. Nigdy nie należy osadzać całej funkcjonalności aplikacji w jednej usłudze, ale zamiast tego rozbijać usługę na moduły, z których każdy ma osobną funkcjonalność biznesową.
- Interoperacyjność usług - usługi powinny wykorzystywać standardy, które umożliwiają różnym abonentom korzystanie z usługi. W usługach sieciowych stosowane są standardy takie jak XML i komunikacja przez HTTP, aby zapewnić zgodność z tą zasadą.