Was ist SOA? 7 SOA-Schritte

Dieser Blog beschreibt die SOA-Schritte, die ein Unternehmen unternehmen muss, bevor es die Kosten- und Agilitätsvorteile einer serviceorientierten Unternehmensarchitektur wirklich erfolgreich realisieren kann. Es beschreibt, wofür SOA steht und die verschiedenen Phasen der SOA-Einführung, indem die Technologien, Prozesse und Best Practices beschrieben werden, die Unternehmen beim Erfolg ihrer serviceorientierten Architekturinitiativen unterstützen.

Was ist SOA?

Serviceorientierte Architektur (SOA) ist eine Art von Architektur, die im Softwaredesign verwendet wird und die Serviceorientierung unterstützt, wobei Dienste für andere Komponenten über ein Kommunikationsprotokoll über ein Netzwerk bereitgestellt werden.

Wofür steht SOA?

Die Definition von SOA, wie von Wikipedia zur Verfügung gestellt:

Serviceorientierte Architektur (SOA) ist ein Stil des Softwaredesigns, bei dem Dienste für die anderen Komponenten von Anwendungskomponenten über ein Kommunikationsprotokoll über ein Netzwerk bereitgestellt werden. Die Grundprinzipien einer serviceorientierten Architektur sind unabhängig von Anbietern, Produkten und Technologien. Ein Dienst ist eine diskrete Funktionseinheit, auf die aus der Ferne zugegriffen und unabhängig voneinander reagiert und aktualisiert werden kann, z. B. das Online-Abrufen einer Kreditkartenabrechnung.

Ein Service hat vier Eigenschaften nach einer von vielen Definitionen von SOA:

1. Es stellt logisch eine Geschäftstätigkeit mit einem bestimmten Ergebnis dar.
2. Es ist in sich geschlossen.
3. Es ist eine Blackbox für seine Verbraucher.
4. Es kann aus anderen zugrunde liegenden Diensten bestehen.

Verschiedene Dienste können in Verbindung verwendet werden, um die Funktionalität einer großen Softwareanwendung bereitzustellen, ein Prinzip, das SOA mit modularer Programmierung teilt. Die serviceorientierte Architektur integriert verteilte, separat gewartete und bereitgestellte Softwarekomponenten. Es wird durch Technologien und Standards ermöglicht, die die Kommunikation und Zusammenarbeit von Komponenten über ein Netzwerk, insbesondere über ein IP-Netzwerk, erleichtern.

Dies liefert eine prägnante Antwort auf die Bedeutung von SOA, beschreibt jedoch nicht die Gründe, warum eine Organisation zu einer serviceorientierten Architektur übergehen möchte, oder die Vorteile von SOA.

Auch aus Wikipedia, wofür SOA steht:

Einige Unternehmensarchitekten glauben, dass SOA Unternehmen dabei helfen kann, schneller und kostengünstiger auf sich ändernde Marktbedingungen zu reagieren.Dieser Architekturstil fördert die Wiederverwendung auf Makroebene (Serviceebene) und nicht auf Mikroebene (Klassenebene). Es kann auch die Verbindung zu bestehenden IT—Assets (Legacy—Assets) und deren Nutzung vereinfachen.

In mancher Hinsicht könnte SOA eher als architektonische Evolution als als Revolution angesehen werden. Es erfasst viele der Best Practices früherer Softwarearchitekturen. In Kommunikationssystemen zum Beispiel hat wenig Entwicklung von Lösungen stattgefunden, die wirklich statische Bindungen verwenden, um mit anderen Geräten im Netzwerk zu sprechen. Durch den Einsatz eines SOA-Ansatzes können sich solche Systeme so positionieren, dass sie die Bedeutung klar definierter, hochgradig interoperabler Schnittstellen betonen.

Wenn wir uns mit diesen Konzepten befassen, können wir sehen, dass es eine Reihe grundlegender Funktionen gibt, die erforderlich sind, um die potenziellen Vorteile von SOA zu nutzen. Wikipedia diskutiert eine Reihe dieser Leitprinzipien, darunter:

• Wiederverwendung – die Fähigkeit, grobkörnige Geschäftsfunktionen als Dienste zu kapseln und verfügbar zu machen
• Lose Kopplung – Sicherstellen, dass die Servicekonsumenten ausreichend von der physischen Implementierung eines Dienstes abstrahiert sind
• Identifizierung und Kategorisierung (Auffindbarkeit) – Sicherstellen, dass potenzielle Verbraucher die benötigten Dienste finden können

Unabhängig davon, welche SOA–Definition Sie verwenden, führen diese grundlegenden Prinzipien einer natürlichen Reihenfolge von Aktivitäten, die eine Organisation abschließen muss, um die Vorteile der serviceorientierten Architektur.

Erfahren Sie, warum Akana im Bericht Forrester Wave™: API Management Solutions, Q3 2020, eine starke Leistung erbringt.

Bericht herunterladen

Was sind die sieben SOA-Schritte?

Es gibt sieben SOA-Schritte:

1. Dienste erstellen/verfügbar machen
2. Dienste registrieren
3. Dienste sichern
4. Dienste verwalten (überwachen)
5. Dienste vermitteln und virtualisieren
6. SOA steuern
7. SOA-Integration mit ESB

SOA Die Schritte 2 bis 6 beschreiben unternehmensübergreifende Bedenken, die mit einer zentralisierten SOA-Infrastrukturplattform angegangen werden sollten. Die Schritte 1 und 7 adressieren spezifische Anforderungen und werden häufig als Teil eines vorhandenen Unternehmensanwendungsstacks bereitgestellt. Das Befolgen dieser Schritte führt eine Organisation auf den richtigen Weg, um die Vorteile von SOA zu realisieren. Lesen Sie weiter, um tiefer in jeden SOA-Schritt einzusteigen.

Dienste erstellen /verfügbar machen

Der erste Schritt beim Übergang einer Organisation in Richtung SOA liegt auf der Hand. Es kann keine SOA-Anwendung ohne Dienste geben, daher muss der erste Schritt darin bestehen, Dienste verfügbar zu machen oder zu erstellen, die von webdienstfähigen Anwendungen problemlos genutzt werden können.

Zu Beginn dieses Prozesses stehen Unternehmen vor einer Reihe interessanter Entscheidungen, nicht zuletzt vor der Entscheidung, ob bestehende Anwendungen mithilfe eines serviceorientierten Paradigmas neu erstellt oder vorhandene Anwendungslogik als eine Reihe von Diensten verfügbar gemacht werden sollen. Dies ist natürlich keine binäre Entscheidung, und die meisten Unternehmen werden neue Dienste von Grund auf neu erstellen, häufig mit J2EE und / oder .NET, und auch Dienste aus vorhandenen Mainframe- und anderen Geschäftsanwendungen verfügbar machen.

Es gibt eine breite Palette verschiedener Lösungen für Unternehmen, die bestehende Anwendungen als Dienste bereitstellen möchten, einschließlich Akanas marktführender SOLA, mit der Mainframe-CICS-Anwendungen zuverlässige, sichere und leistungsstarke Dienste bereitstellen und nutzen können.

Jedes Unternehmen mit einer signifikanten Investition in Mainframe (laut Gartner mehr als 1000 MIPS) sollte nach Möglichkeiten suchen, die Vorteile dieser Plattform besser zu nutzen, und Webdienste verwenden, um seine Mainframe-Anwendungen einfach in moderne Systeme zu integrieren. Akanas SOLA hat sich bei Kunden wie Merrill Lynch bewährt, wo es mehr als 2 Millionen Transaktionen pro Tag von mehr als 600 Webdiensten verarbeitet. SOLA ist das einzige Produkt, das Mainframe-Programmierern eine einfach zu bedienende, webbasierte Schnittstelle für die Bereitstellung und Nutzung von Diensten aus CICS-Anwendungen bietet. Es enthält integrierte Unterstützung für erweiterte Web-Services-Funktionen wie WS-Security, XML-Verschlüsselung und XML-Signatur.

Die meisten traditionellen EAI-Unternehmen (Enterprise Application Integration) liefern auch Versionen ihrer Adapter aus, die Webdienste anstelle ihrer traditionellen proprietären Protokolle verfügbar machen. Tatsächlich tauchen viele dieser EAI-Plattformen als Enterprise Service Bus-Produkte wieder auf. Der ESB befasst sich mit mehreren verschiedenen Problemen, Eines davon ist die Funktionalität des Commodity Data Services-Typs, mit der Webdienstschnittstellen von herkömmlichen Adaptern verfügbar gemacht werden.

Was ist ein Webservice?

Aus Wikipedia:

In Bezug auf W3C-Webdienste definierte das W3C einen Webdienst als: „Ein Webdienst ist ein Softwaresystem, das interoperable Maschine-zu-Maschine-Interaktion über ein Netzwerk unterstützt. Es verfügt über eine Schnittstelle, die in einem maschinenverarbeitbaren Format (insbesondere WSDL) beschrieben ist. Andere Systeme interagieren mit dem Webdienst in einer durch seine Beschreibung vorgeschriebenen Weise unter Verwendung von SOAP-Nachrichten, die typischerweise unter Verwendung von HTTP mit einer XML-Serialisierung in Verbindung mit anderen webbezogenen Standards übermittelt werden.“

Diese Definition ist aus technischer Sicht interessant, aber sie bringt den Wert, der aus SOA und Webdiensten abgeleitet werden kann, nicht wirklich auf den Punkt. Ein grundlegender Aspekt von Webdiensten ist, dass sie Geschäftslogik über eine standardbasierte Schnittstelle verfügbar machen sollten. Ein wichtiger Aspekt beim Bereitstellen oder Erstellen eines Dienstes ist seine Granularität. Es gibt viele verschiedene Denkschulen darüber, was einen Service ausmacht (siehe oben), aber die meisten Unternehmensarchitekten würden zustimmen, dass ein Service, um in einer SOA nützlich zu sein, ausreichend grobkörnig sein muss, um für mehrere verschiedene Anwendungen nützlich zu sein.

Dies entspricht natürlich einem der Grundprinzipien von Diensten in SOA – damit ein Dienst wiederverwendet werden kann; es muss allgemein nützlich und nutzbar sein. Ein Beispiel für einen allgemein nützlichen Dienst kann ein „getCustomerInfo“ -Dienst sein, der Details zu einem Kunden von einer Kundenkennung zurückgibt. Ein feinkörnigerer Dienst, der möglicherweise nicht allgemein nützlich ist, kann etwas Spezifisches für eine bestimmte Anwendung sein, z. B. „setApplicationState“.

Es ist wichtig, die Granularität von Diensten sowohl beim Erstellen neuer Dienste als auch beim Bereitstellen vorhandener Geschäftslogik als Dienst zu berücksichtigen. Zum Beispiel wäre es einfach, eine CICS-Transaktion zu nehmen und mehrere verschiedene Dienste verfügbar zu machen, um verschiedene Parameter festzulegen und abzurufen, während die Realität ist, dass ein grobkörnigerer Dienst, der die gesamte Transaktion als einen einzigen Dienst verfügbar macht, viel allgemeiner sein könnte nützlich und daher wertvoll.

Lesen Sie weiter: Erfahren Sie, wie die SOLA Mainframe API von Akana Kunden einen schnellen und einfachen Prozess bietet, um Mainframe-Anwendungen als sichere Webdienste verfügbar zu machen und Mainframe-Anwendungen die Nutzung von Webdiensten zu ermöglichen.

Registrieren

Ok, Sie haben also einen oder mehrere Dienste in Ihrem Unternehmen verfügbar. Was nun?

Damit ein Dienst verwendet, geschweige denn wiederverwendet werden kann, müssen Anwendungsarchitekten und Entwickler, die von diesem Dienst profitieren könnten, wissen, dass er existiert. Hier kommt eine Registrierung ins Spiel. Auf seiner einfachsten Ebene ist eine Registrierung nichts anderes als ein Bibliotheksindex, der potenziellen Benutzern von Diensten hilft, Dienste zu finden, an denen sie interessiert sein könnten. Die Registrierung sollte sowohl Such- als auch Browse-Schnittstellen bieten und logisch organisiert sein, um eine schnelle und genaue Erkennung von Diensten zu ermöglichen.

In der heutigen SOA ist UDDI (Universal Discover, Description, and Integration) der akzeptierte Standard für grundlegende Registrierungsdienste. Die UDDI-Spezifikation stellt ein Datenmodell und eine Reihe von Schnittstellen (alle Webdienste selbst) zum Veröffentlichen und Ermitteln von Diensten sowie eine weitere Reihe von Schnittstellen zum Verwalten des Registrierungsservers selbst bereit.

Viele Registry-Anbieter haben das ursprüngliche Konzept der Registry ein Stück weiter entwickelt und verwenden Registry-Technologien als Basis für ein vollständigeres Repository. Registry-Anbieter fügen ihren Publishing-Tools auch „Richtlinien“ -basierte Filter hinzu und bieten „Design-Time-Governance-Lösungen“ an.

Akana betrachtet die Registrierung als einen grundlegenden Baustein von SOA. Alle unsere Produkte nutzen UDDI als zentralen Speicher für maßgebliche Informationen zu den Services in einer SOA. Die Produkte können mit jeder UDDI-kompatiblen Registrierung arbeiten, und Akana enthält einen eigenen UDDIv3-Registrierungsserver mit seinem Service Manager-Produkt für Unternehmen, die noch keine Registrierung haben. In dieser Hinsicht erfüllt Registry die Rolle für SOA, die LDAP für Identity- und Access-Management-Lösungen ausfüllt.

Die Produkte von Akana konzentrieren sich auf die Laufzeitverwaltung und nutzen die Registrierung als zentralen Ort, um Laufzeitrichtlinien zu finden, die implementiert und erzwungen werden können. Natürlich ist die eingebettete Registry voll funktionsfähig UDDIv3 Server und so macht auch eine ideale Design-Time-Service-Repository.

Beyond Registry ist das gesamte Konzept von Richtlinien- und Metadatendiensten, die umfassende Repositorys für alle Entwurfszeit- und Laufzeitartefakte für die Dienste in SOA bereitstellen. Dieses Konzept wird im Whitepaper The SOA Infrastructure Reference Model von Akana ausführlicher behandelt.

Sicher

Die Welt von SOA und Web Services ist nicht nur Wein und Rosen. Angenommen, Sie haben die Schritte eins und Zwei abgeschlossen, treten Sie einen Schritt zurück und überlegen Sie, was Sie getan haben. Angenommen, Sie streben einen maximalen Geschäftswert an, haben Sie wahrscheinlich geschäftskritische Anwendungen in grobkörnige Funktionalitäten zerlegt, diese Funktionen als Dienste verfügbar gemacht und diese Dienste dann in einer allgemein zugänglichen Registrierung veröffentlicht.

Dies mag alles wie eine gute Sache erscheinen, und in den meisten Fällen ist es eine großartige Sache, aber Sie haben möglicherweise versehentlich einige klaffende Sicherheitslücken in Ihrer Organisation geschaffen und vertrauliche Informationen oder hochwertige Transaktionen für jeden mit rudimentären Webdiensten offengelegt. Die Gewährleistung der Sicherheit von Diensten bedeutet den Aufbau einer Sicherheitsdurchsetzungsschicht bei den Diensteanbietern und einer Sicherheitsimplementierungsschicht bei den Dienstkonsumenten.

Eine gute Möglichkeit, die Sicherheitsrisiken von Webdiensten zu verstehen, besteht darin, an traditionelle Greenscreen-Mainframe-Anwendungen zu denken. Die einzige Sicherheit, die von diesen Anwendungen erforderlich war Login-Sicherheit, wenn Sie die Anwendung zugreifen können, waren Sie in. Diese Anwendungen enthielten die gleichen Grundelemente wie eine moderne Anwendung (Schnittstelle, Geschäftslogik, Datendienste), aber nur die Schnittstelle war außerhalb der Anwendung zugänglich. In der Welt der Webdienste ist es wahrscheinlich, dass einige der Kerndatendienste als Dienste verfügbar gemacht werden, einige der Geschäftslogik sollten sicherlich verfügbar gemacht werden, und die Anwendung wurde nicht für einen dieser Zugriffspunkte geschrieben. Sie können sich nicht auf die Interna der Anwendung verlassen, um ihre eigene Sicherheit zu gewährleisten.

Was bedeutet es also, einen Webdienst zu sichern? Die gleichen 5 Sicherheitsprinzipien, die für andere Anwendungen gelten, gelten auch für Webdienste:

• Authentifizierung – Stellen Sie sicher, dass Sie die Identität des Dienstanforderers kennen (und stellen Sie außerdem sicher, dass der Anforderer die Identität des Dienstes kennt, mit dem er Kontakt aufnimmt). Es gibt mehrere verschiedene Webdienststandards für die Authentifizierung von Anforderungen, die von einfachen Ansätzen wie der HTTP-Basisauthentifizierung bis hin zu komplexeren Mechanismen wie SAML oder X.509-Signatur reichen. Ein gutes Webservices-Sicherheitstool sollte all diese verschiedenen Optionen unterstützen.
• Autorisierung – Stellen Sie sicher, dass der Anforderer berechtigt ist, auf den angeforderten Dienst oder Vorgang zuzugreifen. Die Autorisierung ist ein komplexes Thema, und es gibt eine Reihe verschiedener politischer Entscheidungsprodukte. Die meisten großen Unternehmen verfügen über eine vorhandene Autorisierungslösung (CA SiteMinder, IBM TAM usw.), und eine gute Sicherheitslösung für Webdienste sollte in der Lage sein, diese zu integrieren und eigene Autorisierungsfunktionen bereitzustellen.
• Datenschutz – Stellen Sie sicher, dass Anforderungs- und Antwortnachrichten nicht von unbefugten 3rd-Parteien gelesen werden können. Dies ist, wo Standards wie XML-Verschlüsselung kommen in ihre eigenen, aber um erfolgreich XML-Verschlüsselung zu verwenden, muss die Web-Services-Sicherheitslösung bieten effektive Schlüssel-und Zertifikatsverwaltung und Verteilung Fähigkeiten, und im Idealfall einige Client-seitige Werkzeuge, um Consumer-Entwickler zu unterstützen.
• Nichtverweigerung – Stellen Sie sicher, dass der Anforderer das Senden einer Anforderung nicht verweigern kann, und stellen Sie sicher, dass der Dienst das Senden seiner Antwort nicht verweigern kann. Dies ist die Rolle der XML-Signatur mit der gleichen Schlüsselverwaltung und -verteilung wie für den Datenschutz.
• Auditing – Stellen Sie sicher, dass das System bei Bedarf eine genaue und zeitnahe Aufzeichnung von Anforderungen und Antworten führen kann.

Eine interessante Frage und ein Diskussionspunkt, der sich im Zusammenhang mit der Sicherheit von Webdiensten stellt, ist, wo diese Sicherheit angewendet werden sollte. Einige Anbieter argumentieren, dass Sicherheit eine zentrale Funktion sein sollte, die durch einen Cluster zentral bereitgestellter Proxys erzwungen wird, während andere argumentieren, dass es sich ausschließlich um die Domäne des Dienstanbieters oder Containers handeln sollte. Die Realität liegt natürlich irgendwo zwischen diesen beiden Positionen. Ein Proxy (oder ein Cluster von Proxys) spielt sicherlich eine wichtige Rolle bei der Bereitstellung von Authentifizierungs- und Bedrohungserkennungsdiensten am Rand des Netzwerks, um sich vor externen Bedrohungen zu schützen. Eine ebenso wichtige Rolle spielt die provider- oder containerbasierte Sicherheit, um die Sicherheit des Dienstes bis zur letzten Meile zu gewährleisten.

Viele Unternehmen neigen dazu, die Forschung zu übersehen, die zeigt, dass die Mehrheit der Sicherheitsbedrohungen unternehmensintern und nicht extern besteht, und delegieren daher die Sicherheit an eine Firewall-Lösung. Akana bietet einen leistungsstarken Proxy, der zentralisierte oder Netzwerk-Edge-Sicherheitsfunktionen ausführt, und eine breite Palette von In-Container-Agenten, um die Sicherheit der bereitgestellten Dienste auf der letzten Meile zu gewährleisten.

Das Sichern von Webdiensten erfordert:

• Bereitstellung voll funktionsfähiger In-Container-Agenten, um die Sicherheit auf der letzten Meile zu gewährleisten und die Last kryptografischer Vorgänge zu verteilen
• Bereitstellung leistungsstarker Netzwerkintermediäre für Routing und Netzwerk-Edge-Sicherheitsdurchsetzung
• Bereitstellung umfassender Schlüssel- und Zertifikatsverwaltung und -verteilung, um sicherzustellen, dass Dienstanbieter und Consumer-Entwickler die erforderlichen Sicherheitsrichtlinien erfolgreich implementieren können
• Bereitstellung von Toolkits für Consumer-Entwickler, um Consumer-Entwickler von der Komplexität der Erkennung und Implementierung richtlinien

Lesen Sie weiter: Erfahren Sie mehr über Best Practices für die API-Sicherheit.

Verwalten

Drei Schritte in den 7-Stufen-Ansatz für SOA und wir beginnen, Fortschritte bei der Erzielung eines echten Werts aus Enterprise SOA zu erzielen. Wir haben einige Dienste, sie werden in einer Registrierung veröffentlicht und können von potenziellen Benutzern entdeckt werden, und wir haben sichergestellt, dass sie sicher sind. Was könnten wir sonst noch brauchen?

Um diese Frage zu beantworten, sollten wir uns zunächst ein mögliches Katastrophenszenario ansehen. Was passiert, wenn meine Dienste Opfer ihres eigenen Erfolgs werden? I.e. ein Dienst ist so populär geworden, dass es mehrere (Dutzende oder Hunderte oder Tausende) verschiedene Anwendungen gibt, die ihn verbrauchen, und er beginnt sich unter der Last zu wölben. Wir haben plötzlich Dutzende oder Hunderte oder Tausende von Anwendungen, die versagen oder schlecht funktionieren, und wir wissen nicht warum oder wie wir sie stoppen können.

Wir müssen unsere Dienste überwachen, damit wir wissen, ob sie innerhalb der normalen Betriebsparameter funktionieren, und damit wir potenzielle Probleme erkennen, bevor sie auftreten, indem wir Kapazitätsplanungsmodelle implementieren.

Die von uns bereitgestellte Überwachungslösung sollte in der Lage sein, Dienste auf grundlegende Verfügbarkeit, Leistung (Reaktionszeit) und Durchsatz zu überwachen und sogar auf inhalts- und benutzerbasierte Überwachung auszudehnen. Es sollte in der Lage sein, bestimmte SLA-Schwellenwerte zu überwachen und darauf aufmerksam zu machen, und sollte in der Lage sein, unterschiedliche SLAs auf verschiedene Benutzer desselben Dienstes oder Vorgangs anzuwenden.

Viele Anbieter definieren diese Produktkategorie als Webservices-Managementlösung, obwohl viele Analysten der Meinung sind, dass das Management viel umfassender ist als eine einfache Überwachungslösung und einen Großteil der im nächsten Schritt beschriebenen Funktionen enthalten sollte.

Idealerweise sollten wir natürlich keine separaten Lösungen für Sicherheit und Überwachung bereitstellen müssen, da wir jedes Mal, wenn wir Nachrichten über einen Agenten oder Vermittler abfangen, einen weiteren Leistungsengpass hinzufügen. Aus diesem Grund wird der Service Manager von Akana mit Network Director kombiniert, um eine umfassende SOA-Sicherheits-, Überwachungs- und Managementplattform in einer einzigen, leistungsstarken und einfach zu implementierenden Lösung bereitzustellen.

Einige Anbieter von Web Services Management (Monitoring) positionieren ihre Lösungen als Business Activity Monitoring (BAM) -Plattformen, obwohl BAM eine komplexe Lösung ist, die die Integration mit vielen Back- und Front-Office-Systemen und Datenbanken erfordert. Die Überwachung von Webservices-Interaktionen auf Inhalte sollte nicht als Alternative zu einer Unternehmens-BAM-Lösung betrachtet werden.

Verwandte Lektüre: Erfahren Sie mehr über die End-to-End API Management Lösung von Akana.

5. Vermitteln und virtualisieren

An dieser Stelle scheint unsere SOA für die Primetime bereit zu sein. Und so ist es zumindest für eine Weile…

Die nächsten Herausforderungen treten auf, wenn Ihre SOA reift. Sie müssen neue Versionen von Diensten einführen oder die Kapazität eines Dienstes erhöhen, indem Sie mehrere Instanzen davon ausführen, Sie müssen Anwendungen bereitstellen, um bestimmte Instanzen von Diensten zu verwenden, und Sie müssen Dienste anbieten, die eine breitere Palette verschiedener Schnittstellentypen verfügbar machen.

Hier kommt die Service-Virtualisierung ins Spiel. Virtualisierung scheint komplex, aber die Realität ist ganz einfach. Ein virtueller Dienst ist ein völlig neuer Dienst, der durch eine eigene WSDL mit eigener Netzwerkadresse und eigenen Transportparametern definiert wird. Es implementiert keine Geschäftslogik; Es fungiert einfach als Proxy für einen oder mehrere physische Dienste, Routing, Lastausgleich, Transformation und Vermittlung zwischen verschiedenen Anforderungsnachrichtentypen und -standards.

Das Konzept der Virtualisierung ist zwar oberflächlich einfach, aber äußerst leistungsfähig. Es bietet die Möglichkeit, Servicekonsumenten vollständig von jedem direkten Wissen über den physischen Service zu abstrahieren. Beispielsweise kann ein .NET-Client, der eine Microsoft-Implementierung eines zuverlässigen Nachrichtenprotokolls mit SOAP über http verwendet, über einen virtuellen Dienst einen einfachen alten XML-Dienst verwenden, der über IBM WebSphere MQ Series von einer Mainframe-Anwendung bereitgestellt wird. Der .NET-Client würde glauben, dass es sich um eine Kommunikation mit einem http-Dienst handelt, der sein zuverlässiges Messaging-Protokoll unterstützt, während die Mainframe-Anwendung glauben würde, dass sie von einer anderen nativen Anwendung der MQ-Serie abgefragt wird.

Virtuelle Dienste bieten ein breites Spektrum an Funktionen:

• Sie können XML-Transformationstechnologien verwenden, um es Verbrauchern zu ermöglichen, eine alte Version eines Dienstes, der nicht mehr vorhanden ist, weiterhin zu verwenden, indem sie Anforderungs- und Antwortnachrichten zwischen der alten Version und der neuen Version, die bereitgestellt wurde, transformieren.
• Sie können bestimmte Vorgänge aus mehreren verschiedenen Diensten auswählen und in einer einzigen funktionalen WSDL für eine bestimmte Klasse verbrauchender Anwendungen kombinieren.
• Sie können unterschiedliche Richtlinienanforderungen für verschiedene Benutzerklassen bereitstellen (z. b. interne Benutzer mit einem Richtliniensatz und eine andere Implementierung des Dienstes, die einen anderen Richtliniensatz für externe Verbraucher erzwingt).
• Sie können Transportbrücken für Dienste und Verbraucher auf inkompatiblen Transporten (z. B. http und JMS) bereitstellen. * Sie können zwischen verschiedenen Normenimplementierungen oder sogar Versionen von Normen vermitteln.
• Sie können zwischen verschiedenen Nachrichtenstilen vermitteln – RSS, SOAP, REST, POX (Plain Old XML).
• Sie können leistungsstarkes inhalts- oder kontextbasiertes Routing bereitstellen, um erweiterte Lastausgleichs- und Hochverfügbarkeitsfunktionen bereitzustellen.

Die Quintessenz virtueller Dienste ist, dass sie für jedes Routing oder andere erweiterte Webdienste erforderlich sind und schnell zu einem wesentlichen Bestandteil jeder Unternehmens-SOA werden.

Mit 5 von 7 abgeschlossenen Schritten ist die Enterprise SOA so gut wie einsatzbereit. Sie verfügen jetzt über sichere, verwaltete Dienste, die einem breiten Publikum auf zuverlässige, lastausgeglichene Weise zur Verfügung stehen und leicht auffindbar sind.

Der nächste Schritt besteht darin, alle Funktionen, die in den ersten 5 Schritten bereitgestellt wurden, mit einem Governance-Framework zu verknüpfen. Governance ist eine überstrapazierte und viel missbrauchte Arbeit, also schauen wir uns kurz eine Definition von Governance an. Wieder aus Wikipedia:

Der Begriff Governance befasst sich mit den Prozessen und Systemen, mit denen eine Organisation oder Gesellschaft operiert. Häufig wird eine Regierung gegründet, um diese Prozesse und Systeme zu verwalten.

Der entscheidende Punkt aus dieser Definition ist, dass es bei Governance um Prozesse und Systeme geht. Im Falle der SOA-Governance diskutieren wir organisatorische Prozesse wie ein Architecture Review Board und Systeme wie die in diesem Blog diskutierten Registrierungs-, Sicherheits- und Managementtechnologien.

Governance für SOA wird häufig in zwei separate Teile unterteilt: Design-Time-Governance und Run-Time-Governance. Zur Entwurfszeit möchten Organisationen steuern (regeln), welche Arten von Diensten veröffentlicht werden können, wer sie veröffentlichen kann, welche Arten von Schemas und Nachrichten diese Dienste akzeptieren können und eine Vielzahl anderer Regeln für Dienste. Zur Laufzeit müssen Unternehmen die Sicherheit, Zuverlässigkeit und Leistung ihrer Dienste sicherstellen und sicherstellen, dass die Dienste den definierten Unternehmensrichtlinien entsprechen. Design-Time Governance ist interessant und trägt dazu bei, eine organisierte, gut gestaltete SOA zu gewährleisten, verblasst jedoch im Vergleich zur aktiven Steuerung der SOA zur Laufzeit.

Der Service Manager von Akana ist die branchenführende Runtime-Governance-Plattform und bietet eine umfassende Lösung für Sicherheit, Überwachung, Management, Vermittlung und Registrierung. Runtime Governance bietet im Wesentlichen einen einzigen Rahmen für die Steuerung und Überwachung der Anwendung der verschiedenen in diesem Dokument beschriebenen Schritte auf SOA. Es bietet eine einzige übergreifende Lösung, die die Überwachung der Serviceregistrierung, Sicherheit, Verwaltung und Vermittlung ermöglicht. Eine gute Runtime-Governance-Lösung wird sich als eine Art Workbench manifestieren, die Tools für alle aktiven Teilnehmer einer SOA bereitstellt.

• Service Entwickler: tools zum Veröffentlichen, Kategorisieren, Definieren von Metadaten, Herunterladen von „Agent“, Virtualisieren, Version, Richtlinie auswählen, Sichtbarkeit / Zugriffsrechte auswählen, an Kapazitätsplanung und Zugriffsworkflow teilnehmen
• Service Consumer: Tools zur Erleichterung der Erkennung, Auswahl und des Zugriffsworkflows von Diensten
• Operations Staff: Tools zur Überwachung der Serviceleistung, Fehlerbehebung, Überwachung von Abhängigkeiten, Versionsdienste, Virtualisierung, Proxy-Management
• Sicherheitspersonal: Tools für Richtlinienverwaltung, Richtlinienberichterstattung, Konformitätsprüfung, Sicherheitsüberwachung
• Unternehmensarchitekt: Tools für Application Monitoring, Relationship Management, Design Policy validation and definition, Service Version Management, service to proxy assignment, Service virtualization
• Enterprise IT Management: Reuse metric Management, service reuse metrics, SOA statistics

SOA Integration Mit ESB

Wenn wir auf die Ergebnisse der letzten 6 Schritte in Richtung einer SOA zurückblicken, fragen wir uns, was es sonst noch geben kann. Inzwischen verfügen wir über eine Reihe von Diensten, die in einer sicheren, verwalteten, zuverlässigen und lose gekoppelten Registrierung veröffentlicht werden, die alle in einer soliden Design- und Laufzeit-Governance-Lösung enthalten sind.

Der letzte Schritt für einige Unternehmen besteht darin, eine oder mehrere ESB-Implementierungen (Enterprise Services Bus) bereitzustellen, um Dienste in übergeordnete zusammengesetzte oder orchestrierte Dienste zu integrieren. Diese ESBs werden häufig als Teil einer umfassenderen Anwendungssuite bereitgestellt, z. B. Oracle eBusiness-Anwendungen oder SAP. Einige spezialisierte ESBs können verwendet werden, um komplexe zusammengesetzte Dienste zu erstellen, und werden in den Bereich des Business Process Management (BPM) reichen.

Weiterführende Literatur:Erfahren Sie mehr über die Integrationslösungen von Akana.

Enterprise Service Bus (ESB) ist ein immer beliebteres Konzept. Ursprünglich als Weiterentwicklung von nachrichtenorientierter Middleware und EAI-Lösungen (Enterprise Application Integration) konzipiert, bedeutet der ESB für verschiedene Organisationen sehr unterschiedliche Dinge. Da sich Analysten, Anbieter und Kunden mit der Idee eines ESB abfinden, scheint es, dass ein ESB 3 funktionale Konzepte kapselt: Adapter aus einem EAI-Tool, um die Konnektivität mit Legacy-Anwendungen sicherzustellen, Messaging-Dienste aus einer nachrichtenorientierten Middleware-Plattform, um eine zuverlässige Bereitstellung zu gewährleisten, und Prozessorchestrierung, um agile Anwendungen zu erstellen.

Die Analysten sind sich einig, dass die meisten Unternehmen am Ende mehrere ESB-Plattformen von mehreren Anbietern haben werden, die Dienste in ihrem eigenen Kontext bereitstellen. In dieser Umgebung ist es wichtig, dass die ESBs eine zentrale SOA-Infrastruktur verwenden, um die konsistente Einhaltung der Sicherheits- und Messaging-Richtlinien für die von ihnen bereitgestellten und genutzten Dienste sicherzustellen.

Die Service Manager- und Network Director-Produkte von Akana bieten zusammen eine Komplettlösung für die Verwaltung und Vermittlung zwischen mehreren ESB-Instanzen in einem Unternehmen.

Nun, da Sie mehr darüber wissen, wofür SOA steht und die wichtigsten SOA-Schritte, schauen Sie sich Akana in Aktion an!

Testversion starten