Architektura zorientowana na usługi (SOA) pojawiła się na początku tego wieku jako ewolucja obliczeń rozproszonych. Przed SOA usługi były rozumiane jako końcowy efekt procesu tworzenia aplikacji. W architekturze SOA sama aplikacja składa się z usług. Usługi mogą być dostarczane pojedynczo lub łączone jako komponenty w większej, złożonej usłudze.
Usługi współdziałają przez sieć przy użyciu protokołu takiego jak REST lub SOAP (Simple Object Access Protocol). Usługi są luźno powiązane, co oznacza, że interfejs usługi jest niezależny od podstawowej implementacji. Programiści lub integratorzy systemów mogą łączyć jedną lub więcej usług w aplikację, niekoniecznie wiedząc, w jaki sposób każda usługa jest implementowana.
Ten artykuł zawiera omówienie Java SOA i kluczowe cechy architektura zorientowana na usługi zaimplementowana przy użyciu usług internetowych opartych na SOAP. Omówię też pokrótce SOA i mikrousługi oraz omówię różnicę między usługami sieciowymi opartymi na RESTful i SOAP w Javie.
Dlaczego architektura zorientowana na usługi?
SOA odpowiada na trzy typowe wyzwania przedsiębiorstwa :
- Szybko reaguj na zmiany biznesowe.
- Wykorzystaj istniejące inwestycje w infrastrukturę.
- Wspieraj nowe kanały interakcji z klientami, partnerami i dostawcami.
Infrastruktura przedsiębiorstwa jest heterogeniczna w różnych systemach operacyjnych, aplikacjach, oprogramowaniu systemowym i infrastrukturze aplikacji. W rezultacie wiele systemów przedsiębiorstwa składa się ze złożonych i niespójnych aplikacji dostarczających zakres współzależnych usług. Istniejące aplikacje obsługujące bieżące procesy biznesowe są krytyczne, więc rozpoczynanie od zera lub modyfikowanie ich jest delikatną propozycją. Jednak przedsiębiorstwa muszą mieć możliwość modyfikowania i rozszerzania infrastruktury technicznej, aby sprostać wymaganiom biznesowym.
Jak w porównaniu do monolitycznego archi tecture, luźno powiązany charakter SOA sprawia, że podłączanie nowych usług lub uaktualnianie istniejących usług do nowych wymagań biznesowych jest stosunkowo łatwe. Zapewnia również opcję udostępniania usług w różnych kanałach oraz prezentowania starszych aplikacji jako usług, chroniąc w ten sposób inwestycje w infrastrukturę.
Ponieważ są one luźno powiązane, komponenty SOA można zmieniać przy minimalnym wpływie na inne składniki . Komponenty można również dodawać do architektury w ustandaryzowany sposób i można je skalować w celu uwzględnienia obciążenia.
Jako przykład rozważ, w jaki sposób przedsiębiorstwo może wykorzystać zestaw istniejących aplikacji do utworzenia nowego, złożona aplikacja łańcucha dostaw. Chociaż istniejące aplikacje są heterogeniczne i rozproszone w różnych systemach, ich funkcjonalność jest ujawniana i dostępna za pomocą standardowych interfejsów.
Rysunek 1. Aplikacja łańcucha dostaw w architekturze zorientowanej na usługi
Kluczowe cechy architektury SOA
SOA może być tak prosta, jak pojedynczy komponent zużywający usługi świadczone przez inny komponent lub tak wyrafinowana, jak szereg komponentów współdziałających za pośrednictwem korporacyjnej magistrali usług, takiej jak ESB MuleSoft. Bez względu na skalę, kluczem do pomyślnego wdrożenia SOA używać jak najmniej złożoności, aby osiągnąć swoje cele. Twoje pierwsze i ostatnie pytanie powinno zawsze brzmieć: Czy ten projekt spełnia nasze wymagania biznesowe?
Niezależnie od skali lub złożoności, wzór architektury zorientowanej na usługi jest mniej więcej taki sam:
- Dostawcy usług ujawniają punkty końcowe i opisują dostępne akcje w każdym punkcie końcowym.
- Konsumenci usług wysyłają żądania i korzystają z odpowiedzi.
- Dostawcy usług generują komunikaty w celu obsługi żądań.
Wdrażanie usługi – architektura zorientowana
Aby zaimplementować architekturę SOA, należy rozpocząć od podstawowej architektury usług, a następnie zapewnić infrastrukturę, czyli protokoły i inne narzędzia umożliwiające komunikację i współdziałanie. Rysunek 2 przedstawia diagram typowej architektury usług.
Rysunek 2. Przykładowa architektura usługi
Na tym diagramie trzech konsumentów wywołuje usługi, wysyłając komunikaty do magistrali usług przedsiębiorstwa, która przekształca i kieruje komunikaty do odpowiedniej implementacji usługi . Mechanizm reguł biznesowych zawiera reguły biznesowe w usłudze lub w usługach. Warstwa zarządzania usługami zarządza działaniami, takimi jak audyt, fakturowanie i rejestrowanie.
Komponenty w tej architekturze są luźno powiązane, więc można je przełączać lub aktualizować przy stosunkowo minimalnym wpływie na aplikację jako całość. Daje to przedsiębiorstwu elastyczność w dodawaniu lub aktualizowaniu procesów biznesowych w razie potrzeby. W większości przypadków zmiany w poszczególnych usługach nie powinny mieć znacznego wpływu na inne usługi.
Usługi sieciowe oparte na protokole SOAP
Usługi internetowe zaimplementowane przy użyciu protokołu SOAP są nadal bardziej sztywne niż usługi sieciowe lub implementacja mikrousług zgodnych z REST, ale znacznie bardziej elastyczne niż we wczesnych latach architektury SOA. Tutaj tylko przyjrzymy się protokołom wysokiego poziomu wymaganym dla usług sieciowych opartych na SOAP.
SOAP, WSDL i XSD
SOAP, WSDL i XSD to podstawowa infrastruktura implementacji usługi WWW opartej na SOAP. WSDL jest używany do opisu usługi, a SOAP jest warstwą transportową do wysyłania komunikatów między konsumentami usług a dostawcami. Usługi komunikują się z komunikatami formalnie zdefiniowanymi przy użyciu schematu XML (XSD). jako interfejs usługi (luźno analogiczny do interfejsu Java). Implementacja odbywa się w klasach Java, a komunikacja w sieci odbywa się za pośrednictwem protokołu SOAP. Funkcjonalnie konsument szukałby usługi, pobierałby kod WSDL dla tej usługi, a następnie wywoływał usługę za pomocą protokołu SOAP.
Bezpieczeństwo usługi sieci Web
WS -I Specyfikacja podstawowego profilu 2.0 dotyczy bezpieczeństwa wiadomości. Ta specyfikacja koncentruje się na wymianie poświadczeń, integralności wiadomości i poufności wiadomości.
Wykrywanie usług internetowych
Gdy kamień węgielny wykrywania usług internetowych, UDDI (Universal Description, Definition and Integration) wyblakł do historii. W dzisiejszych czasach usługa sieciowa oparta na SOAP jest powszechna w taki sam sposób, jak każda inna usługa, za pośrednictwem adresu URL punktu końcowego. Jako przykład można użyć interfejsu punktu końcowego usługi JAX-WS i jego @WebService i @WebMethod adnotacje.
Tworzenie i wdrażanie usług internetowych
Programiści Java mają kilka opcji tworzenia i wdrażania opartych na protokole SOAP usług internetowych, w tym Apache Axis2 i Spring-WS; jednak standardem Java jest JAX-WS, Java API dla usług XML Web Services. Podstawową ideą JAX-WS jest tworzenie klas Java i dodawanie do nich adnotacji w celu utworzenia wymaganych artefaktów. Pod maską JAX-WS używa kilku pakietów Java, w tym JAXB, biblioteki ogólnego przeznaczenia do wiązania klas Java z XML.
JAX-WS ukrywa podstawową złożoność i protokoły przed programistą, usprawniając w ten sposób proces definiowania i wdrażania opartych na Javie usług SOAP. Nowoczesne środowiska Java IDE, takie jak Eclipse, obejmują pełną obsługę tworzenia usług sieciowych JAX-WS. Specyfikacja WS została również wybrana do ciągłego rozwoju w Dżakarcie EE.
Podsumowanie
Architektura zorientowana na usługi zaimplementowana z usługami sieciowymi opartymi na SOAP wymaga bardziej sztywnej i formalne definicje usług niż usługi sieciowe lub mikrousługi zgodne z REST. Jednak niektóre większe organizacje nadal preferują bardziej formalny styl narzucany przez SOAP. Wiele starszych systemów na dużą skalę jest również zbudowanych w oparciu o SOAP, a niektóre systemy B2B i systemy wewnętrzne wybierają usługi sieciowe oparte na SOAP dla swoich bardziej formalnie zdefiniowanych kontraktów API. Niezależnie od tego, czy tworzysz, czy utrzymujesz system korporacyjny na dużą skalę, zrozumienie wzorca SOA i możliwość oceny opcji jego wdrożenia przydadzą się w Twojej karierze programisty.