Co to jest architektura zorientowana na usługi?

Architektura zorientowana na usługi (SOA) pojawiła się na początku tego wieku jako ewolucja przetwarzania rozproszonego. Przed SOA usługi były rozumiane jako efekt końcowy procesu tworzenia aplikacji. W architekturze SOA sama aplikacja składa się z usług. Usługi mogą być świadczone indywidualnie lub łączone jako komponenty w ramach większej, złożonej usługi.

Usługi współdziałają przez sieć kablową 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, jak każda usługa jest zaimplementowana.

Ten artykuł zawiera omówienie architektury Java SOA i głównych cech architektury zorientowanej na usługi zaimplementowanej przy użyciu usług sieci Web opartych na protokole SOAP. Pokrótce porównuję również SOA i mikrousługi i omówię różnicę między usługami sieciowymi opartymi na RESTful i SOAP w Javie.

SOA i usługi sieciowe

SOA i usługi internetowe są często ze sobą powiązane, ale to nie to samo. SOA to architektura, która umożliwia programistom łączenie wielu usług aplikacji w większą, złożoną usługę. SOA można zaimplementować przy użyciu usług internetowych opartych na protokole SOAP lub interfejsów API REST, a czasem kombinacji obu. Ważne jest, aby zrozumieć, że w SOA usługa to każdy zdalnie dostępny zasób, który może odpowiadać na żądania. Serwis internetowy jest realizowany przy użyciu określonych protokołów.

Dlaczego architektura zorientowana na usługi?

SOA jest odpowiedzią na trzy typowe wyzwania dla przedsiębiorstw:

  • Szybko reaguj na zmiany biznesowe.
  • Wykorzystaj istniejące inwestycje infrastrukturalne.
  • Wspieraj nowe kanały interakcji z klientami, partnerami i dostawcami.

Infrastruktura przedsiębiorstwa jest heterogeniczna pod względem systemów operacyjnych, aplikacji, oprogramowania systemowego i infrastruktury aplikacji. W rezultacie wiele systemów korporacyjnych składa się ze złożonych i niespójnych aplikacji dostarczających szereg 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.

SOA i mikrousługi

Mikrousługi to styl architektoniczny wyewoluowany z architektury SOA. Obie są architekturami rozproszonymi i obie oferują paradygmat odsprzęgnięty. Podczas gdy architektura zorientowana na usługi jest bardziej obciążona infrastrukturą, mikrousługi oferują bardziej elastyczny i lekki styl programowania. Obie mają wady i zalety i obie są szeroko stosowane. Ogólnie rzecz biorąc, SOA jest częściej wdrażane lub utrzymywane przez istniejące przedsiębiorstwa, które mają zasoby umożliwiające obsługę większej liczby formalności. Mikrousługi często są atrakcyjne dla nowych lub rozwijających się organizacji, które wymagają elastyczności.

W porównaniu z architekturą monolityczną, 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 bezproblemowe. Zapewnia również możliwość korzystania z 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 komponenty. 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 zastanów się, jak przedsiębiorstwo może wykorzystać zestaw istniejących aplikacji do utworzenia nowej, złożonej aplikacji ł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.

Matthew Tyson

Kluczowe cechy SOA

SOA może być tak prosta, jak pojedynczy komponent korzystający z usług świadczonych przez inny komponent lub tak wyrafinowany, jak szereg komponentów współdziałających przez magistralę usług przedsiębiorstwa, taką jak ESB MuleSoft. Bez względu na skalę, kluczem do udanej implementacji SOA jest 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 wzorzec 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ą wnioski i przyjmują odpowiedzi.
  • Dostawcy usług generują wiadomości do obsługi żądań.

Wdrażanie architektury zorientowanej na usługi

Aby wdrożyć architekturę SOA, zaczynasz od podstawowej architektury usług, a następnie udostępniasz infrastrukturę, czyli protokoły i inne narzędzia umożliwiające komunikację i współdziałanie. Rysunek 2 przedstawia schemat typowej architektury usług.

Matthew Tyson

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łania, takie jak audyt, rozliczania i rejestrowania.

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 SOAP vs RESTful

Możliwe jest zaadaptowanie stylu SOA i zaimplementowanie go z REST, na przykład za pomocą JAX-RS API lub Spring Boot Actuator, ale ta dyskusja jest poza zakresem tego artykułu. Zobacz „SOAP vs REST vs JSON”, aby zapoznać się z przydatnymi porównaniami usług internetowych SOAP i RESTful. Istnieje również pewne nakładanie się usług internetowych RESTful i bardziej uproszczonego stylu skojarzonego z mikrousługami.

Usługi sieciowe oparte na SOAP

Usługi sieci Web zaimplementowane przy użyciu protokołu SOAP są nadal bardziej sztywne niż usługi internetowe obsługujące REST lub implementacje mikrousług, ale znacznie bardziej elastyczne niż wczesne dni architektury SOA. Tutaj przyjrzymy się tylko protokołom wysokiego poziomu wymaganym dla usług internetowych 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 odbiorcami usług a dostawcami. Usługi komunikują się z komunikatami formalnie zdefiniowanymi za pomocą schematu XML (XSD). Możesz myśleć o WSDL jako o interfejsie usługi (luźno analogicznym 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ług internetowych

Specyfikacja WS-I Basic Profile 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

Kiedyś kamień węgielny wykrywania usług internetowych, UDDI (Universal Description, Definition and Integration) przeszedł do historii. Obecnie 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 oraz jego adnotacji @WebServicei @WebMethodadnotacji.

Tworzenie i wdrażanie usług internetowych

Programiści Java mają kilka opcji tworzenia i wdrażania usług internetowych opartych na SOAP, w tym Apache Axis2 i Spring-WS; jednak standardem Java jest JAX-WS, Java API dla 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 wykorzystuje kilka pakietów Java, w tym JAXB, bibliotekę 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 usług SOAP opartych na języku Java. Nowoczesne środowiska Java IDE, takie jak Eclipse, obejmują pełną obsługę tworzenia usług internetowych JAX-WS. Specyfikacja JAX-WS została również wybrana do dalszego rozwoju w Dżakarcie EE.

Wniosek

Architektura zorientowana na usługi zaimplementowana z usługami sieciowymi opartymi na protokole SOAP wymaga bardziej sztywnych i formalnych definicji usług niż usługi internetowe 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 lub utrzymujesz system korporacyjny na dużą skalę, zrozumienie wzorca SOA i umiejętność oceny opcji jego wdrożenia przyda Ci się dobrze w Twojej karierze programistycznej.

Ta historia „Co to jest architektura zorientowana na usługi?” został pierwotnie opublikowany przez JavaWorld.