Was ist serviceorientierte Architektur?

Serviceorientierte Architektur (SOA) entstand zu Beginn dieses Jahrhunderts als Weiterentwicklung des verteilten Rechnens. Vor SOA wurden Services als Endergebnis des Anwendungsentwicklungsprozesses verstanden. In SOA besteht die Anwendung selbst aus Diensten. Services können einzeln oder als Komponenten in einem größeren, zusammengesetzten Service bereitgestellt werden.

Dienste interagieren über das Kabel mithilfe eines Protokolls wie REST oder SOAP (Simple Object Access Protocol). Services sind lose gekoppelt , was bedeutet, dass die Service-Schnittstelle unabhängig von der zugrunde liegenden Implementierung ist. Entwickler oder Systemintegratoren können einen oder mehrere Dienste in einer Anwendung zusammenstellen, ohne unbedingt zu wissen, wie jeder Dienst implementiert ist.

Dieser Artikel bietet einen Überblick über Java SOA und die wichtigsten Merkmale einer serviceorientierten Architektur, die mithilfe von SOAP-basierten Webdiensten implementiert wird. Ich werde auch kurz SOA und Microservices vergleichen und den Unterschied zwischen RESTful- und SOAP-basierten Webdiensten in Java diskutieren.

SOA und Webdienste

SOA und Webdienste werden häufig zusammengeführt, aber sie sind nicht dasselbe. SOA ist eine Architektur, mit der Entwickler mehrere Anwendungsdienste zu einem größeren zusammengesetzten Dienst kombinieren können. SOA kann mithilfe von SOAP-basierten Webdiensten oder REST-APIs oder manchmal einer Kombination aus beiden implementiert werden. Es ist wichtig zu verstehen, dass ein Dienst in SOA eine remote verfügbare Ressource ist, die auf Anforderungen reagieren kann. Ein Webdienst wird unter Verwendung bestimmter Protokolle implementiert.

Warum serviceorientierte Architektur?

SOA befasst sich mit drei allgemeinen Herausforderungen für Unternehmen:

  • Reagieren Sie schnell auf geschäftliche Änderungen.
  • Nutzen Sie vorhandene Infrastrukturinvestitionen.
  • Unterstützen Sie neue Kanäle der Interaktion mit Kunden, Partnern und Lieferanten.

Die Unternehmensinfrastruktur ist über Betriebssysteme, Anwendungen, Systemsoftware und Anwendungsinfrastruktur hinweg heterogen. Infolgedessen bestehen viele Unternehmenssysteme aus komplexen und inkonsistenten Anwendungen, die eine Reihe von voneinander abhängigen Diensten bereitstellen. Bestehende Anwendungen, in denen aktuelle Geschäftsprozesse ausgeführt werden, sind von entscheidender Bedeutung. Daher ist es eine heikle Angelegenheit, von vorne zu beginnen oder sie zu ändern. Unternehmen müssen jedoch in der Lage sein, die technische Infrastruktur zu modifizieren und zu erweitern, um den geschäftlichen Anforderungen gerecht zu werden.

SOA und Microservices

Microservices ist ein Architekturstil, der aus SOA entwickelt wurde. Beide sind verteilte Architekturen und bieten ein entkoppeltes Paradigma. Während serviceorientierte Architekturen die Infrastruktur stärker belasten, bietet Microservices einen flexibleren und leichteren Entwicklungsstil. Beide haben Vor- und Nachteile, und beide sind weit verbreitet. Im Allgemeinen wird SOA häufiger von etablierten Unternehmen implementiert oder gepflegt, die über die Ressourcen verfügen, um mehr Formalität zu unterstützen. Microservices spricht häufig neue oder wachsende Unternehmen an, die Agilität benötigen.

Im Vergleich zu einer monolithischen Architektur ist es aufgrund der lockeren Kopplung von SOA relativ nahtlos, neue Dienste anzuschließen oder vorhandene Dienste für neue Geschäftsanforderungen zu aktualisieren. Es bietet auch die Möglichkeit, Dienste über verschiedene Kanäle hinweg nutzbar zu machen und ältere Anwendungen als Dienste verfügbar zu machen, wodurch Infrastrukturinvestitionen geschützt werden.

Da sie lose gekoppelt sind, können SOA-Komponenten mit minimaler Auswirkung auf andere Komponenten geändert werden. Komponenten können der Architektur auch auf standardisierte Weise hinzugefügt und auf die Last skaliert werden.

Stellen Sie sich als Beispiel vor, wie ein Unternehmen eine Reihe vorhandener Anwendungen verwenden könnte, um eine neue, zusammengesetzte Supply-Chain-Anwendung zu erstellen. Während die vorhandenen Anwendungen heterogen und auf verschiedene Systeme verteilt sind, wird ihre Funktionalität über Standardschnittstellen verfügbar gemacht und darauf zugegriffen.

Matthew Tyson

Schlüsselmerkmale von SOA

SOA kann so einfach sein wie eine einzelne Komponente, die Dienste verbraucht, die von einer anderen Komponente bereitgestellt werden, oder so komplex wie eine Reihe von Komponenten, die über einen Enterprise Service Bus wie den ESB von MuleSoft interagieren. Unabhängig von der Größe besteht der Schlüssel zu einer erfolgreichen SOA-Implementierung darin, möglichst wenig Komplexität zu verwenden, um Ihre Ziele zu erreichen. Ihre erste und letzte Frage sollte immer lauten: Entspricht dieses Design unseren Geschäftsanforderungen?

Unabhängig von Umfang oder Komplexität ist das Muster einer serviceorientierten Architektur mehr oder weniger dasselbe:

  • Dienstanbieter legen Endpunkte offen und beschreiben die verfügbaren Aktionen an jedem Endpunkt.
  • Service-Konsumenten stellen Anfragen und konsumieren Antworten.
  • Dienstanbieter generieren Nachrichten zur Bearbeitung von Anforderungen.

Serviceorientierte Architektur implementieren

Um SOA zu implementieren, beginnen Sie mit der grundlegenden Dienstarchitektur und stellen dann die Infrastruktur bereit, dh Protokolle und andere Tools, die Kommunikation und Interoperabilität ermöglichen. Abbildung 2 zeigt ein Diagramm einer typischen Dienstarchitektur.

Matthew Tyson

In diesem Diagramm rufen drei Verbraucher Dienste auf, indem sie Nachrichten an einen Unternehmensdienstbus senden, der die Nachrichten transformiert und an eine geeignete Dienstimplementierung weiterleitet. Eine Geschäftsregel-Engine enthält Geschäftsregeln in einem Dienst oder dienstübergreifend. Eine Service-Management-Schicht verwaltet Aktivitäten wie Überwachung, Abrechnung und Protokollierung.

Komponenten in dieser Architektur sind lose miteinander verbunden, sodass sie mit relativ geringen Auswirkungen auf die gesamte Anwendung ausgetauscht oder aktualisiert werden können. Dies gibt dem Unternehmen die Flexibilität, Geschäftsprozesse nach Bedarf hinzuzufügen oder zu aktualisieren. Änderungen an einzelnen Diensten sollten zum größten Teil keine großen Auswirkungen auf andere Dienste haben.

SOAP vs RESTful Webdienste

Es ist möglich, den SOA-Stil zu übernehmen und mit REST zu implementieren, beispielsweise mithilfe der JAX-RS-API oder des Spring Boot Actuator. Diese Diskussion ist jedoch für diesen Artikel nicht zulässig. Unter "SOAP vs REST vs JSON" finden Sie einen nützlichen Vergleich von SOAP vs RESTful-Webdiensten. Es gibt auch einige Überschneidungen zwischen RESTful-Webdiensten und dem leichteren Stil, der mit Microservices verbunden ist.

SOAP-basierte Webdienste

Mit SOAP implementierte Webdienste sind immer noch starrer als eine RESTful-Webdienst- oder Microservices-Implementierung, aber weitaus flexibler als die Anfänge von SOA. Hier sehen wir uns nur die allgemeinen Protokolle an, die für SOAP-basierte Webdienste erforderlich sind.

SOAP, WSDL und XSD

SOAP, WSDL und XSD sind die grundlegende Infrastruktur einer SOAP-basierten Webdienstimplementierung. WSDL wird zur Beschreibung des Dienstes verwendet, und SOAP ist die Transportschicht zum Senden von Nachrichten zwischen Dienstkonsumenten und -anbietern. Dienste kommunizieren mit Nachrichten, die mithilfe des XML-Schemas (XSD) formal definiert wurden. Sie können sich WSDL als die Schnittstelle des Dienstes vorstellen (lose analog zu einer Java-Schnittstelle). Die Implementierung erfolgt in Java-Klassen, und die Kommunikation über das Netzwerk erfolgt über SOAP. Funktionell würde ein Verbraucher nach einem Dienst suchen, die WSDL für diesen Dienst abrufen und den Dienst dann über SOAP aufrufen.

Sicherheit von Webdiensten

Die WS-I Basic Profile 2.0-Spezifikation befasst sich mit der Nachrichtensicherheit. Diese Spezifikation konzentriert sich auf den Austausch von Anmeldeinformationen, die Nachrichtenintegrität und die Vertraulichkeit von Nachrichten.

Webdiensterkennung

UDDI (Universal Description, Definition and Integration), einst der Eckpfeiler der Webdiensterkennung, ist in die Geschichte eingegangen. Heutzutage ist es üblich, einen SOAP-basierten Webdienst wie jeden anderen Dienst über eine Endpunkt-URL verfügbar zu machen. Als Beispiel könnten Sie die JAX-WS-Dienstendpunktschnittstelle und ihre @WebServiceund @WebMethodAnmerkungen verwenden.

Erstellen und Bereitstellen von Webdiensten

Java-Entwickler haben verschiedene Optionen zum Erstellen und Bereitstellen von SOAP-basierten Webdiensten, einschließlich Apache Axis2 und Spring-WS. Der Java-Standard ist jedoch JAX-WS, die Java-API für XML-Webdienste. Die Kernidee von JAX-WS besteht darin, Java-Klassen zu erstellen und mit Anmerkungen zu versehen, um die erforderlichen Artefakte zu erstellen. Unter der Haube verwendet JAX-WS mehrere Java-Pakete, darunter JAXB, eine Allzweckbibliothek zum Binden von Java-Klassen an XML.

JAX-WS verbirgt die zugrunde liegende Komplexität und Protokolle vor dem Entwickler und optimiert so den Prozess der Definition und Bereitstellung von Java-basierten SOAP-Diensten. Moderne Java-IDEs wie Eclipse bieten volle Unterstützung für die Entwicklung von JAX-WS-Webdiensten. Die JAX-WS-Spezifikation wurde auch für die Weiterentwicklung in Jakarta EE ausgewählt.

Fazit

Serviceorientierte Architekturen, die mit SOAP-basierten Webdiensten implementiert werden, erfordern strengere und formalere Dienstdefinitionen als RESTful-Webdienste oder Microservices. Einige größere Organisationen bevorzugen jedoch weiterhin den formelleren Stil von SOAP. Viele große Legacy-Systeme basieren ebenfalls auf SOAP, und einige B2B- und interne Systeme wählen SOAP-basierte Webdienste für ihre formell definierten API-Verträge. Unabhängig davon, ob Sie ein umfangreiches Unternehmenssystem entwickeln oder warten, das SOA-Muster zu verstehen und Ihre Optionen für dessen Implementierung bewerten zu können, wird Ihnen in Ihrer Programmierkarriere gute Dienste leisten.

Diese Geschichte: "Was ist serviceorientierte Architektur?" wurde ursprünglich von JavaWorld veröffentlicht.