Überblick über die SOA-Terminologie

Teil 1. Service-, Architektur-, Management- und Geschäftsbedingungen

Bertrand Portier
Veröffentlicht am 25.06.2008

Inhaltsreihe:

Semantik ist in jedem Bereich wichtig, insbesondere in der serviceorientierten Architektur (SOA). Da SOA Teams und Organisationen verbindet, ist eine einheitliche Terminologie äußerst wichtig. In dieser Artikelserie machen wir einen Rundgang durch SOA und definieren die Begriffe und die Ideen dahinter. Hier lernen Sie genügend Terminologie, um im SOA-Bereich zu kommunizieren. Sie werden verstehen, warum jeder Begriff für SOA wichtig ist, was er in diesem Kontext bedeutet, mit welchen Standards er verbunden ist und wie er sich von anderen Begriffen unterscheidet.

Organisatorischer Hinweis

Die unten aufgeführten Begriffe sind weder alphabetisch noch nach Wichtigkeit geordnet. Sie sind eher blockartig organisiert. Wir beginnen mit „Service“, weil es ein grundlegendes Konzept innerhalb von SOA ist. Auf diesem Konzept bauen wir Definitionen von Begriffen wie „Architektur“, „Management“ und „Geschäft“ auf. In vielen Fällen zerlegen wir langfristige Begriffe in ihre Bestandteile.

Service

Dienste sind zweifellos das Herzstück der serviceorientierten Architektur: der Begriff selbst Service weit verbreitet. Allerdings verstehen es verschiedene Menschen unterschiedlich und daher stellt sich die Frage „Was ist eine Dienstleistung?“ führt oft zu langen Streitigkeiten. Ich habe Leute über Geschäftsprobleme, Geschäftsdienste, Anwendungsfunktionen, technische Dienste und Infrastrukturdienste sprechen hören. Lassen Sie mich Ihnen eine Definition geben, die auf dem IBM Rational® Method Composer Plug-in für SOA Governance und dem IBM Rational® Unified Process for Service-Oriented Architecture basiert. Weitere Informationen finden Sie unter.

„Ein Dienst ist eine sichtbare Ressource, die eine wiederholbare Aufgabe ausführt und durch eine externe Anweisung beschrieben wird.“

Die Definition des Dienstleistungsbegriffs am Anfang des Artikels ist nicht einfach, da er viele andere Definitionen mit sich bringt. Beispielsweise denken Sie möglicherweise, dass die obige Definition zu technisch ist. Bedenken Sie jedoch, dass es wichtig ist, sich nicht auf die formale Definition eines Dienstes einzulassen, sondern sich auf die Schlüsselideen zu konzentrieren, die dahinter stehen, wie zum Beispiel:

• Geschäftsorientierung: Dienstleistungen konzentrieren sich nicht auf IT-Fähigkeiten, sondern auf Geschäftsanforderungen. Die Geschäftsausrichtung von Dienstleistungen wird durch Serviceanalyse- und Designtechniken unterstützt.
• Anweisungen: Dienste sind in sich geschlossen und werden anhand von Schnittstellen, Vorgängen, Semantik, dynamischen Merkmalen, Richtlinien und Diensteigenschaften beschrieben.
• Wiederverwendung: Die Wiederverwendung von Diensten wird durch deren modulare Planung sichergestellt.
• Vereinbarungen: Servicevereinbarungen werden zwischen Unternehmen, die als Anbieter bezeichnet werden, und Benutzern geschlossen. Diese Vereinbarungen basieren auf Leistungsanweisungen und haben keinen Einfluss auf die Durchführung der Leistungen selbst.
• Platzierung und Sichtbarkeit: Während ihres Lebenszyklus werden Dienste gehostet und durch Dienstmetadaten, Registrierungen und Repositorys sichtbar gemacht.
• Anhäufung: Lose gekoppelte Dienste werden verwendet, um vereinheitlichende Geschäftsprozesse und komplexe Anwendungen für ein oder mehrere Unternehmen zu erstellen.

Diese Merkmale zusammengenommen zeigen, dass es bei SOA nicht nur um „Technologie“, sondern auch um die Bedürfnisse und Wünsche des Unternehmens geht.

Es ist auch wichtig zu bedenken, dass nicht alles eine Dienstleistung ist. Es gibt IT-Funktionen, bei denen es keinen Sinn macht, sie als Dienste zu hosten. Analysetechniken wie IBM Service-Oriented Modeling and Architecture (SOMA) helfen dabei, festzustellen, ob Services den oben aufgeführten Ideen entsprechen. Wir werden alle diese Punkte (einschließlich aller hervorgehobenen Begriffe aus diesem Abschnitt) in diesem Artikel ausführlich betrachten.

Die Architektur

Wie bei Dienstleistungen ist es auch für Architektur schwierig, eine Definition zu finden, die alle zufriedenstellt. Allerdings wird Architektur im Gegensatz zu Dienstleistungen oft vergessen, wenn über SOA gesprochen wird, und das aus gutem Grund! Im Wesentlichen ist es Unternehmensarchitektur gemeinsames Ziel– Unterstützung des Unternehmens mit einer integrierten IT-Strategie. Unternehmensarchitekten sind beispielsweise ein Schlüsselelement für den Erfolg von SOA, da sie die strategische Entwicklung von Unternehmens-IT-Systemen auf der Grundlage sich verändernder Geschäftsanforderungen und -anforderungen aufzeichnen.

Das Open Group Architecture Forum (TOGAF) hat je nach Kontext zwei Definitionen von Architektur:

1. „Formale Beschreibung bzw Detaillierter Plan System auf Komponentenebene, um dessen Erstellung zu steuern.
2. Die Struktur der Komponenten, ihre Beziehungen, Prinzipien und Entwicklungsrichtungen, die ihre Entwicklung und Entwicklung bestimmen.“

Diese beiden Definitionen sind entscheidend für das Verständnis des „A“ (Architektur) im SOA-Akronym. Wenn wir genauer hinschauen, sehen wir auch, dass Architektur für Folgendes notwendig ist:

• Entwicklung und Modellierung auf verschiedenen Abstraktionsebenen
• Trennung von Anleitung und Umsetzung
• Flexible Systeme aufbauen
• Prüfung anhand der Geschäftsanforderungen
• Analyse des Änderungsumfangs bei neuen Anforderungen
• Compliance-Prüfung

Unternehmensstruktur

Hier ist die Definition aus Wikipedia:

„Architektur“ lässt sich der Projektebene zuordnen, „Unternehmensarchitektur“ der Organisationsebene. Beachten Sie auch Verweise auf Prozesse, Informationssysteme, Personen, Ziele, Strategie und IT-Geschäftsausrichtung.

Das Hauptziel der Erstellung einer Unternehmensarchitektur besteht darin, Geschäftsstrategie und Investitionen im IT-Bereich aufeinander abzustimmen. Somit ermöglicht Ihnen die Unternehmensarchitektur, von der allgemeinen Geschäftsstrategie hin zur zugrunde liegenden Technologie überzugehen.“

Sie können „Architektur“ auf Projektebene und „Unternehmensarchitektur“ auf Organisationsebene klassifizieren. Beachten Sie auch Verweise auf Prozesse, Informationssysteme, Personen, Ziele, Strategie und IT-Geschäftsausrichtung.

Serviceorientierte Architektur

Serviceorientierung

Wie im technischen Überblick über die IBM SOA Foundation beschrieben, „... Serviceorientierung ist der Weg, ein Unternehmen als eine Reihe zusammenhängender Dienstleistungen zu integrieren.“ Weitere Informationen zur IBM SOA Foundation finden Sie unter.

Das Schlüsselwort hier ist „Geschäft“. Durch Serviceorientierung können Sie beispielsweise Geschäftsprozesse aus einem Geschäftsbereich (OB), verschiedenen OBs und auch mit Geschäftspartnern, die Services nutzen, flexibel umsetzen und verbinden.

SOA-Foundation-Referenzmodell

IBM SOA Foundation enthält Referenzmodell Die in Abbildung 1 dargestellte SOA zeigt die wichtigsten Merkmale, die zur Unterstützung einer serviceorientierten Architektur erforderlich sind.

Da das Modell selbst serviceorientiert ist, ermöglicht es die schrittweise Einführung von SOA bei neuen Geschäftsanforderungen, angefangen bei kleinen Projekten bis hin zur Integration im Laufe der Zeit im gesamten Unternehmen. Weitere Informationen zur SOA-Stiftung finden Sie unter.

Abbildung 1. SOA-Foundation-Referenzmodell

Serviceorientierte Architektur

In der IBM SOA-Grundlage ist SOA wie folgt definiert:

„Serviceorientierte Architektur (SOA) ist ein Architekturstil zum Erstellen einer Unternehmens-IT-Architektur, der serviceorientierte Prinzipien verwendet, um eine enge Verbindung zwischen dem Unternehmen und den es unterstützenden Informationssystemen herzustellen.“

SOA weist die folgenden Eigenschaften auf:

• Es verbessert die Beziehung zwischen Unternehmensarchitektur und Geschäft.
• Es ermöglicht Ihnen, komplexe Anwendungen aus einer Reihe integrierter Dienste zu erstellen.
• Es schafft flexible Geschäftsprozesse.

Die serviceorientierte Architektur führt auf evolutionäre (im Gegensatz zu „revolutionäre“) Weise neue Fähigkeiten, neue Wege der Zusammenarbeit, neue unterstützende Infrastrukturen und neue Arten von Softwareanwendungen in die Industrie ein.

Das in Abbildung 2 dargestellte SOA Solutions Framework ist ein SOA-Referenzmodell, das den konzeptionellen (High-Level-)Design von SOA-Lösungen widerspiegelt.

Dieses Modell, manchmal auch „geschichtete SOA-Architektur“ genannt, umfasst Schichten und Konzepte wie Geschäftsprozess, Service, Servicekomponente und die Beziehungen zwischen ihnen.

Es hängt nicht von den Technologien ab, auf denen es basiert. Wie Sie im Abschnitt „Modellgesteuerte Architektur“ (MDA) im zweiten Artikel dieser Reihe sehen werden, ist diese Unterscheidung wichtig.

Abbildung 2. SOA-Lösungsstruktur

Der Aufbau besteht aus 5 Funktionsschichten (von unten nach oben):

• Betriebssysteme: Präsentieren Sie bestehende IT-Lösungen, zeigen Sie den Wert und die Bedeutung von IT-Investitionen für SOA und die Möglichkeit ihrer Nutzung auf.
• Servicekomponenten: Implementieren von Diensten und können eine oder mehrere Anwendungen auf Betriebssystemebene nutzen. Wie Sie dem Modell entnehmen können, haben Benutzer und Geschäftsprozesse im Gegensatz zu Diensten keinen direkten Zugriff auf Komponenten. Vorhandene Komponenten können wiederverwendet oder bei Bedarf in die SOA implementiert werden.
• Dienstleistungen: Stellt die in der Umgebung gehosteten Dienste dar. Bei diesen Diensten handelt es sich um verwaltete sichtbare Einheiten.
• Geschäftsprozess: Stellt betriebliche Programme dar, die Geschäftsprozesse in Form von Service-Choreografien erstellen.
• Benutzer: Stellt die Kanäle dar, die für den Zugriff auf Geschäftsprozesse, Dienste und Anwendungen verwendet werden.

Kontrolle

Für eine erfolgreiche Adoption SOA-Management Dies ist teilweise aufgrund des organisationsübergreifenden Charakters von SOA erforderlich, bei dem Eigentümer, Entwickler, Programmierer, technisches Personal und Benutzer in verschiedenen Organisationen, Unternehmen, IT-Abteilungen, OBs, Abteilungen oder Abteilungen ansässig sein können.

Dieser Abschnitt enthält Definitionen aus dem IBM Rational Method Composer Plug-in für SOA Governance. Es definiert die Begriffe „Governance“, „IT-Governance“, „SOA-Governance“ und definiert den Unterschied zwischen Governance, Governance und Compliance. Außerdem werden die Probleme des SOA-Managements beschrieben. Weitere Informationen zu Rational Method Composer finden Sie unter .

Kontrolle

„Mit Management meinen wir:

• Aufbau von Verantwortungs-, Autoritäts- und Verbindungsketten zur Stärkung der Menschen (Entscheidungsrechte)
• Einrichtung von Mess-, Berechnungs- und Kontrollmechanismen, damit Menschen ihre Aufgaben im Rahmen ihrer Verantwortung erfüllen können

Das Management überwacht die Vergabe von Entscheidungsrechten und entscheidet, nach welchen Kriterien und Regeln diese Entscheidungen getroffen werden. Entscheidungsrechte liegen bei bestimmten Positionen, nicht bei Einzelpersonen. Im Gegensatz zum Management Management Dazu gehört die Zuordnung von Mitarbeitern zu Positionen und die Überwachung der Einhaltung von Regeln.

Bestandteil jeder Managemententscheidung ist die Einhaltung organisatorischer Compliance-Regeln. Korrespondenz ist ein dokumentierter Beweis dafür, dass Kontrolle vorhanden ist und umgesetzt wird: Entscheidungen werden dokumentiert und Entscheidungsregeln werden befolgt.“

IT-Management

„IT-Management betrifft diejenigen Aspekte des Managements, die sich auf Prozesse in diesem Bereich beziehen Informationstechnologien in der Organisation und wie diese Prozesse mit den Geschäftszielen übereinstimmen.“

Unter IT-Governance versteht man die Zuweisung von Entscheidungsrechten und Mitteln zur Bewertung von IT-Prozessen.

SOA-Management

„SOA-Governance ist eine Erweiterung der IT-Governance, die sich auf Dienste und andere Produkte des SOA-Lebenszyklus konzentriert.“

Insbesondere konzentriert sich die SOA-Governance auf Methoden und Prozesse im Zusammenhang mit der Identifizierung, Finanzierung, dem Besitz, der Entwicklung, der Programmierung, dem Hosting, der Wiederverwendung, der Entdeckung, dem Zugriff, der Überwachung, der Verwaltung und der Stilllegung von Diensten.

„SOA-Management soll die folgenden Probleme lösen:

• Welche neuen organisatorischen Positionen und Strukturen sind erforderlich, um Dienste zu identifizieren, zu entwickeln und zu teilen?
• Welche Kennzahlen unterstützen Investitionen, Wartung, Rentabilität und gemeinsame Nutzung von Diensten?
• Wie kann ein Unternehmen das Problem lösen, in die Erstellung und Aufrechterhaltung von Dienstleistungen zu investieren?
• Was ist Fertigungsreife im Bereich Serviceorientierung?
• Welche Ausbildung, Schulung oder Betreuung ist erforderlich?“

Lebenszyklus

Service-Lebenszyklus

IN Lebenszyklus Der Dienst umfasst die Zustände, in denen sich Dienste befinden können, sowie die Ereignisse, die zu einer Änderung dieser Zustände führen.

Im Laufe ihres „Lebens“ durchlaufen Dienste viele Stadien und Phasen (genau wie wir ;-)). Sie können sich den Service-Lebenszyklus als eine Geschäftsmaschine vorstellen, mit Zuständen (Positionen), in denen sich Services befinden können, und Übergängen, die Services von einem Status in einen anderen bringen.

Das SOA-Management befasst sich mit der Planung, Definition, Aktivierung und Messung während des gesamten Lebenszyklus von Diensten. Das SOA-Management bestimmt, welche Servicezustände vorliegen sollen, welche Aktionen durchgeführt werden sollen, um von Zustand zu Zustand zu gelangen (Übergänge), wie (Prozesse und Methoden) und von wem (Positionen, Controller).

Das SOA-Management kann beispielsweise die folgenden Servicestatus definieren: identifiziert, finanziert, spezifiziert, programmiert, genehmigt, betriebsbereit, veröffentlicht, zum Rückzug genehmigt, zurückgezogen.

Um Dienste während ihres gesamten Lebenszyklus zu unterstützen und die Korrektheit von Prozessen zu überwachen, ist außerdem eine zugrunde liegende SOA-Shell erforderlich. Beispielsweise sollten Dienstregister und Repositories die Durchführung von Maßnahmen ermöglichen, die zur Weiterentwicklung von Diensten während ihres gesamten Lebenszyklus führen. Damit Benutzer (und alle anderen Personen mit Berechtigungen) Entscheidungen über das Verschieben von Diensten von einem Status in einen anderen treffen und Benutzer benachrichtigen können, wenn sie Maßnahmen ergreifen müssen, sind Tools zum Verwalten von Berechtigungen und Listen erforderlich.

Bei der Definition des SOA-Lebenszyklus identifiziert die IBM SOA Foundation vier Phasen:

• Modell besteht aus Geschäftsanalyse und -entwicklung (Anforderungen, Prozesse, Ziele, Key Performance Indicators) und IT-Analyse und -Entwicklung (Servicedefinition und -spezifikation).
• Montage besteht aus Programmierdiensten und der Erstellung komplexer Anwendungen.
• Unterkunft besteht aus Anwendungshosting- und Laufzeiteinrichtungen wie Enterprise Service Buses (ESB).
• Management besteht aus der Aufrechterhaltung der Betriebsumgebung, der Überwachung der Serviceleistung und der Überwachung der Einhaltung von Servicerichtlinien.

Die oben definierte SOA-Governance und -Prozesse unterstützen diese vier Phasen. Dies ist in Abbildung 3 dargestellt.

Abbildung 3. SOA-Lebenszyklus

Geschäft

Heutzutage müssen Unternehmen in der Lage sein, Veränderungen schnell zu erkennen und darauf zu reagieren und gleichzeitig ihr Ökosystem aus Mitarbeitern, Partnern und Kunden aufrechtzuerhalten. IBM On Demand Business beschreibt, dass dafür die Technologie maximal genutzt werden muss. Informationen zu IBM On Demand Business finden Sie unter .

Unternehmen benötigen Flexibilität und Agilität, um Kunden- und Regulierungsanforderungen sowie die Veränderungen, die sich aus wettbewerbsintensiven Märkten ergeben, zu erfüllen. Eine serviceorientierte Architektur hilft Ihnen, diese Ziele zu erreichen und sich schnell an Veränderungen anzupassen.

Geschäftsorientierung

Der Schlüssel zum Erfolg von SOA liegt in der Wiederverwendung vorhandener IT-Ressourcen, beispielsweise Legacy-Anwendungen. Im Gegensatz zu Diensten, die auf isolierten Informationssystemen basieren, ermöglicht SOA Unternehmen jedoch, ihre Bemühungen auf Dienste zu konzentrieren, die ihre Bedürfnisse oder Prozesse unterstützen – beispielsweise können Serviceabläufe an Geschäftszielen ausgerichtet werden. Dieser Geschäftsfokus führt zu größerer Konvergenz und einfacherer Kommunikation zwischen Geschäft und IT. Um zu verstehen, wie Geschäftsmodelle in IT-Modelle umgewandelt und deren Funktionalität erhöht werden kann, schauen wir uns im nächsten Teil des Artikels an unterschiedliche Ansätze zur SOA-Analyse und zum Design: Top-Down, Bottom-Up und Konvergenz im Zentrum.

Geschäftsorientierung bedeutet jedoch nicht einen strikten Zusammenhang zwischen Produktionskapazitäten und deren Umsetzung im IT-Bereich. Eine der Schlüsselideen von SOA, die lose Kopplung, trennt die Spezifikationen (Geschäftsmodell, Schnittstelle) von der Implementierung (Technologie) und minimiert so die Auswirkungen von Änderungen, wie z. B. einem Wechsel des Dienstanbieters.

Komponentenansicht des Geschäfts

Site Component Business Model® ist eine strategische Methode, die es Unternehmen ermöglicht, sich auf ihre Kernkompetenzen zu konzentrieren – wie sich das Unternehmen von seinen Mitbewerbern unterscheidet, den Ressourcenverbrauch zu verfolgen und bessere Geschäfts-IT-Verbindungen aufzubauen. In finden Sie Weitere Informationenüber das Component-Geschäftsmodell. Durch und durch Serviceorientierung wird die Integration und Interaktion dieser Geschäftskomponenten sowie die Flexibilität erreicht, die die Auslagerung von Komponenten ermöglicht: Jede der Geschäftskomponenten hat ihren eigenen, einzigartigen Zweck und sie kommunizieren über das Ganze miteinander von Geschäftsdienstleistungen, die sie anderen Komponenten liefern oder von anderen Komponenten beziehen. Dies kann als Teil der „Business-Architektur“ betrachtet werden.

Geschäftsmodellierung

Die Geschäftsmodellierung wird durch den IBM Rational Unified Process® wie folgt definiert:

„Die Disziplin der Rational Unified Process Business Modeling bietet präzise Leitlinien für die Beschreibung des „aktuellen“ oder „gewünschten“ Geschäfts durch eine Reihe von Ansätzen und Techniken auf verschiedenen Formalisierungsebenen.“

Geschäftsmodellierung beschreibt Ideen, Komponenten und Rollen; Es beschreibt und organisiert Aufgaben im Zusammenhang mit Geschäftsstrategie, Geschäftsvision, Geschäftsobjekten, Geschäftszielen, Geschäftsvokabular, Geschäftsarchitektur, Geschäftsanalyse und -entwicklung, Geschäftsregeln, Geschäftswerten, Geschäftsbereichen, Geschäftseinheiten und Geschäftsprozessen. Im nächsten Abschnitt werden diese Probleme detaillierter untersucht.

SOA ist eine langfristige Strategie zur Neuorganisation von Geschäfts- und IT-Systemen, deren Ziel es ist, schnell auf Veränderungen zu reagieren. Es gibt einen Link zum IBM Systems-Magazin (Band 44, Nummer 4), in dem es um SOA geht. Dort finden Sie einen tiefergehenden Einblick in die geschäftliche Seite des serviceorientierten Denkens.

Geschäftsprozess

Ein Geschäftsprozess ist eine Abfolge von Aktionen, die zu einem nützlichen Ergebnis führen.

Ein Geschäftsprozess umfasst zugehörige Geschäftselemente (Daten), die durch ihn fließen, einschließlich eingehender und ausgehender Prozessdaten.

Geschäftsaktivitäten und Aufgaben

Geschäftsaktivitäten und -aufgaben sind Elemente, die in ihrer Verknüpfung Geschäftsprozesse bilden.

Einer Geschäftsaktivität können Merkmale wie Dauer, Kosten, Umsatz, Ressourcen, Inputs und Outputs zugeordnet werden. Alle diese Elemente sind Bestandteile von Geschäftsprozessen. Service-Identifikationstechniken ermöglichen es Ihnen, Geschäftsprozesse in Aktionen und Aufgaben zu zerlegen, auf deren Grundlage bestehende oder notwendige Services (und deren Abläufe) bestimmt werden. Solche Dienste werden manchmal als „Geschäftsdienste“ bezeichnet.

Geschäftsprozessmodellierung

„Bestehende“ Geschäftsprozesse in einer Organisation können komplex sein, da sie oft das Ergebnis zahlreicher Änderungen am ursprünglichen Prozess sind. Eine wesentliche Voraussetzung besteht darin, Geschäftsprozesse zu verstehen, formal zu definieren und zu dokumentieren. Darüber hinaus ermöglicht die Modellierung und Simulation „bestehender“ und „gewünschter“ (zukünftiger) Geschäftsprozesse die Ermittlung von Kosten, Zeitverzögerungen und zu automatisierenden Bereichen.

Die Geschäftsprozessmodellierung bietet nicht nur eine visuelle Darstellung, sondern ermöglicht auch die spätere Verknüpfung von Elementen des Geschäftsprozessmodells mit IT-Elementen – sofern sie in einer Infrastruktur durchgeführt wird, die mit den zugrunde liegenden Metadaten der Prozesse arbeitet.

Aufgaben für Menschen

Nicht selten erfordern Prozesse menschliches Eingreifen (zum Beispiel die Genehmigung einer Geschäftsreise oder eines Kredits). Bei der Modellierung eines Geschäftsprozesses werden solche Aufgaben als manuell definiert und jeder Aufgabe wird eine bestimmte Rolle zugewiesen. Nach der Bereitstellung benötigen SOA-Prozesse Unterstützung für menschliche Aufgaben. Produkte wie IBM WebSphere Process Server stellen Benutzern Listen ausstehender Aufgaben zur Verfügung, die sie erledigen müssen. In Kombination mit Produkten wie IBM WebSphere Portal und Lotus Sametime können Benutzer auch zusammenarbeiten und das System über ihre Entscheidungen informieren, sodass das System weiterhin Prozesse ausführen kann. Dieser menschliche Faktor ist entscheidend für den Erfolg von SOA.

BPEL

IBM, Microsoft und andere Unternehmen waren an der Entwicklung der Business Process Execution Language (BPEL) für Web-Services-Spezifikationen beteiligt, die ein Mittel zur formalen Beschreibung von Geschäftsprozessen und Interaktionsprotokollen darstellt.

Branchen

In verschiedenen Tätigkeitsfeldern und Branchen können Geschäftsprozesse ihre eigenen Besonderheiten haben, wie zum Beispiel im Versicherungswesen. Branchengeschäftsprozesse werden durch Industriekonsortien bestimmt. Beispielsweise definiert das TeleManagement Forum eine erweiterte Telecom Operations Map (eTOM) für die Telekommunikationsbranche. Darüber hinaus können Unternehmen ihre eigenen Geschäftsprozesse auf Basis bewährter Modelle wie IBM Industry Models implementieren, um sich von der Konkurrenz abzuheben. Die Referenz bezieht sich auf IBM Insurance Application Architecture (IAA), ein Beispiel für IBM Industry Models.

Geschäftsprozessmanagement

Business Process Management (BPM) befasst sich mit dem gesamten Lebenszyklus von Geschäftsprozessen, um deren Effizienz, Flexibilität und Kontrollierbarkeit zu verbessern.

BPM führt die Modellierung, Simulation, Optimierung, Platzierung, Ausführung, Führung und Überwachung von Geschäftsprozessen durch, liefert anschließend die zur Verbesserung der Modelle erforderlichen Ergebnisse und beginnt den Verbesserungszyklus erneut. IBM WebSphere wird mit einer Vielzahl von BPM-bezogenen Produkten ausgeliefert.

Abschluss

In diesem ersten Teil einer Artikelserie zur SOA-Terminologie haben wir wichtige SOA-Begriffe wie Service, SOA und die Beziehung von SOA zur Architektur definiert. Wir haben zwei Begriffe definiert – Servicelebenszyklus und SOA-Governance –, die grundlegende Elemente von SOA sind. Darüber hinaus haben wir den Zusammenhang von SOA mit dem Geschäft diskutiert und Geschäftsprozesse beschrieben. Und das ist erst der Anfang. In den folgenden Artikeln definieren wir SOA-Begriffe im Zusammenhang mit IT-Design, -Entwicklung, -Workflow und -Management. Bleiben Sie also mit DeveloperWorks in Verbindung!

Danksagungen

Ich möchte meinen Kollegen bei IBM danken, die einen großen Beitrag zur serviceorientierten Architektur und den in diesem Artikel beschriebenen Ideen geleistet haben. Besonderer Dank geht an Richard D. Johnson und Steve Kinder für die Durchsicht dieses Artikels.

• Übersetzung

Die serviceorientierte Architektur (SOA) wurde Ende der 1980er Jahre erfunden. Es basiert auf Ideen, die in CORBA, DCOM, DCE und anderen Dokumenten dargelegt sind. Über SOA ist viel geschrieben worden; es gibt mehrere Implementierungen davon. Aber im Wesentlichen lässt sich SOA auf mehrere Ideen reduzieren, und die Architektur schreibt nicht vor, wie sie umgesetzt werden:

• Benutzerzentrierte Anwendungsinteroperabilität.
• Wiederverwendung von Unternehmensdienstleistungen.
• Unabhängigkeit von einer Reihe von Technologien.
• Autonomie (unabhängige Entwicklung, Skalierbarkeit und Bereitstellung).

SOA ist eine Reihe von Architekturprinzipien, die unabhängig von Technologien und Produkten sind, genau wie Polymorphismus oder Kapselung.

In diesem Artikel werde ich die folgenden Muster im Zusammenhang mit SOA betrachten:

• Common Object Request Broker-Architektur (CORBA).
• Internetdienste.
• Nachrichtenwarteschlange.
• Enterprise Service Bus (ESB).
• Mikrodienste.

Common Object Request Broker-Architektur (CORBA)

In den 1980er Jahren begann die aktive Nutzung von Unternehmensnetzwerken und Client-Server-Architekturen. Es besteht Bedarf an einer Standardmethode für die Interaktion zwischen Anwendungen, die mit unterschiedlichen Technologien erstellt wurden, auf unterschiedlichen Computern und unter unterschiedlichen Betriebssystemen ausgeführt werden. Aus diesem Grund wurde CORBA entwickelt. Dies ist einer der verteilten Computerstandards, der in den 1980er Jahren entstand und 1991 seine Blütezeit erlebte.

Der CORBA-Standard wurde von mehreren Anbietern implementiert. Es bietet:

• Plattformunabhängige Remoteprozeduraufrufe.
• Transaktionen (auch gelöschte!).
• Sicherheit.
• Veranstaltungen.
• Unabhängigkeit von der Wahl der Programmiersprache.
• Unabhängigkeit von der Wahl des Betriebssystems.
• Unabhängigkeit von der Wahl der Ausrüstung.
• Datenerfassung über Interface Definition Language (IDL).

Auch heute noch wird CORBA für heterogenes Computing verwendet. Beispielsweise ist es immer noch Teil von Java EE, obwohl es ab Java 9 als separates Modul ausgeliefert wird.

Das möchte ich gerne anmerken Ich glaube nicht, dass CORBA ein SOA-Muster ist(obwohl ich der Meinung bin, dass sowohl CORBA- als auch SOA-Muster im Bereich des verteilten Rechnens liegen). Ich spreche hier darüber, weil ich denke, dass die Mängel von CORBA einer der Gründe für die Entstehung von SOA sind.

Arbeitsprinzip

Zuerst müssen wir einen Object Request Broker (ORB) erhalten, der der CORBA-Spezifikation entspricht. Es wird vom Anbieter bereitgestellt und verwendet Sprachzuordnungen, um Stubs und Skelette in Client-Codesprachen zu generieren. Mit diesem ORB und Schnittstellendefinitionen mittels IDL (analog zu WSDL) können Sie im Client remote aufrufbare Klassen auf Basis realer Klassen generieren - Stubs(Stub-Klassen). Und auf dem Server können Sie Klassen generieren - Skelette(Skelettklassen), die eingehende Anfragen verarbeiten und echte Zielobjekte aufrufen.

Das aufrufende Programm (Aufrufer) ruft eine lokale Prozedur auf, die durch einen Stub implementiert wird.

1. Der Stub prüft den Aufruf, erstellt eine Anforderungsnachricht und übergibt sie an den ORB.
2. Der Client-ORB sendet eine Nachricht über das Netzwerk an den Server und blockiert den aktuellen Ausführungsthread.
3. Der Server-ORB empfängt die Anforderungsnachricht und erstellt eine Skelettinstanz.
4. Das Skelett führt die Prozedur im aufrufbaren Objekt aus.
5. Der Angerufene führt die Berechnung durch und gibt das Ergebnis zurück.
6. Das Skelett packt die Ausgabeargumente in eine Antwortnachricht und übergibt sie an den ORB.
7. ORB sendet eine Nachricht über das Netzwerk an den Client.
8. Der Client-ORB empfängt die Nachricht, entpackt sie und übergibt die Informationen an den Stub.
9. Der Stub übergibt Ausgabeargumente an die aufrufende Methode, entsperrt den Ausführungsthread und das aufrufende Programm setzt seine Arbeit fort.

Vorteile

• Unabhängigkeit von den gewählten Technologien (ORB-Implementierung nicht eingerechnet).
• Unabhängigkeit von Datenübertragungs-/Kommunikationsfunktionen.

Mängel

• Standortunabhängig: Der Clientcode hat keine Ahnung, ob der Anruf lokal oder remote ist. Das hört sich gut an, aber die Länge der Verzögerung und die Art der Ausfälle können stark variieren. Wenn wir nicht wissen, was unser Aufruf ist, kann die Anwendung keine geeignete Strategie für die Verarbeitung von Methodenaufrufen auswählen und daher keine Remote-Aufrufe innerhalb der Schleife generieren. Dadurch läuft das gesamte System langsamer.
• Komplexe, aufgeblähte und mehrdeutige Spezifikation: Es wurde aus mehreren Versionen von Spezifikationen verschiedener Anbieter zusammengestellt und war daher (damals) aufgebläht, mehrdeutig und schwer zu implementieren.
• Verstopfte Kommunikationsleitungen: Es werden bestimmte Protokolle über TCP/IP sowie bestimmte Ports (oder sogar zufällige Ports) verwendet. Doch Unund Firewalls lassen HTTP-Verbindungen oft nur auf Port 80 zu und blockieren so die CORBA-Kommunikation.

Internetdienste

Obwohl es heute Verwendungsmöglichkeiten für CORBA gibt, wissen wir das Es war notwendig, die Anzahl der gelöschten Anfragen zu reduzieren um die Systemleistung zu verbessern. Auch erforderte einen zuverlässigen Kommunikationskanal und eine einfachere Nachrichtenspezifikation.

Und um diese Probleme zu lösen, kamen Ende der 1990er Jahre Webdienste auf den Markt.

• erforderlich zuverlässiger Kommunikationskanal, Deshalb:
  • HTTP funktioniert jetzt standardmäßig auf Port 80.
  • Sie begannen, eine plattformunabhängige Sprache (wie XML oder JSON) für die Nachrichtenübermittlung zu verwenden.
• Hatte Reduzieren Sie die Anzahl der Remote-Anfragen, Deshalb:

[Web]Dienste können unabhängig von der Technologie auf standardmäßige Weise veröffentlicht, entdeckt und genutzt werden.
-Microsoft 2004,

Dank Microservices sind wir im SOA-Paradigma vom Remote-Aufruf von Objektmethoden (CORBA) zur Weitergabe von Nachrichten zwischen Diensten übergegangen.

Sie müssen jedoch verstehen, dass Webdienste innerhalb von SOA nicht nur allgemeine APIs sind, die einfach CRUD-Zugriff auf die Datenbank über HTTP bereitstellen. In einigen Fällen kann diese Implementierung nützlich sein, Im Interesse der Integrität Ihrer Daten ist es jedoch wichtig, dass Benutzer das zugrunde liegende Implementierungsmodell verstehen und die Geschäftsregeln befolgen. SOA impliziert, dass Webdienste begrenzte Kontexte von Geschäftsunterdomänen sind und trennt die Implementierung von den Aufgaben, die Webdienste lösen.

Aus technologischer Sicht ist SOA nicht nur eine Servicearchitektur, sondern eine Reihe von Richtlinien, Techniken und Frameworks, über die wir die von uns benötigten Services bereitstellen und empfangen.
- Microsoft 2004, Grundlegendes zur serviceorientierten Architektur

Vorteile

• Isolierung von Domänenkontexten.

Mängel

• Synchrones Messaging kann Systeme überlasten.

Nachrichtenwarteschlange

Wir haben mehrere Anwendungen, die über plattformunabhängige Nachrichten asynchron miteinander kommunizieren. Message Queuing verbessert die Skalierbarkeit und erhöht die Anwendungsisolation. Sie müssen nicht wissen, wo sich die anderen Apps befinden, wie viele es gibt oder was sie sind. Allerdings müssen alle diese Anwendungen dieselbe Nachrichtensprache verwenden, also ein vordefiniertes Textformat zur Darstellung von Daten.

Message Queuing verwendet einen Software-Nachrichtenbroker (RabbitMQ, Beanstalkd, Kafka usw.) als Infrastrukturkomponente. Um die Kommunikation zwischen Anwendungen zu implementieren, können Sie die Warteschlange auf verschiedene Arten konfigurieren:

• Anfrage/Antwort

  • Der Client sendet eine Nachricht an die Warteschlange, einschließlich eines Links zu Referenz „Gespräch“.. Die Nachricht kommt an einem speziellen Knoten an, der dem Absender mit einer weiteren Nachricht antwortet, die einen Link zu derselben enthält sprechen, damit der Empfänger weiß, welches sprechen verweist auf die Nachricht und kann weiter agieren. Dies ist sehr nützlich für Geschäftsprozesse mittlerer und langer Dauer (Ereignisketten, Sagen).
• Veröffentlichen/Abonnieren
  • Nach Listen
    Die Warteschlange verwaltet Listen der veröffentlichten Abonnementthemen (Themen) und ihrer Abonnenten. Wenn die Warteschlange eine Nachricht für ein Thema empfängt, platziert sie diese in der entsprechenden Liste. Eine Nachricht wird anhand des Nachrichtentyps oder eines vordefinierten Satzes von Kriterien, einschließlich des Inhalts der Nachricht, einem Thema zugeordnet.
  • Broadcast-basiert
    Wenn die Warteschlange eine Nachricht empfängt, sendet sie diese an alle Knoten, die die Warteschlange überwachen. Knoten müssen die Daten selbst filtern und nur relevante Nachrichten verarbeiten.

Alle diese Muster können einem der beiden zugeschrieben werden Pull- (Umfrage), oder zu drücken-Ansatz:

• In einem Pull-Szenario fragt der Client die Warteschlange mit einer bestimmten Häufigkeit ab. Der Client verwaltet seine Last, es kann jedoch zu Verzögerungen kommen: Die Nachricht befindet sich bereits in der Warteschlange und der Client verarbeitet sie noch nicht, da die Zeit für die nächste Warteschlangenabfrage noch nicht gekommen ist.
• In einem Push-Szenario übermittelt die Warteschlange Nachrichten sofort an Clients, sobald sie eintreffen. Es gibt keine Latenz, aber die Clients verwalten ihre Last nicht.

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.

Mängel

• Aufgrund unterschiedlicher Nachrichtensprachen ist es schwierig, verschiedene Webdienste zu integrieren. Beispielsweise verwenden zwei Webdienste unterschiedliche JSON-Darstellungen desselben Konzepts.

Enterprise Service Bus (ESB)

Enterprise Service Bus nutzte Webdienste bereits in den 1990er Jahren, als sie sich gerade in der Entwicklung befanden (vielleicht verwendeten einige Implementierungen zuerst CORBA?).

ESB entstand aus einer Zeit, als Unternehmen separate Anwendungen hatten. Zum Beispiel eine für die Arbeit mit den Finanzen, eine andere für die Personalbuchhaltung, eine dritte für die Lagerverwaltung usw., und die mussten irgendwie miteinander verbunden, irgendwie integriert sein. Aber alle diese Anwendungen wurden ohne Integrationsaspekte erstellt; es gab keine Standardsprache für die Anwendungsinteraktion (wie es sie heute gibt). Daher stellten Anwendungsentwickler Endpunkte zum Senden und Empfangen von Daten in einem bestimmten Format bereit. Kundenunternehmen integrierten dann die Anwendungen, richteten Kommunikationskanäle zwischen ihnen ein und konvertierten Nachrichten von einer Anwendungssprache in eine andere.

Eine Nachrichtenwarteschlange kann die Kommunikation zwischen Anwendungen erleichtern, das Problem unterschiedlicher Sprachformate kann sie jedoch nicht lösen. Es wurde jedoch versucht, die Nachrichtenwarteschlange von einem einfachen Kommunikationskanal in einen Vermittler umzuwandeln, der Nachrichten zustellt und in die erforderlichen Formate/Sprachen umwandelt. ESB war der nächste Schritt in der natürlichen Entwicklung der einfachen Nachrichtenwarteschlange.

Diese Architektur verwendet eine modulare Anwendung (zusammengesetzte Anwendung), die normalerweise benutzerorientiert ist und mit Webdiensten kommuniziert, um einige Vorgänge auszuführen. Diese Webdienste können wiederum mit anderen Webdiensten kommunizieren und anschließend einige Daten an die Anwendung zurückgeben. Aber weder die Anwendung noch die Backend-Dienste wissen etwas voneinander, einschließlich Standort- und Kommunikationsprotokollen. Sie wissen nur, welchen Dienst sie kontaktieren möchten und wo sich der Dienstbus befindet.

Der Client (Dienst oder modulare Anwendung) sendet eine Anfrage an den Servicebus, der verwandelt wandelt die Nachricht in ein am Ziel unterstütztes Format um und leitet die Anfrage dorthin weiter. Alle Die Interaktion erfolgt über den Servicebus. Wenn dieser also ausfällt, fallen auch alle anderen Systeme aus. Das heißt, der ESB ist ein wichtiger Vermittler, eine sehr komplexe Komponente des Systems.

Dies ist eine sehr vereinfachte Beschreibung der ESB-Architektur. Obwohl der ESB die Hauptkomponente der Architektur ist, kann das System darüber hinaus auch andere Komponenten wie Domänenbroker, Datendienste, Prozessorchestrierungsdienste und Regel-Engines nutzen. Ein föderiertes Design kann dasselbe Muster verwenden: Das System ist in Geschäftsdomänen mit eigenen ESBs unterteilt, und alle ESBs sind miteinander verbunden. Dieses Schema bietet eine höhere Leistung und es gibt keinen Single Point of Failure: Wenn ein ESB ausfällt, leidet nur dessen Geschäftsdomäne.

Hauptaufgaben des ESB:

• Überwachen und leiten Sie Nachrichten zwischen Diensten weiter.
• Konvertieren Sie Nachrichten zwischen kommunizierenden Servicekomponenten.
• Verwalten Sie die Bereitstellung und Versionierung von Diensten.
• Verwalten Sie die Nutzung redundanter Dienste.
• Bereitstellung von Standard-Ereignisverarbeitungs-, Datentransformations- und Zuordnungsdiensten, Nachrichten- und Ereigniswarteschlangendiensten, Sicherheits- oder Ausnahmebehandlungsdiensten sowie Protokollübersetzungs- und Bereitstellungsdiensten erforderliche Qualität Kommunikation.

Beim Aufbau von Kommunikationsstrukturen zwischen verschiedenen Prozessen haben wir viele Produkte und Ansätze gesehen, die sehr fortschrittliche Kommunikationsmechanismen nutzen. Ein gutes Beispiel sind Enterprise Service Busse, die häufig komplexe Nachrichtenweiterleitung, Choreografie, Transformation und Durchsetzung von Geschäftsregeln umfassen.
- Martin Fowler 2014, Microservices

Dieses architektonische Muster hat positive Aspekte. Ich finde es jedoch besonders nützlich in Fällen, in denen wir die Webdienste nicht „besitzen“ und einen Mittelsmann benötigen, der Nachrichten zwischen Diensten sendet, Geschäftsprozesse orchestriert, die mehrere Webdienste verwenden, und andere Aufgaben.

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.
• Isolierung von Domänenkontexten.
• Einfache Verbindung und Trennung von Diensten.
• Asynchrones Messaging hilft bei der Verwaltung der Systemlast.
• Ein zentraler Punkt für die Verwaltung der Versionierung und Konvertierung.

Mängel

• Die Kommunikationsgeschwindigkeit ist geringer, insbesondere zwischen bereits kompatiblen Diensten.
• Zentralisierte Logik:
  • Ein Single Point of Failure, der die Kommunikationssysteme des gesamten Unternehmens zum Absturz bringen kann.
  • Große Komplexität der Konfiguration und des Supports.
  • Mit der Zeit kann es dazu kommen, dass Geschäftsregeln im ESB gespeichert werden.
  • Der Bus ist so komplex, dass man ein ganzes Team braucht, um ihn zu bedienen.
  • Hohe Abhängigkeit der Dienste vom ESB.

Mikrodienste

Die Microservice-Architektur basiert auf SOA-Konzepten. Sein Zweck ist derselbe wie der des ESB: die Erstellung einer einzigen gemeinsamen Unternehmensanwendung aus mehreren spezialisierten Anwendungen von Geschäftsdomänen.

Der Hauptunterschied zwischen Microservices und dem Bus besteht darin, dass der ESB im Kontext erstellt wurde Integration einzelner Anwendungen, um eine einzelne verteilte Unternehmensanwendung zu erstellen. Und die Microservice-Architektur wurde im Kontext des schnellen und ständigen Wandels geschaffen Unternehmen, die (meistens) ihre eigenen Cloud-Anwendungen von Grund auf erstellen.

Das heißt, im Fall von ESB haben wir Es gab bereits Bewerbungen, die nicht zu uns „gehören“., und deshalb konnten wir sie nicht ändern. Und im Fall von Microservices wir Volle Kontrolle über Anwendungen(Gleichzeitig können Webservices von Drittanbietern im System genutzt werden).

Die Art und Weise, wie Microservices erstellt/entworfen werden, erfordert keine tiefe Integration. Microservices müssen zum Geschäftskonzept und zum begrenzten Kontext passen. Sie sollten ihren Zustand beibehalten, unabhängig von anderen Mikrodiensten sein und daher weniger Integration benötigen. Das heißt, eine geringe gegenseitige Abhängigkeit und eine hohe Konnektivität führten zu dem bemerkenswerten Nebeneffekt, dass der Integrationsbedarf verringert wurde.

[Microservices sind] kleine, autonome Dienste, die zusammenarbeiten und auf eine Geschäftsdomäne ausgerichtet sind.
- Sam Newman 2015, Prinzipien von Microservices

Der Hauptnachteil der ESB-Architektur war die sehr komplexe zentralisierte Anwendung, von der alle anderen Anwendungen abhingen. Und in einer Microservice-Architektur wird diese Anwendung fast vollständig entfernt.

Es gibt immer noch Elemente, die das gesamte Microservices-Ökosystem durchdringen. Allerdings haben sie im Vergleich zum ESB deutlich weniger Aufgaben. Beispielsweise wird eine Nachrichtenwarteschlange immer noch für die asynchrone Kommunikation zwischen Mikrodiensten verwendet, aber dies ist nur ein Kanal zum Übertragen von Nachrichten, mehr nicht. Oder Sie können sich das Microservices-Ökosystem-Gateway vorstellen, über das der gesamte externe Datenaustausch erfolgt.

• Entwerfen von Diensten rund um Geschäftsdomänen
  Dies kann uns stabile Schnittstellen, hochkohärente und wenig voneinander abhängige Codemodule sowie klar definierte, abgegrenzte Kontexte liefern.
• Automatisierungskultur
  Das gibt uns viel mehr Freiheit und wir können mehr Module einsetzen.
• Implementierungsdetails ausblenden
  Dadurch können sich Dienste unabhängig voneinander entwickeln.
• Vollständige Dezentralisierung
  Dezentralisieren Sie Entscheidungsfindung und Architekturkonzepte, geben Sie Teams Autonomie, sodass das Unternehmen selbst komplex wird adaptives System in der Lage, sich schnell an Veränderungen anzupassen.
• Unabhängige Bereitstellung
  Kann eingesetzt werden neue Version Service, ohne etwas anderes zu ändern.
• Verbraucher zuerst
  Der Dienst sollte einfach zu nutzen sein, auch für andere Dienste.
• Fehleranalyse
  Fällt ein Dienst aus, funktionieren die anderen weiterhin, wodurch das gesamte System ausfallsicher wird.
• Einfache Überwachung
  Da das System aus vielen Komponenten besteht, ist es schwierig, den Überblick über alles zu behalten, was darin passiert. Wir benötigen ausgefeilte Überwachungstools, die es uns ermöglichen, in jeden Winkel des Systems zu blicken und jede Ereigniskette zu verfolgen.

Die Community bevorzugt einen anderen Ansatz: Intelligente Endpunkte und dumme Kanäle. Die Microservices, aus denen Anwendungen zusammengestellt werden, sollten möglichst wenig voneinander abhängen und gleichzeitig sehr eng gekoppelt sein – sie enthalten eine eigene Domänenlogik und funktionieren aus Sicht des klassischen Unix eher wie Filter: Sie nehmen Anfragen entgegen, Logik anwenden und Antworten generieren. Sie werden mit einfachen REST-ähnlichen Protokollen orchestriert und nicht mit komplexen Protokollen wie WS-Choreography oder BPEL oder einem zentralisierten Tool.
- Martin Fowler 2014, Microservices

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.
• Isolierung von Domänenkontexten.
• Einfache Verbindung und Trennung von Diensten.
• Asynchrones Messaging hilft bei der Verwaltung der Systemlast.
• Die Nachrichtensynchronität hilft bei der Verwaltung der Systemleistung.
• Völlig unabhängige und autonome Dienste.
• Geschäftslogik wird nur in Diensten gespeichert.
• Ermöglichen Sie dem Unternehmen, sich in ein komplexes adaptives System zu verwandeln, das aus mehreren kleinen autonomen Teilen/Teams besteht und in der Lage ist, sich schnell an Veränderungen anzupassen.

Mängel

• Hohe Komplexität der Bedienung:
  • Es erfordert viel, in eine starke DevOps-Kultur zu investieren.
  • Die Verwendung mehrerer Technologien und Bibliotheken kann außer Kontrolle geraten.
  • Änderungen an Eingabe-/Ausgabe-APIs müssen sorgfältig verwaltet werden, da viele Anwendungen diese Schnittstellen verwenden.
  • Die Verwendung von „Eventual Consistency“ kann schwerwiegende Folgen haben, die beim Entwurf einer Anwendung vom Backend bis zur UX berücksichtigt werden müssen.
  • Das Testen wird schwieriger, da sich Änderungen an der Schnittstelle auf unvorhersehbare Weise auf andere Dienste auswirken können.

20 Antworten

Kleiner Teaser:

SOA ist eine Art der Archivierung von Anwendungen, die aus einzelnen Software-Agenten besteht, die über einfache, klar definierte Schnittstellen verfügen und durch lose Kommunikation organisiert sind, um die erforderliche Funktion auszuführen.

In SOA gibt es zwei Rollen: Dienstanbieter und Dienstkonsument. Ein Software-Agent kann beide Rollen übernehmen. SOA ist kein völlig neues Konzept – dieser Artikel konzentriert sich jedoch auf SOA, das mithilfe von Webdiensten implementiert wird.

SOA ist ein neues Symbol für einige sehr alte Ideen:

Teilen Sie Ihren Code in wiederverwendbare Module auf.

Fassen Sie alle Designentscheidungen, die sich ändern könnten, in einem Modul zusammen.

Gestalten Sie Ihre Module so, dass sie auf unterschiedliche Weise kombiniert werden können (manchmal auch „Familie“ oder „Produktlinie“ genannt).

Das sind alles Gestaltungsprinzipien Software für Grundgestein, von denen viele zuerst von David Parnas formuliert wurden.

Was ist neu in SOA?

Sie machen es online.

Module kommunizieren, indem sie einander Nachrichten über ein Netzwerk senden, und nicht über traditionellere Programmiersprachenmechanismen wie Prozeduraufrufe. Insbesondere in einer serviceorientierten Architektur teilen sich die Teile typischerweise keinen veränderlichen Zustand (globale Variablen in einem herkömmlichen Programm). Oder, wenn sie den Status teilen, wird dieser Status sorgfältig in einer Datenbank gesperrt, die selbst ein Agent ist und problemlos mehrere gleichzeitige Clients verwalten kann.

Ich sehe viele Antworten, die Service Oriented Architecture (SOA) mit noch komplexeren Wörtern und Fachbegriffen erklären. Ich möchte es für den Laien anhand einer Analogie in einfachem Englisch aufschlüsseln.

Doch zunächst eine Beschreibung von SOA
SOA kann in drei Schichten beschrieben werden, wie in der folgenden Abbildung dargestellt. Auf der einen Seite haben wir den Anbieter und auf der anderen Seite den Verbraucher, getrennt durch eine Brücke, über die beide Seiten kommunizieren.

Der Verbraucher verwendet eine Reihe von Anwendungen, die für sein Unternehmen benötigt werden, und der Anbieter verwendet Komponenten, die diesen Anwendungen Informationen bereitstellen. Sie kommunizieren über eine Reihe von Diensten unter Verwendung einer gemeinsamen Architektur.

Analogie
Stellen Sie sich ein Haus im Norden vor, das Teil einer größeren Gemeinschaft ist, beispielsweise einer Stadt. Die Stadt verfügt über eigene komplexe Systeme für die Wasser- und Stromversorgung, die Abwasserentsorgung, den Transport und andere öffentliche Dienstleistungen. Das Haus ist der Verbraucher dieses Modells, die Stadt (oder Gemeinde) ist der Lieferant und Rohre, Abwasserleitungen, Stromleitungen, Glasfasern usw. ist die Infrastruktur, in der sie kommunizieren.

Dieses Modell kann frei mit SOA verglichen werden. Menschen im Haushalt nutzen viele verschiedene „Anwendungen“ wie Heizkörper, Computer, Toiletten, Lampen, Fußbodenheizung, Bäder usw. Bei diesen Apps ist es egal, wie die Stadt Wasser erzeugt, Strom erzeugt oder Abfälle im Laufe der Zeit behandelt. Die Bestandteile der Stadt sind Generatoren, Wasserpumpen usw Sanitärbereiche. Er versorgt das Haus mit all diesen Bedürfnissen, aber er nähert sich dem Haus, um es so zu nutzen, wie er es für richtig hält.

Ich hoffe, das hat wenigstens jemandem geholfen bestes Bild SOA.

Nehmen wir an, Sie haben vier Köche. Bei SOA gehen Sie davon aus, dass sie sich gegenseitig hassen, und versuchen daher, sie so wenig wie möglich miteinander reden zu lassen.

Wie machst du das? Nun, zuerst definieren Sie die Rollen und die Schnittstelle – Chefkoch 1 bereitet den Salat zu, Chefkoch 2 bereitet die Suppe zu, Chefkoch 3 bereitet das Steak zu usw. Dann stellen Sie die Gerichte gut geordnet auf den Tisch (das sind also die Schnittstellen) und sagen: „Bitte legen Sie Ihre Kreation in die Ihnen zugewiesenen Gerichte. Machen Sie sich keine Sorgen um die anderen.“

Daher sollten die vier Köche so wenig wie möglich miteinander reden, was bei der Entwicklung von Software sehr gut ist – nicht unbedingt, weil sie sich gegenseitig hassen, sondern aus anderen Gründen wie dem physischen Standort, der Effizienz der Entscheidungsfindung usw. .

Das bedeutet auch, dass Sie Speisen (Leistungen) nach eigenem Ermessen neu kombinieren können. Sie können zum Beispiel einfach den Nachtisch verwenden, um ein Café zu servieren, oder einfach Suppe nehmen und sie mit Brot kombinieren, das Sie bei einem anderen Unternehmen gekauft haben, um ein günstigeres Menü bereitzustellen, oder anderen Restaurants erlauben, Ihre Salate in Kombination mit ihren Gerichten usw. zu verwenden. d ..

Eine der erfolgreichsten SOA-Implementierungen fand bei Amazon statt. Aufgrund ihres Designs können sie ihre gesamte Infrastruktur neu verpacken und als Amazon Web Service verkaufen.

*Dies ist nur ein Aspekt von SOA.

SOA ist ein architektonischer Stil, aber auch Vision darüber, wie eine heterogene Anwendung entwickelt und integriert werden sollte. Das Hauptziel von SOA ist die Umstellung monolithische Anwendungen und stattdessen Reihe wiederverwendbarer Dienste, die zum Erstellen von Anwendungen erstellt werden können.

Meiner Meinung nach macht SOA nur auf Unternehmensebene Sinn und hat für eine einzelne Anwendung keine Bedeutung.

In vielen Unternehmen verfügte jede Abteilung über einen eigenen Satz Unternehmensanwendungen

Eine ähnliche Funktion wurde mehrfach implementiert

Daten (z. B. Kunden- oder Mitarbeiterdaten) müssen über mehrere Anwendungen hinweg gemeinsam genutzt werden

Die Anwendungen erfolgten dezentral.

Bei SOA geht es darum, wiederverwendbare Dienste im gesamten Unternehmen bereitzustellen, sodass daraus eine Anwendung erstellt und zusammengestellt werden kann. SOA-Versprechen:

Keine Notwendigkeit, ähnliche Funktionen immer wieder neu zu definieren (z. B. Bereitstellung von Kunden- oder Mitarbeiterdiensten)

Erleichtert die Integration von Anwendungen und den Zugriff auf gemeinsame Daten oder Funktionen

• Entwicklung, unternehmensorientierte Bemühungen.

Um SOA anzuzeigen, benötigen Sie technologisch auch verschieben organisatorisch Schicht. Während es einige Probleme löst, bringt es auch andere mit sich, zum Beispiel ist die Sicherheit bei SOA mit einer monolithischen Anwendung viel schwieriger. Es wird also darüber diskutiert, ob SOA funktioniert oder nicht.

Dies ist eine 1000-Fuß-SOA-Ansicht. Dabei bleibt es jedoch noch nicht. Es gibt weitere Konzepte, die SOA ergänzen, wie zum Beispiel Business Process Engineering (BPM), Enterprise Service Bus (ESB), Complex Event Processing (CEP) usw. Sie lösen das Problem IT-/Business-Ausrichtung So kann die IT das Unternehmen effektiv unterstützen.

SOA ist ein Akronym für Service Oriented Architecture.

SOA entwickelt und schreibt Softwareanwendungen so, dass einzelne Softwaremodule nahtlos integriert werden können und ein hoher Wiederverwendungsgrad gewährleistet ist.

Die meisten Leute beschränken SOA auf das Schreiben von Client/Server-Software für Webdienste. Dies ist aber auch ein kleiner Kontext für SOA. SOA ist viel größer als die Web-Services-Wechselumgebung der letzten Jahre im Sommer, was wahrscheinlich der Grund dafür ist, dass Menschen SOA allgemein als Web-Services betrachten, was den Umfang und die Bedeutung von SOA einschränkt.

Sie könnten darüber nachdenken, ein Datenbankzugriffsmodul zu erstellen, das so unabhängig ist, dass es eigenständig und ohne Abhängigkeiten ausgeführt werden kann. Dieses Modul kann Klassen verfügbar machen, die von jeder Host-Software verwendet werden können, die auf die Datenbank zugreifen muss. In der Hostanwendung gibt es keine Startkonfiguration. Alles, was benötigt oder benötigt wird, wird über die vom Datenbankzugriffsmodul bereitgestellten Klassen weitergeleitet. Wir können diese Klassen als Dienste bezeichnen und ein Modul als Dienst betrachten.

Die Praxis von SOA ermöglicht mit DRY ein hohes Maß an Wiederverwendung, was zu einer äußerst wartbaren Software führt. Das Erste, was die Softwarearchitektur tut, ist, die Dinge am Laufen zu halten – SOA bietet Ihnen das.

So wie ich es verstehe, besteht das Grundkonzept darin, dass man kleine „Dienste“ erstellt, die anderen Systemen etwas Nützliches bieten, und nicht selbst erstellt große Systeme, die normalerweise alles innerhalb des Systems erledigen.

Sie definieren also das Protokoll, das Sie für die Kommunikation verwenden (sagen wir, es könnten SOAP-Webdienste sein) und lassen Ihr System mit kleinen Diensten interagieren, um Ihre großen Ziele zu erreichen.“

Was in großen Organisationen häufig vorkommt, ist, dass es sich mit der Zeit entweder um monolithische, isolierte Systeme handelt, die überall verstreut sind, oder um ein wenig von beidem. Irgendwann kommt jemand und sagt, wir seien ein Chaos. Wenn Sie nun ein Reverse Engineering durchführen möchten (Geld an jemanden), hängt alles davon ab, wem Sie das Paradigma zahlen, um als Monolith zu navigieren, aber gleichzeitig in der Lage zu sein, Teile und Teile unabhängig vom Master/Monolithen hinzuzufügen.

Sie kaufen also Oracle SOA und Oracle wird zum Chef aller Ihrer Teile. Alle anderen Akteure müssen über einen Dienst (Webdienst oder etwas anderes) mit SOA interagieren. Der Oracle-Monolith kümmert sich um alles (Monolith soll nicht abwertend sein). Oh ja, Sie haben ASP.NET MVC auf der Vorderseite oder was auch immer.

Der Schlüssel besteht darin, Dinge ohne Auswirkungen in das System hinein und aus ihm heraus zu verschieben und den Oracle SOA-Anbieter Microsoft WCF als das Gehirn des Ganzen zu unterstützen. alles, was oop/ood mag, flüssig, Dinge, die sich ohne Auswirkungen hinein- und hinausbewegen, sogar menschliche Dienste, nicht nur Computer.

Für mich bedeutet es einfach eine Reihe von Webdiensten (oder wie auch immer wir sie in Zukunft nennen) mit einer schönen Oberfläche. Und wenn Sie über eine Datenbank verfügen, klicken Sie einfach auf die Datenbank und machen Sie sich keine Gedanken mehr über Wörter. alles in Ordnung.

aus dem ittoolbox-Blog.

Im Folgenden werden die Gemeinsamkeiten und Unterschiede zu früheren Entwurfsmethoden beschrieben:

SOA und strukturierte Programmierung o Ähnlichkeiten: Die meisten ähneln Unterprogrammaufrufen, bei denen Parameter übergeben werden und die Funktionsfunktion vom Aufrufer abstrahiert wird – z. B. CICS und COBOL CALL mit Ausführungs- und reserviertem Wort. Copybooks werden verwendet, um eine Datenstruktur zu definieren, die normalerweise als XML-Schema für Dienste definiert wird. o Unterschiede: SOA ist lose gekoppelt, was bedeutet, dass Änderungen am Dienst weniger Auswirkungen auf den Verbraucher (den „Anrufer“) haben und Dienste über Sprachen und Plattformen hinweg interoperieren.

SOA vs. OOA/OOD o Ähnlichkeiten: Kapselung, Abstraktion und definierte Schnittstellen o Unterschiede: SOA ist lose an Klassenhierarchie oder Vererbung, Abstraktionen gekoppelt niedriges Niveau- Klassenniveau und Business-Service

SOA und Legacy Component Driven Development (CBD) – z. B. CORBA, DCOM, EJB o Ähnlichkeiten: Wiederverwendung durch Assembly-Komponenten, Schnittstellen, Remote-Aufrufe o Unterschiede: Breite Übernahme von Standards, XML-Schemas und gemarshallten Objekten, Service-Orchestrierung, einfacher wiederverwendbares Design, Dienstleistungen sind geschäftsorientiert und IT-orientiert, Geschäftsdienstleistungen sind endlich groß (breit im Umfang)

SOA (für Integration) vs. Enterprise Application Integration (EAI) o Ähnlichkeiten: Best Practices (klar definierte Schnittstellen, standardisierte Designs, ereignisgesteuerte Architektur), wiederverwendbare Schnittstellen, gemeinsame Designs o Unterschiede: Standards, Akzeptanz und verbesserte Tools

Nun ja, sehen Sie. SOA steht für Service Oriented Architecture... Vereinfacht ausgedrückt schreiben Sie einen Code, der sehr allgemein ist, d. h. Es macht etwas, das in vielen Anwendungen verwendet werden kann ... könnte so etwas wie ein Adressbuch oder ein Taschenrechner sein. und Sie führen diesen Code in IIS aus. Sie stellen also über Ihren Code einen Dienst bereit. Sie sind also ein Dienstleister. Möchte nun jemand ähnlichen Code verwenden, muss er den Code nicht erneut schreiben. Es verwendet einfach Ihren Code, möglicherweise über einen Webdienst. Folglich wird er zum Verbraucher von Dienstleistungen. Daher wird die Erstellung eines Programms unter Verwendung solcher Dienste als SOA bezeichnet. Und es gibt freie Kommunikation, weil der Dienstanbieter und der Verbraucher auch dann kommunizieren können, wenn sie unterschiedliche Programmiersprachen verwenden. Ich hoffe, Sie verstehen.




Die serviceorientierte Architektur (SOA) wurde Ende der 1980er Jahre erfunden. Es basiert auf Ideen, die in CORBA, DCOM, DCE und anderen Dokumenten dargelegt sind. Über SOA ist viel geschrieben worden; es gibt mehrere Implementierungen davon. Aber im Wesentlichen lässt sich SOA auf mehrere Ideen reduzieren, und die Architektur schreibt nicht vor, wie sie umgesetzt werden:

• Benutzerzentrierte Anwendungsinteroperabilität.
• Wiederverwendung von Unternehmensdienstleistungen.
• Unabhängigkeit von einer Reihe von Technologien.
• Autonomie (unabhängige Entwicklung, Skalierbarkeit und Bereitstellung).

SOA ist eine Reihe von Architekturprinzipien, die unabhängig von Technologien und Produkten sind, genau wie Polymorphismus oder Kapselung.

In diesem Artikel werde ich die folgenden Muster im Zusammenhang mit SOA betrachten:

• Common Object Request Broker-Architektur (CORBA).
• Internetdienste.
• Nachrichtenwarteschlange.
• Enterprise Service Bus (ESB).
• Mikrodienste.

Common Object Request Broker-Architektur (CORBA)

In den 1980er Jahren begann die aktive Nutzung von Unternehmensnetzwerken und Client-Server-Architekturen. Es besteht Bedarf an einer Standardmethode für die Interaktion zwischen Anwendungen, die mit unterschiedlichen Technologien erstellt wurden, auf unterschiedlichen Computern und unter unterschiedlichen Betriebssystemen ausgeführt werden. Aus diesem Grund wurde CORBA entwickelt. Dies ist einer der verteilten Computerstandards, der in den 1980er Jahren entstand und 1991 seine Blütezeit erlebte.

Der CORBA-Standard wurde von mehreren Anbietern implementiert. Es bietet:

• Plattformunabhängige Remoteprozeduraufrufe.
• Transaktionen (auch gelöschte!).
• Sicherheit.
• Veranstaltungen.
• Unabhängigkeit von der Wahl der Programmiersprache.
• Unabhängigkeit von der Wahl des Betriebssystems.
• Unabhängigkeit von der Wahl der Ausrüstung.
• Datenerfassung über Interface Definition Language (IDL).

Auch heute noch wird CORBA für heterogenes Computing verwendet. Beispielsweise ist es immer noch Teil von Java EE, obwohl es ab Java 9 als separates Modul ausgeliefert wird.

Das möchte ich gerne anmerken Ich glaube nicht, dass CORBA ein SOA-Muster ist(obwohl ich der Meinung bin, dass sowohl CORBA- als auch SOA-Muster im Bereich des verteilten Rechnens liegen). Ich spreche hier darüber, weil ich denke, dass die Mängel von CORBA einer der Gründe für die Entstehung von SOA sind.

Arbeitsprinzip

Zuerst müssen wir einen Object Request Broker (ORB) erhalten, der der CORBA-Spezifikation entspricht. Es wird vom Anbieter bereitgestellt und verwendet Sprachzuordnungen, um Stubs und Skelette in Client-Codesprachen zu generieren. Mit diesem ORB und Schnittstellendefinitionen mittels IDL (analog zu WSDL) können Sie im Client remote aufrufbare Klassen auf Basis realer Klassen generieren - Stubs(Stub-Klassen). Und auf dem Server können Sie Klassen generieren - Skelette(Skelettklassen), die eingehende Anfragen verarbeiten und echte Zielobjekte aufrufen.




Das aufrufende Programm (Aufrufer) ruft eine lokale Prozedur auf, die durch einen Stub implementiert wird.

1. Der Stub prüft den Aufruf, erstellt eine Anforderungsnachricht und übergibt sie an den ORB.
2. Der Client-ORB sendet eine Nachricht über das Netzwerk an den Server und blockiert den aktuellen Ausführungsthread.
3. Der Server-ORB empfängt die Anforderungsnachricht und erstellt eine Skelettinstanz.
4. Das Skelett führt die Prozedur im aufrufbaren Objekt aus.
5. Der Angerufene führt die Berechnung durch und gibt das Ergebnis zurück.
6. Das Skelett packt die Ausgabeargumente in eine Antwortnachricht und übergibt sie an den ORB.
7. ORB sendet eine Nachricht über das Netzwerk an den Client.
8. Der Client-ORB empfängt die Nachricht, entpackt sie und übergibt die Informationen an den Stub.
9. Der Stub übergibt Ausgabeargumente an die aufrufende Methode, entsperrt den Ausführungsthread und das aufrufende Programm setzt seine Arbeit fort.

Vorteile

• Unabhängigkeit von den gewählten Technologien (ORB-Implementierung nicht eingerechnet).
• Unabhängigkeit von Datenübertragungs-/Kommunikationsfunktionen.

Mängel

• Standortunabhängig: Der Clientcode hat keine Ahnung, ob der Anruf lokal oder remote ist. Das hört sich gut an, aber die Länge der Verzögerung und die Art der Ausfälle können stark variieren. Wenn wir nicht wissen, was unser Aufruf ist, kann die Anwendung keine geeignete Strategie für die Verarbeitung von Methodenaufrufen auswählen und daher keine Remote-Aufrufe innerhalb der Schleife generieren. Dadurch läuft das gesamte System langsamer.
• Komplexe, aufgeblähte und mehrdeutige Spezifikation: Es wurde aus mehreren Versionen von Spezifikationen verschiedener Anbieter zusammengestellt und war daher (damals) aufgebläht, mehrdeutig und schwer zu implementieren.
• Verstopfte Kommunikationsleitungen: Es werden bestimmte Protokolle über TCP/IP sowie bestimmte Ports (oder sogar zufällige Ports) verwendet. Doch Unund Firewalls lassen HTTP-Verbindungen oft nur auf Port 80 zu und blockieren so die CORBA-Kommunikation.

Internetdienste

Obwohl es heute Verwendungsmöglichkeiten für CORBA gibt, wissen wir das Es war notwendig, die Anzahl der gelöschten Anfragen zu reduzieren um die Systemleistung zu verbessern. Auch erforderte einen zuverlässigen Kommunikationskanal und eine einfachere Nachrichtenspezifikation.

Und um diese Probleme zu lösen, kamen Ende der 1990er Jahre Webdienste auf den Markt.

• erforderlich zuverlässiger Kommunikationskanal, Deshalb:
  • HTTP funktioniert jetzt standardmäßig auf Port 80.
  • Sie begannen, eine plattformunabhängige Sprache (wie XML oder JSON) für die Nachrichtenübermittlung zu verwenden.
• Hatte Reduzieren Sie die Anzahl der Remote-Anfragen, Deshalb:

[Web]Dienste können unabhängig von der Technologie auf standardmäßige Weise veröffentlicht, entdeckt und genutzt werden.
-Microsoft 2004,




Dank Microservices sind wir im SOA-Paradigma vom Remote-Aufruf von Objektmethoden (CORBA) zur Weitergabe von Nachrichten zwischen Diensten übergegangen.

Sie müssen jedoch verstehen, dass Webdienste innerhalb von SOA nicht nur allgemeine APIs sind, die einfach CRUD-Zugriff auf die Datenbank über HTTP bereitstellen. In einigen Fällen kann diese Implementierung nützlich sein, Im Interesse der Integrität Ihrer Daten ist es jedoch wichtig, dass Benutzer das zugrunde liegende Implementierungsmodell verstehen und die Geschäftsregeln befolgen. SOA impliziert, dass Webdienste begrenzte Kontexte von Geschäftsunterdomänen sind und trennt die Implementierung von den Aufgaben, die Webdienste lösen.

Aus technologischer Sicht ist SOA nicht nur eine Servicearchitektur, sondern eine Reihe von Richtlinien, Techniken und Frameworks, über die wir die von uns benötigten Services bereitstellen und empfangen.
- Microsoft 2004, Grundlegendes zur serviceorientierten Architektur

Vorteile

• Isolierung von Domänenkontexten.

Mängel

• Synchrones Messaging kann Systeme überlasten.

Nachrichtenwarteschlange

Wir haben mehrere Anwendungen, die über plattformunabhängige Nachrichten asynchron miteinander kommunizieren. Message Queuing verbessert die Skalierbarkeit und erhöht die Anwendungsisolation. Sie müssen nicht wissen, wo sich die anderen Apps befinden, wie viele es gibt oder was sie sind. Allerdings müssen alle diese Anwendungen dieselbe Nachrichtensprache verwenden, also ein vordefiniertes Textformat zur Darstellung von Daten.

Message Queuing verwendet einen Software-Nachrichtenbroker (RabbitMQ, Beanstalkd, Kafka usw.) als Infrastrukturkomponente. Um die Kommunikation zwischen Anwendungen zu implementieren, können Sie die Warteschlange auf verschiedene Arten konfigurieren:

• Anfrage/Antwort

  • Der Client sendet eine Nachricht an die Warteschlange, einschließlich eines Links zu Referenz „Gespräch“.. Die Nachricht kommt an einem speziellen Knoten an, der dem Absender mit einer weiteren Nachricht antwortet, die einen Link zu derselben enthält sprechen, damit der Empfänger weiß, welches sprechen verweist auf die Nachricht und kann weiter agieren. Dies ist sehr nützlich für Geschäftsprozesse mittlerer und langer Dauer (Ereignisketten, Sagen).
• Veröffentlichen/Abonnieren
  • Nach Listen
    Die Warteschlange verwaltet Listen der veröffentlichten Abonnementthemen (Themen) und ihrer Abonnenten. Wenn die Warteschlange eine Nachricht für ein Thema empfängt, platziert sie diese in der entsprechenden Liste. Eine Nachricht wird anhand des Nachrichtentyps oder eines vordefinierten Satzes von Kriterien, einschließlich des Inhalts der Nachricht, einem Thema zugeordnet.
  • Broadcast-basiert
    Wenn die Warteschlange eine Nachricht empfängt, sendet sie diese an alle Knoten, die die Warteschlange überwachen. Knoten müssen die Daten selbst filtern und nur relevante Nachrichten verarbeiten.




Alle diese Muster können einem der beiden zugeschrieben werden Pull- (Umfrage), oder zu drücken-Ansatz:

• In einem Pull-Szenario fragt der Client die Warteschlange mit einer bestimmten Häufigkeit ab. Der Client verwaltet seine Last, es kann jedoch zu Verzögerungen kommen: Die Nachricht befindet sich bereits in der Warteschlange und der Client verarbeitet sie noch nicht, da die Zeit für die nächste Warteschlangenabfrage noch nicht gekommen ist.
• In einem Push-Szenario übermittelt die Warteschlange Nachrichten sofort an Clients, sobald sie eintreffen. Es gibt keine Latenz, aber die Clients verwalten ihre Last nicht.

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.

Mängel

• Aufgrund unterschiedlicher Nachrichtensprachen ist es schwierig, verschiedene Webdienste zu integrieren. Beispielsweise verwenden zwei Webdienste unterschiedliche JSON-Darstellungen desselben Konzepts.

Enterprise Service Bus (ESB)

Enterprise Service Bus nutzte Webdienste bereits in den 1990er Jahren, als sie sich gerade in der Entwicklung befanden (vielleicht verwendeten einige Implementierungen zuerst CORBA?).

ESB entstand aus einer Zeit, als Unternehmen separate Anwendungen hatten. Zum Beispiel eine für die Arbeit mit den Finanzen, eine andere für die Personalbuchhaltung, eine dritte für die Lagerverwaltung usw., und die mussten irgendwie miteinander verbunden, irgendwie integriert sein. Aber alle diese Anwendungen wurden ohne Integrationsaspekte erstellt; es gab keine Standardsprache für die Anwendungsinteraktion (wie es sie heute gibt). Daher stellten Anwendungsentwickler Endpunkte zum Senden und Empfangen von Daten in einem bestimmten Format bereit. Kundenunternehmen integrierten dann die Anwendungen, richteten Kommunikationskanäle zwischen ihnen ein und konvertierten Nachrichten von einer Anwendungssprache in eine andere.

Eine Nachrichtenwarteschlange kann die Kommunikation zwischen Anwendungen erleichtern, das Problem unterschiedlicher Sprachformate kann sie jedoch nicht lösen. Es wurde jedoch versucht, die Nachrichtenwarteschlange von einem einfachen Kommunikationskanal in einen Vermittler umzuwandeln, der Nachrichten zustellt und in die erforderlichen Formate/Sprachen umwandelt. ESB war der nächste Schritt in der natürlichen Entwicklung der einfachen Nachrichtenwarteschlange.



Diese Architektur verwendet eine modulare Anwendung (zusammengesetzte Anwendung), die normalerweise benutzerorientiert ist und mit Webdiensten kommuniziert, um einige Vorgänge auszuführen. Diese Webdienste können wiederum mit anderen Webdiensten kommunizieren und anschließend einige Daten an die Anwendung zurückgeben. Aber weder die Anwendung noch die Backend-Dienste wissen etwas voneinander, einschließlich Standort- und Kommunikationsprotokollen. Sie wissen nur, welchen Dienst sie kontaktieren möchten und wo sich der Dienstbus befindet.

Der Client (Dienst oder modulare Anwendung) sendet eine Anfrage an den Servicebus, der verwandelt wandelt die Nachricht in ein am Ziel unterstütztes Format um und leitet die Anfrage dorthin weiter. Alle Die Interaktion erfolgt über den Servicebus. Wenn dieser also ausfällt, fallen auch alle anderen Systeme aus. Das heißt, der ESB ist ein wichtiger Vermittler, eine sehr komplexe Komponente des Systems.

Dies ist eine sehr vereinfachte Beschreibung der ESB-Architektur. Obwohl der ESB die Hauptkomponente der Architektur ist, kann das System darüber hinaus auch andere Komponenten wie Domänenbroker, Datendienste, Prozessorchestrierungsdienste und Regel-Engines nutzen. Ein föderiertes Design kann dasselbe Muster verwenden: Das System ist in Geschäftsdomänen mit eigenen ESBs unterteilt, und alle ESBs sind miteinander verbunden. Dieses Schema bietet eine höhere Leistung und es gibt keinen Single Point of Failure: Wenn ein ESB ausfällt, leidet nur dessen Geschäftsdomäne.




Hauptaufgaben des ESB:

• Überwachen und leiten Sie Nachrichten zwischen Diensten weiter.
• Konvertieren Sie Nachrichten zwischen kommunizierenden Servicekomponenten.
• Verwalten Sie die Bereitstellung und Versionierung von Diensten.
• Verwalten Sie die Nutzung redundanter Dienste.
• Bereitstellung standardmäßiger Ereignisverarbeitungsdienste, Datenkonvertierung und -vergleich, Nachrichten- und Ereigniswarteschlangendienste, Sicherheits- oder Ausnahmebehandlungsdienste, Protokollkonvertierungsdienste und Sicherstellung der erforderlichen Kommunikationsqualität.

Beim Aufbau von Kommunikationsstrukturen zwischen verschiedenen Prozessen haben wir viele Produkte und Ansätze gesehen, die sehr fortschrittliche Kommunikationsmechanismen nutzen. Ein gutes Beispiel sind Enterprise Service Busse, die häufig komplexe Nachrichtenweiterleitung, Choreografie, Transformation und Durchsetzung von Geschäftsregeln umfassen.
- Martin Fowler 2014, Microservices

Dieses architektonische Muster hat positive Aspekte. Ich finde es jedoch besonders nützlich in Fällen, in denen wir die Webdienste nicht „besitzen“ und einen Mittelsmann benötigen, der Nachrichten zwischen Diensten sendet, Geschäftsprozesse orchestriert, die mehrere Webdienste verwenden, und andere Aufgaben.

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.
• Isolierung von Domänenkontexten.
• Einfache Verbindung und Trennung von Diensten.
• Asynchrones Messaging hilft bei der Verwaltung der Systemlast.
• Ein zentraler Punkt für die Verwaltung der Versionierung und Konvertierung.

Mängel

• Die Kommunikationsgeschwindigkeit ist geringer, insbesondere zwischen bereits kompatiblen Diensten.
• Zentralisierte Logik:
  • Ein Single Point of Failure, der die Kommunikationssysteme des gesamten Unternehmens zum Absturz bringen kann.
  • Große Komplexität der Konfiguration und des Supports.
  • Mit der Zeit kann es dazu kommen, dass Geschäftsregeln im ESB gespeichert werden.
  • Der Bus ist so komplex, dass man ein ganzes Team braucht, um ihn zu bedienen.
  • Hohe Abhängigkeit der Dienste vom ESB.

Mikrodienste

Die Microservice-Architektur basiert auf SOA-Konzepten. Sein Zweck ist derselbe wie der des ESB: die Erstellung einer einzigen gemeinsamen Unternehmensanwendung aus mehreren spezialisierten Anwendungen von Geschäftsdomänen.

Der Hauptunterschied zwischen Microservices und dem Bus besteht darin, dass der ESB im Kontext erstellt wurde Integration einzelner Anwendungen, um eine einzelne verteilte Unternehmensanwendung zu erstellen. Und die Microservice-Architektur wurde im Kontext des schnellen und ständigen Wandels geschaffen Unternehmen, die (meistens) ihre eigenen Cloud-Anwendungen von Grund auf erstellen.

Das heißt, im Fall von ESB haben wir Es gab bereits Bewerbungen, die nicht zu uns „gehören“., und deshalb konnten wir sie nicht ändern. Und im Fall von Microservices wir Volle Kontrolle über Anwendungen(Gleichzeitig können Webservices von Drittanbietern im System genutzt werden).

Die Art und Weise, wie Microservices erstellt/entworfen werden, erfordert keine tiefe Integration. Microservices müssen zum Geschäftskonzept und zum begrenzten Kontext passen. Sie sollten ihren Zustand beibehalten, unabhängig von anderen Mikrodiensten sein und daher weniger Integration benötigen. Das heißt, eine geringe gegenseitige Abhängigkeit und eine hohe Konnektivität führten zu dem bemerkenswerten Nebeneffekt, dass der Integrationsbedarf verringert wurde.

[Microservices sind] kleine, autonome Dienste, die zusammenarbeiten und auf eine Geschäftsdomäne ausgerichtet sind.
- Sam Newman 2015, Prinzipien von Microservices

Der Hauptnachteil der ESB-Architektur war die sehr komplexe zentralisierte Anwendung, von der alle anderen Anwendungen abhingen. Und in einer Microservice-Architektur wird diese Anwendung fast vollständig entfernt.

Es gibt immer noch Elemente, die das gesamte Microservices-Ökosystem durchdringen. Allerdings haben sie im Vergleich zum ESB deutlich weniger Aufgaben. Beispielsweise wird eine Nachrichtenwarteschlange immer noch für die asynchrone Kommunikation zwischen Mikrodiensten verwendet, aber dies ist nur ein Kanal zum Übertragen von Nachrichten, mehr nicht. Oder Sie können sich das Microservices-Ökosystem-Gateway vorstellen, über das der gesamte externe Datenaustausch erfolgt.

• Entwerfen von Diensten rund um Geschäftsdomänen
  Dies kann uns stabile Schnittstellen, hochkohärente und wenig voneinander abhängige Codemodule sowie klar definierte, abgegrenzte Kontexte liefern.
• Automatisierungskultur
  Das gibt uns viel mehr Freiheit und wir können mehr Module einsetzen.
• Implementierungsdetails ausblenden
  Dadurch können sich Dienste unabhängig voneinander entwickeln.
• Vollständige Dezentralisierung
  Dezentralisieren Sie Entscheidungsfindung und Architekturkonzepte, geben Sie Teams Autonomie, sodass das Unternehmen selbst zu einem komplexen adaptiven System wird, das sich schnell an Veränderungen anpassen kann.
• Unabhängige Bereitstellung
  Sie können eine neue Version des Dienstes bereitstellen, ohne etwas anderes zu ändern.
• Verbraucher zuerst
  Der Dienst sollte einfach zu nutzen sein, auch für andere Dienste.
• Fehleranalyse
  Fällt ein Dienst aus, funktionieren die anderen weiterhin, wodurch das gesamte System ausfallsicher wird.
• Einfache Überwachung
  Da das System aus vielen Komponenten besteht, ist es schwierig, den Überblick über alles zu behalten, was darin passiert. Wir benötigen ausgefeilte Überwachungstools, die es uns ermöglichen, in jeden Winkel des Systems zu blicken und jede Ereigniskette zu verfolgen.




Die Community bevorzugt einen anderen Ansatz: Intelligente Endpunkte und dumme Kanäle. Die Microservices, aus denen Anwendungen zusammengestellt werden, sollten möglichst wenig voneinander abhängen und gleichzeitig sehr eng gekoppelt sein – sie enthalten eine eigene Domänenlogik und funktionieren aus Sicht des klassischen Unix eher wie Filter: Sie nehmen Anfragen entgegen, Logik anwenden und Antworten generieren. Sie werden mit einfachen REST-ähnlichen Protokollen orchestriert und nicht mit komplexen Protokollen wie WS-Choreography oder BPEL oder einem zentralisierten Tool.
- Martin Fowler 2014, Microservices

Vorteile

• Unabhängigkeit von der Reihe von Technologien, Bereitstellung und Skalierbarkeit von Diensten.
• Standardmäßiger, einfacher und zuverlässiger Kommunikationskanal (Textübertragung per HTTP über Port 80).
• Optimiertes Messaging.
• Stabile Messaging-Spezifikation.
• Isolierung von Domänenkontexten.
• Einfache Verbindung und Trennung von Diensten.
• Asynchrones Messaging hilft bei der Verwaltung der Systemlast.
• Die Nachrichtensynchronität hilft bei der Verwaltung der Systemleistung.
• Völlig unabhängige und autonome Dienste.
• Geschäftslogik wird nur in Diensten gespeichert.
• Ermöglichen Sie dem Unternehmen, sich in ein komplexes adaptives System zu verwandeln, das aus mehreren kleinen autonomen Teilen/Teams besteht und in der Lage ist, sich schnell an Veränderungen anzupassen.

Mängel

• Hohe Komplexität der Bedienung:
  • Es erfordert viel, in eine starke DevOps-Kultur zu investieren.
  • Die Verwendung mehrerer Technologien und Bibliotheken kann außer Kontrolle geraten.
  • Änderungen an Eingabe-/Ausgabe-APIs müssen sorgfältig verwaltet werden, da viele Anwendungen diese Schnittstellen verwenden.
  • Die Verwendung von „Eventual Consistency“ kann schwerwiegende Folgen haben, die beim Entwurf einer Anwendung vom Backend bis zur UX berücksichtigt werden müssen.
  • Das Testen wird schwieriger, da sich Änderungen an der Schnittstelle auf unvorhersehbare Weise auf andere Dienste auswirken können.

Antimuster: Ravioli-Architektur

Ravioli-Architektur Wird normalerweise als Anti-Pattern der Microservice-Architektur bezeichnet. Ravioli führt dazu, dass zu viele Mikrodienste vorhanden sind, diese zu klein sind und keine Domänenkonzepte widerspiegeln.

Abschluss

SOA hat sich in den letzten Jahrzehnten stark weiterentwickelt. Dank der Ineffizienz früherer Lösungen und der Entwicklung der Technologie sind wir heute zu einer Microservice-Architektur gekommen.

Die Evolution folgte dem klassischen Weg: komplexe Probleme wurden in kleinere, leichter zu lösende Probleme zerlegt.

Das Problem der Codekomplexität kann auf die gleiche Weise gelöst werden, indem wir eine monolithische Anwendung in separate Domänenkomponenten (getrennte Kontexte) aufteilen. Doch je größer die Teams und Codebasen werden, desto größer wird der Bedarf an unabhängiger Entwicklung, Skalierung und Bereitstellung. SOA trägt dazu bei, diese Unabhängigkeit zu erreichen, indem es die Grenzen von Kontexten stärkt.




Ich wiederhole, der springende Punkt ist die schwache gegenseitige Abhängigkeit und die hohe Konnektivität, und die Größe der Komponenten sollte größer sein als zuvor. Sie müssen Ihre Anforderungen pragmatisch bewerten: Setzen Sie SOA nur bei Bedarf ein, da dies die Komplexität erheblich erhöht. Und wenn man tatsächlich auf SOA verzichten kann, dann ist es besser, Microservices in der entsprechenden Größe und Menge zu wählen, nicht mehr und nicht weniger.

SOA steht wörtlich für serviceorientierte Architektur.

In letzter Zeit ist es zu einer Art Schlagwort geworden, also teils ein Modewort, teils ein Begriff, der gezielt ausgesprochen wird, um andere zu beeindrucken.

Alle großen Softwareunternehmen (wie IBM, BEA, Oracle) präsentieren ständig Neuigkeiten, die SOA irgendwie übertreffen. Die meisten Beratungsunternehmen und Integratoren kommunizieren auf unterschiedliche Weise, dass sie sich mit der Implementierung und Implementierung serviceorientierter Architektur für Kunden befassen. Es ist oft so, dass jeder die serviceorientierte Architektur ein wenig (oder sehr) anders versteht.

Tatsächlich gibt es keine strenge Definition von SOA, es gibt kein Gremium, das Standards für serviceorientierte Architektur entwickelt (obwohl dies überhaupt nicht für die Technologien gilt, auf denen sie implementiert werden kann), und grundsätzlich kann es auch kein solches geben. Da SOA überhaupt keine Technologie ist und Philosophie, Konzept, Paradigma, neuer Ansatz(nennen Sie es wie Sie wollen) bis hin zum Aufbau von Unternehmensinformationssystemen und der Integration von Geschäfts- und Informationstechnologie.

Traditionelle Probleme von Informationssystemen

Derzeit hängt das Funktionieren eines Unternehmens stark davon ab, wie es im weitesten Sinne des Wortes automatisiert wird. In einer globalisierten Welt hängt der Erfolg (oder umgekehrt der Misserfolg) davon ab, wie schnell ein Unternehmen eine neue Dienstleistung oder ein neues Produkt auf den Markt bringen kann. Gleichzeitig wird die Situation durch die „Erosion“ der Haupttätigkeit von Unternehmen erschwert, beispielsweise beginnen Bankinstitute zunehmend, verschiedene Versicherungsprodukte anzubieten und umgekehrt sind Versicherungsunternehmen zunehmend im Finanzsektor tätig.

IT-Abteilungen von Unternehmen müssen schnell auf solche Veränderungen reagieren; letztlich hängt der Erfolg zahlreicher Geschäftsinitiativen davon ab, inwieweit und wie schnell sich die vorhandenen Automatisierungstools des Unternehmens grundsätzlich an die neuen Dienste anpassen lassen. Es stellt sich heraus, dass am Ende alles von der Automatisierungsabteilung abhängt. Natürlich ist diese Situation für ein Unternehmen völlig unnatürlich, aber seltsamerweise ist sie auch nicht gut für die IT-Abteilung, da sie ohne das Hauptgeschäft auch nicht mehr existiert.

Gleichzeitig sollten Sie aber keineswegs glauben, dass IT-Abteilungen sich über die Bedeutung und Macht freuen, die ihnen unerwartet zuteil wurde. Vielmehr verbringen Mitarbeiter dieser Abteilungen immer mehr Zeit in Besprechungen, um herauszufinden, warum sich Projekttermine zunehmend verzögern, erläutern, warum bestehende Software nicht einfach an neue Anforderungen angepasst werden kann, und begründen die Notwendigkeit einer personellen Aufstockung . Den Leitern dieser Abteilungen gerät der Schweiß ins Gesicht, wenn sie in Meetings darlegen müssen, warum trotz aller Investitionen immer wieder Pläne zur Einführung eines neuen Business Services aufgrund der Nichtverfügbarkeit der Software scheitern.

Definition von SOA

Im Kern enthält die serviceorientierte Architektur (SOA) keine neuen revolutionären Ideen, sondern ist eine Verallgemeinerung empfohlene Vorgehensweise Die Erstellung von Software- und Informationssystemen auf Unternehmensebene und höher hat nichts Originelles gebracht, dient aber als Quintessenz für die Durchführung von Integrationsprojekten.

Die Hauptgründe für die Entstehung von SOA sind die hohe Dynamik modernes Geschäft und die ständig steigenden Anforderungen an Informationssysteme, sich kontinuierlich an diese Dynamik anzupassen. Es reicht nicht mehr aus, dass ein Informationssystem eine einfache Automatisierung von Geschäftsinformationen und Berechnungsaufgaben bietet. Es muss sichergestellt werden, dass sich die sich durch den zunehmenden Wettbewerb rasch ändernden Geschäftsbedingungen erfüllen Totalreflexion V Informationssystem Das heißt, das Unternehmensinformationssystem muss sich genauso schnell ändern, wie sich die Geschäftsanforderungen und die Geschäftsprozesse des Unternehmens ändern.

In jedem Fall benötigen Kunden ein umfassendes Verständnis ihres Geschäfts und ein Verständnis für die Unvermeidlichkeit, für die Zukunft zu arbeiten, ohne sofortige Renditen zu erwarten, und Berater und Systemintegratoren benötigen hohe Qualifikationen auf allen Ebenen, Verständnis für die Aufgaben des Kunden und die Koordinierung von Bereichen Verantwortung. Sie müssen jedoch verstehen, dass SOA kein Allheilmittel und kein Ziel ist, sondern ein Mittel, um es zu erreichen und praktische Ergebnisse zu erzielen.

SOA zeichnet sich durch die folgenden Grundprinzipien aus, anhand derer wir sagen können, ob ein Informationssystem serviceorientiert ist oder nicht:

• Dienste als Bestandteile eines Informationssystems, die ihre Schnittstellen (Verträge) veröffentlichen. Diese Verträge sind unabhängig von der Plattform, Programmiersprache, Betriebssystem und andere technische Eigenschaften Implementierungen, Dienste interagieren miteinander und unterstützende Dienste über offene, weit verbreitete Standards.
• Jeder Dienst, aus dem das Informationssystem besteht, implementiert eine separate Geschäftsfunktion, bei der es sich um eine logisch separate, sich wiederholende Aufgabe handelt Bestandteil Geschäftsprozess des Unternehmens.
• geringe Kopplung. Dienste in Systemen, die auf SOA basieren, können unabhängig von anderen Systemdiensten implementiert werden; Sie müssen lediglich die Schnittstelle der verwendeten Dienste kennen.

Wie Sie sehen, handelt es sich nicht bei jedem dieser Punkte um ein spezifisches Merkmal von SOA. Viele Technologien haben diese Prinzipien übernommen. Besonderheit Ein auf SOA aufgebautes System ist die gleichzeitige Einhaltung all dieser Prinzipien.

Schauen wir sie uns etwas genauer an.

Dienste als Bestandteile eines Informationssystems

Ein Dienst ist eine unabhängige Softwarekomponente, die eine bestimmte Aufgabe ausführt, beispielsweise „eine Kreditkarte verifizieren“, für deren Nutzung durch Kunden keine spezielle Softwaretechnologie erforderlich ist.

Die Verwendung offener Standards ist wichtig charakteristisches Merkmal SOA. Dies reduziert die Zeit, die für die Anbindung eines neuen Geschäftsdienstes an ein bestehendes System benötigt wird, erheblich, und bei der Implementierung von SOA ist dies nicht erforderlich (was für Unternehmen mit langjähriger Erfahrung oft ein äußerst wichtiger Punkt ist). Bewährte und bestehende Entscheidungen umschreiben oder einfach aufgeben.

Die Wahl der verteilten Technologie spielt eine wesentliche Rolle. Die Verwendung von beispielsweise SNA oder DCOM als Kommunikationsmittel zwischen Diensten bringt eine Einschränkung mit sich, da alle Komponenten im System SNA oder DCOM verwenden müssen, was die Anwendbarkeit des Systems einschränkt.

Wenn man sagt, dass ein Informationssystem den Prinzipien von SOA folgt, dann sollte ein Dienst, der beispielsweise in der Java-Sprache implementiert ist und in einem EE-Container läuft, für die Verwendung durch Clients anwendbar sein, die in einer Windows-Umgebung implementiert sind, und umgekehrt.

Der Dienst führt eine wiederkehrende Geschäftsfunktion aus

Was ist ein Service im Kontext von SOA? Ist eine Funktion in einer Anwendung ein Dienst? Sind technische Services die Services, von denen die Leute reden, wenn sie SOA meinen? Das sind alles wichtige und relevante Fragen. Dienste in SOA implementieren sich wiederholende Geschäftsfunktionen, die erforderlich sind, um die koordinierte Arbeit komplexer, bestehender Aufgaben zu organisieren große Zahl verschiedene Komponenten, Anwendungen.

Bestehende Unternehmensanwendungen bestehen in der Regel aus einer Reihe monolithischer Module, von denen jedes häufig die Implementierung identischer Fragmente der Geschäftslogik umfasst, beispielsweise kann im obigen Beispiel eine Versicherungsgesellschaft erstellt werden, die auch mit der Bereitstellung von Finanzdienstleistungen begonnen hat in Versicherungs- und Bankensoftwaremodulen Rabattberechnung auf Basis von Kundendaten, Kundenhistorie und -volumen aktueller Betrieb. Wenn wir uns bei der Entwicklung an die Prinzipien der serviceorientierten Architektur halten, sollten wir einen Dienst „Rabattberechnung“ implementieren, der von allen Diensten kontaktiert wird, die einen Rabatt berechnen müssen.

Dadurch wird die Funktionalität von zahlreichen Anwendungen genutzt und es ist möglich, die Geschäftslogik schnell und relativ einfach zu ändern und an sich ständig ändernde Marktbedingungen anzupassen.

Darüber hinaus müssen Änderungen nur an einem einzigen Dienst vorgenommen werden und die vorgenommenen Änderungen werden von allen Client-Anwendungen gleichzeitig verwendet.

Dies ist einer der Hauptvorteile von SOA.

Dabei ist zu beachten, dass für die erfolgreiche Implementierung und den anschließenden Betrieb eines Systems auf SOA-Basis während der Entwicklung zunächst eine Analyse und Beschreibung der Geschäftsprozesse des Unternehmens durchgeführt werden muss. Im Prinzip handelt es sich dabei um recht eigenständige Schritte, denn die beschriebenen und optimierten Geschäftsprozesse selbst sind in hohem Maße die Grundlage für den erfolgreichen Betrieb eines Unternehmens und stellen eine Art Grundgerüst des Managementsystems dar. In diesem Fall wird jeder Struktureinheit ein Unikat zugeordnet funktionale Verantwortlichkeiten, Bereitstellung von Informationen an das Management zur Übernahme Managemententscheidungen und Koordination der Arbeit des gesamten Unternehmens. In diesem Fall kann die Automatisierung von Geschäftsprozessen durch den Einsatz von Software deren Ausführung weiter beschleunigen.

Es gibt unzählige Beispiele für die erfolglose oder nicht sehr erfolgreiche Implementierung automatisierter Informationssysteme. Bei der Analyse dieser Projekte wird sehr oft deutlich, dass der Ausgangspunkt aller Misserfolge die falsche Vorstellung ist, dass mit der Einführung eines automatisierten Systems alle internen Probleme im Unternehmen gelöst werden. Infolgedessen rückte die Softwareentwicklung in den Vordergrund, um das bestehende Durcheinander zu automatisieren. Die Managementprozesse blieben trotz aller Automatisierung im Wesentlichen gleich.

Tatsächlich ist der Hauptgrund für diese Probleme das Fehlen klarer und bewährter Geschäftsprozesse, die den reibungslosen Betrieb aller Unternehmensbereiche regeln.

Grundsätzlich ist es wichtig und sogar notwendig, Geschäftsprozesse bei der Implementierung zu zerlegen automatisierte Systeme Auf Unternehmensebene wird diesem Thema schon seit langem Beachtung geschenkt, doch gerade bei SOA ist dies eines der Grundprinzipien.

Geringe Kopplung

Geringe Kopplung ist ein wichtiges Architekturprinzip bei der Entwicklung von SOA-Systemen. Mit diesem Prinzip ist es möglich, verschiedene Komponenten eines Informationssystems im laufenden Betrieb über das sogenannte Late-Binding zu verbinden.

Mit dieser Funktion können auch Änderungen an der Funktionalität von Diensten wesentlich einfacher vorgenommen werden, da andere Dienste überhaupt nicht beeinträchtigt werden.

Eine niedrige Kopplung macht es viel einfacher Schritt-für-Schritt-Erstellung Unternehmenssystem, da keine Hindernisse für die Implementierung der Funktionalität des Dienstes über mehrere Iterationen hinweg bestehen.

Die Fähigkeit zur dynamischen Anbindung neuer Dienste sowie die Suche nach diesen Diensten durch Clients ist ebenfalls eines der Grundprinzipien eines Systems, das auf der Grundlage einer serviceorientierten Architektur aufgebaut ist.

Ein Beispiel für ein auf SOA basierendes Informationssystem

In diesem Teil betrachten wir ein Informationssystem eines bestimmten Unternehmens, das auf SOA-Basis aufgebaut ist. Bisher wurde bei der Beschreibung serviceorientierter Technologie nicht erwähnt, auf welchen Technologien Systeme aufgebaut werden können, und das ist durchaus berechtigt, da es sich bei SOA, wie bereits erwähnt, um einen neuen Ansatz zum Aufbau von Unternehmensinformationssystemen handelt.

Es ist jedoch wahrscheinlich sinnvoll, darüber nachzudenken, aus welchen Komponenten ein ideales gemitteltes SOA-System bestehen könnte. Viele der im Folgenden aufgeführten Komponenten sind so wichtig und umfangreich, dass sie möglicherweise Gegenstand einer gesonderten Diskussion sind. Diese Komponenten dienen hier jedoch nur der allgemeinen Information.

Die Hauptkomponenten (in Abbildung 1 dargestellt) sind also der Enterprise Service Bus (ESB), die SOA-Registrierung, die Workflow-Engine, der Service Broker und der SOA-Supervisor. Sie alle spielen ihre eigene Rolle im System und interagieren miteinander andere.

Bild 1.

Enterprise Service Bus (ESB):

In einer serviceorientierten Architektur kommunizieren alle verschiedenen Softwareteile miteinander und senden sich normalerweise gegenseitig eine Menge Nachrichten. Diese Nachrichten müssen schnell zugestellt werden und die Zustellung muss gewährleistet sein.

Um Nachrichten an SOA zu übertragen, wird typischerweise ein Enterprise Service Bus (ESB) verwendet. Der Service Bus ist in SOA so wichtig, dass man sich vorstellen kann, dass eine serviceorientierte Architektur ohne ihn nicht existieren kann und umgekehrt seine Anwesenheit eine ausreichende Voraussetzung für SOA ist. Tatsächlich ist es möglich, ein System auf Basis einer serviceorientierten Architektur ohne Verwendung eines Servicebusses aufzubauen, und sein Vorhandensein garantiert nicht die Positionierung des Systems als SOA.

Der Enterprise Service Bus kann als separate Softwareschicht dargestellt werden, die zusammen mit dem Unternehmensnetzwerk einen garantierten Dienst zum Senden und Empfangen von Nachrichten bereitstellt, die von allen anderen Teilen des Unternehmenssystems gesendet werden.

SOA-Registrierung:

Die SOA-Registrierung ist eine Art elektronischer Katalog, der Informationen über jede Komponente eines Unternehmensinformationssystems sowie über die Schnittstellen speichert, über die diese Komponenten miteinander kommunizieren.

In einer SOA-Betriebsumgebung stellt die Registry den Clients Informationen über die aktuell zur Nutzung verfügbaren Dienste bereit (was besonders wichtig für den Service Broker ist).

Für Softwareentwickler und Geschäftsanalysten ist die SOA-Registrierung eine Informationsquelle, die ihnen hilft, vorhandene Komponenten auszuwählen und zu verbinden, um neue Anwendungen zu erstellen und neue Prozesse aufzubauen.

Die SOA-Registrierung speichert auch die Informationen jeder Komponente.

Workflow-Engine:

Jedes Unternehmen hat seinen eigenen Arbeitsablauf, der im Einzelfall zufällig oder formal beschrieben ist, wie von selbst entsteht oder das Ergebnis sorgfältiger Analyse und Automatisierung ist.

Workflow Engine ist ein Softwareprodukt, das es Ihnen ermöglicht, den gesamten Geschäftsprozess vom Anfang bis zum Abschluss in einem Unternehmensinformationssystem zu verbinden, ein System zur Reproduktion des Arbeitsablaufs nach einem bestehenden Modell.

Gleichzeitig erfolgt die Datenverarbeitung in den einzelnen Phasen in verschiedenen voneinander unabhängigen Anwendungen und die Funktionen der Prozessorganisation und Anbindung verschiedener Subsysteme werden durch ein spezialisiertes Workflow-System umgesetzt.

Produkte, die Geschäftsprozesse modellieren, gab es schon lange vor SOA, und es gibt eine Vielzahl von Angeboten verschiedener Anbieter, die oft auf unterschiedliche Bereiche spezialisiert sind. Vor etwa 15 Jahren standen die meisten dieser Systeme im Zusammenhang mit Dokumentenmanagementsystemen. Mittlerweile orientieren sich Anbieter dieser Systeme zunehmend an Geschäftsprozessmanagementsystemen und Verwaltungsvorschriften (Geschäftsprozessmanagementsystem oder einfach BPM).

Servicemakler:

Ein Service Broker ist ein Dienst, der verschiedene Dienste miteinander verbindet. Alle notwendigen Informationen erhält es von der SOA Registry, was bedeutet, dass die Registry und der Broker koordiniert zusammenarbeiten müssen.



Figur 2.

Abbildung 2 zeigt, wie in einem bestimmten SOA-System ein Service Broker die Auftragsabwicklung organisiert. Das Schema umfasst nur 4 Geschäftsdienste und eine Workflow-Engine.

Die Pfeile stellen die Aktionen des Service Brokers dar, die dicken Linien stellen den Fluss der Anfragen dar.

Die Abfolge der Aktionen könnte wie folgt aussehen:

1. Der Benutzer meldet sich an und fordert den Bestellabwicklungsdienst an. Da dieser Dienst noch nicht gestartet ist, erhält der Service Broker eine entsprechende Benachrichtigung und beginnt mit seiner Arbeit
2. Der Service-Broker fragt den Registrierungs-COA, was zum Starten des Auftragsverarbeitungsdienstes erforderlich ist und ob es zu diesem Zeitpunkt möglich ist, ihn zu starten
3. Der Service Broker prüft, ob die 4 Business Services, die für den Auftragsabwicklungsdienst erforderlich sind, ausgeführt werden, und startet diese, falls noch nicht geschehen.
4. Basierend auf der von der Registry erhaltenen SOA prüft der Service Broker die Schnittstellen zwischen Geschäftskomponenten. Diese Komponenten können dann für die Auftragsabwicklung miteinander verbunden werden.
5. Der Service Broker benachrichtigt die Geschäftskomponenten, dass sie die Workflow-Engine kontaktieren müssen, um den erforderlichen Dienst auszuführen, und der Geschäftsprozess beginnt mit der Ausführung.

Einige ESB-Implementierungen (Enterprise Service Bus) fungieren auch als Service-Broker.

SOA-Betreuer:

Der SOA-Supervisor ist sozusagen der wichtigste Servicedienst, der während des gesamten Systembetriebs fungiert und die Arbeit aller anderen, vor allem Servicedienste, überwacht und koordiniert.

Eine der Hauptaufgaben des SOA-Supervisors besteht darin, den Betrieb verschiedener Komponenten innerhalb des SOA-Systems zu überwachen, die Richtigkeit ihrer Funktionsweise zu bewerten und auch an externe Systeme gesendete Anfragen zu überwachen.

Es ist schwierig, die Bedeutung dieser Komponente zu überschätzen.

Es ist kein Geheimnis, dass es zum Erreichen eines bestimmten Leistungsniveaus viel einfacher ist, auf das Prinzip der geringen Kopplung zu verzichten, da seine Umsetzung dazu führt, dass eine bestimmte Infrastruktur geschaffen werden muss, was zweifellos Auswirkungen auf die Geschwindigkeit hat Ausführung.

Daher ist bei der Umsetzung des SOA-Prinzips eine Art Überwachungskomponente erforderlich, die bei auftretenden Problemen bei der Ausführung rechtzeitig benachrichtigt wird, um rechtzeitig Maßnahmen ergreifen zu können und den Kunden weiterhin ein ausreichendes Niveau zur Verfügung zu stellen Nutzungsbedingungen, Geschäftsbedingungen.