Was ist eine serviceorientierte Architektur (SOA)?

SOA entlastet den Entwickler der Anwendung, der zuvor bestehende Funktionen neu entwickelte oder duplizierte oder wissen musste, wie man bestehende Funktionen verbindet oder Interoperabilität mit ihnen herstellt.

Jeder Service in einer SOA verkörpert den Code und die Daten, die für die Ausführung einer vollständigen, diskreten Geschäftsfunktion erforderlich sind (z. B. die Prüfung der Kreditwürdigkeit eines Kunden, die Berechnung einer monatlichen Kreditrate oder die Bearbeitung eines Hypothekenantrags). Die Serviceschnittstellen bieten eine lose Kopplung. Das bedeutet, dass sie mit wenig oder gar keiner Kenntnis über die Art und Weise der Implementierung des darunter liegenden Service aufgerufen werden können, was die Abhängigkeiten zwischen den Anwendungen reduziert.

Diese Schnittstelle ist ein Servicevertrag zwischen dem Serviceanbieter und dem Servicenutzer. Anwendungen hinter der Serviceschnittstelle können in Java, Microsoft .Net, Cobol oder einer anderen Programmiersprache geschrieben werden, die für Unternehmen als Paketanwendungen von einem Anbieter (z. B. SAP), SaaS-Anwendungen (z. B. Salesforce CRM) oder als Open-Source-Anwendungen bereitgestellt werden.

Service-Schnittstellen werden häufig anhand der Web Service Definition Language (WSDL) definiert, einer standardmäßigen Tag-Struktur, die auf XML (Extensible Markup Language) basiert.

Die Dienste werden verfügbar gemacht, indem Standardnetzwerkprotokolle  – wie das Simple Object Access Protocol (SOAP)/HTTP oder Restful HTTP (JSON/HTTP) – verwendet werden, um Anforderungen zum Lesen oder Ändern von Daten zu senden. Die Service-Governance steuert den Lebenszyklus für die Entwicklung, und in der entsprechenden Phase werden die Services in einer Registrierung  veröffentlicht. Dadurch können Entwicklungsteams sie schnell finden und wiederverwenden, um neue Anwendungen oder Geschäftsprozesse zusammenzustellen.

Diese Services können völlig neu aufgebaut werden, werden jedoch häufig durch die Bereitstellung von Funktionen aus Altlast-Aufzeichnungssystemen als Serviceschnittstellen erstellt.

Auf diese Weise stellt SOA eine wichtige Phase in der Entwicklung von Anwendung und Integration in den letzten Jahrzehnten dar. Bevor SOA in den späten 1990er Jahren aufkam, erforderte die Verbindung einer Anwendung mit Daten oder Funktionen, die in einem anderen System untergebracht waren, eine komplexe Point-to-Point-Integration – eine Integration, die Entwickler für jedes neue Entwicklungsprojekt ganz oder teilweise neu erstellen mussten. Die Bereitstellung dieser Funktionen über SOA-Services ermöglichte es dem Entwickler, die vorhandene Funktion einfach wiederzuverwenden und über die SOA-ESB-Architektur eine Verbindung herzustellen (siehe unten).

Obwohl SOA und die neuere Microservice-Architektur viele Wörter gemeinsam haben (z. B. „Service“ und „Architektur“), sind sie nur lose miteinander verwandt und arbeiten in der Tat in unterschiedlichen Bereichen, wie später in diesem Artikel erläutert wird.

Ein ESB (Enterprise Service Bus) ist ein Architekturmuster, bei dem eine zentralisierte Softwarekomponente die Integration zwischen Anwendungen durchführt. Ein ESB führt Transformationen von Datenmodellen durch, verwaltet Konnektivität und Messaging, führt Routing durch, konvertiert Kommunikationsprotokolle und verwaltet gegebenenfalls die Zusammenstellung mehrerer Anfragen.

Der ESB kann diese Integrationen und Transformationen als Serviceschnittstelle zur Wiederverwendung durch neue Anwendungen bereitstellen. Das ESB-Muster wird in der Regel mithilfe einer speziell entwickelten Integrationslaufzeitumgebung und einem Toolset implementiert, die eine optimale Produktivität gewährleisten.

Eine SOA kann auch ohne ESB-Architektur implementiert werden, das würde jedoch einfach nur eine Ansammlung von Services bedeuten. Jeder Anwendungseigner müsste eine direkte Verbindung zu jedem benötigten Service herstellen und die erforderlichen Datentransformationen für jede Serviceschnittstelle durchführen.

Dies ist eine Menge Arbeit (selbst wenn die Schnittstellen wiederverwendbar sind) und schafft eine ernsthafte Herausforderung für die zukünftige Wartung, da jede Verbindung Punkt-zu-Punkt ist. Tatsächlich wurden ESBs schließlich als ein so tatsächliches Element jeder SOA-Implementierung angesehen, dass die beiden Begriffe manchmal als Synonyme verwendet werden, was zu Verwirrung führt.

Im Vergleich zu den vorangegangenen Architekturen bot SOA dem Unternehmen erhebliche Nutzen:

• Größere geschäftliche Flexibilität; schnellere Markteinführung: Wiederverwendbarkeit ist der Schlüssel. Die Effizienz, mit der Anwendungen aus wiederverwendbaren Diensten – also Bausteinen – zusammengestellt werden, anstatt sie bei jedem neuen Entwicklungsprojekt neu zu schreiben und zu reintegrieren, ermöglicht es Entwicklern, viel schneller auf neue Geschäftschancen zu reagieren.
  Der serviceorientierte architektonische Ansatz unterstützt Szenarien für die Anwendungsintegration, die Datenintegration und die Automatisierung von Geschäftsprozessen oder Workflows im Stil der Orchestrierung. Dies beschleunigt das Softwaredesign und die Softwareentwicklung, da die Entwickler deutlich weniger Zeit für die Integration aufwenden müssen und sich mehr auf die Bereitstellung und Verbesserung ihrer Anwendungen konzentrieren können.
• Die Möglichkeit, Altlast-Funktionen in neuen Märkten zu nutzen: Eine gut durchdachte SOA ermöglicht es Entwicklern, Funktionen, die in einer Computerplattform oder -umgebung „eingesperrt“ sind, einfach auf neue Umgebungen und Märkte zu übertragen. Viele Unternehmen haben SOA beispielsweise genutzt, um Funktionen von Mainframe-basierten Finanzsystemen für neue Anwendungen verfügbar zu machen. Auf diese Weise können Kunden Prozesse und Informationen selbst nutzen, die zuvor nur durch direkte Interaktion mit Mitarbeitern oder Geschäftspartnern des Unternehmens zugänglich waren.
• Verbesserte Zusammenarbeit zwischen Unternehmen und IT: In einer SOA können Dienstleistungen in Geschäftsbegriffen definiert werden (zum Beispiel „Versicherungsangebot erstellen“ oder „ROI für Equipment berechnen“). Dies ermöglicht es Business-Analysten, effektiver mit Entwicklern an wichtigen Erkenntnissen zu arbeiten – wie etwa dem Umfang eines Geschäftsprozesses, der durch die Nutzung von Diensten definiert wird, oder den geschäftlichen Auswirkungen einer Prozessänderung –, die zu einem besseren Ergebnis führen können.

Bis zum Jahr 2010 liefen die SOA-Implementierungen bei führenden Unternehmen in praktisch allen Branchen auf vollen Touren. Ein Beispiel:

Delaware Electric wandte sich an SOA, um Systeme zu integrieren, die zuvor nicht miteinander kommunizierten. Dies führte zu einer effizienteren Entwicklung, die dem Unternehmen half, während eines fünfjährigen, staatlich verordneten Einfrierens der Stromtarife zahlungsfähig zu bleiben.

Cisco führte SOA ein, um sicherzustellen, dass die Produktbestellererfahrung über alle Produkte und Kanäle hinweg konsistent ist, indem Bestellprozesse als Services verfügbar gemacht werden, die die Geschäftsbereiche, Akquisitionen und Geschäftspartner von Cisco in ihre Websites

integrieren können. Independence Blue Cross (IBC) in Philadelphia implementierte eine SOA, um sicherzustellen, dass die verschiedenen Beteiligten, die mit Patientendaten umgehen – IBC-Kundendienstmitarbeiter, Arztpraxen, Nutzer von IBC- Websites – mit derselben Datenquelle (einer Single-Source-of-Truth (SSOT)) arbeiten.

Experten haben ein paar tausend gedruckte und digitale Seiten gefüllt, um SOA und Microservices zu vergleichen und die Feinheiten ihrer Beziehung zueinander definiert. Für die Zwecke dieses Artikels bestehen die Hauptunterschiede zwischen den beiden in der Kopplung der Komponenten und des Umfangs der Integration:

SOA ist ein Architekturstil der Integration und ein unternehmensweites Konzept. Sie ermöglicht es, bestehende Anwendungen über lose gekoppelte Schnittstellen offenzulegen, die jeweils einer Geschäftsfunktion entsprechen, die es Anwendungen in einem Teil eines erweiterten Unternehmens ermöglicht, Funktionen in anderen Anwendungen wiederzuverwenden.

Die Microservices-Architektur ist ein Architekturstil für Anwendungen und ein auf die Anwendung bezogenes Konzept. Sie ermöglicht, die Interna einer einzelnen Anwendung in kleine Teile aufzuteilen, die unabhängig voneinander geändert, skaliert und verwaltet werden können. Sie definiert nicht, wie Anwendungen miteinander kommunizieren, sodass wir uns wieder auf den Unternehmensbereich der von SOA bereitgestellten Serviceschnittstellen verlassen.

Microservices sind mit dem Aufkommen von Virtualisierung, Cloud-Computing, Praktiken zur agilen Entwicklung und DevOps entstanden und haben seither zunehmend an Bedeutung gewonnen. Die meisten Vorteile von Microservices in diesen Kontexten ergeben sich aus der Entkopplung der Komponenten, die Folgendes vereinfacht und verbessert:

• Agilität und Produktivität der Entwickler: Microservices ermöglichen es Entwicklern, neue Technologien in einen Teil der Anwendung zu integrieren, ohne den Rest der Anwendung zu beeinträchtigen. Jede Komponente kann unabhängig von den anderen geändert, getestet und bereitgestellt werden, was die Iterationszyklen beschleunigt.
• Skalierbarkeit: Microservices können die Vorteile der Cloud-Skalierbarkeit maximieren. Jede Komponente kann unabhängig von den anderen skaliert werden, um schnellstmöglich auf Workload-Anforderungen zu reagieren und die Ressourcen möglichst effizient zu nutzen.
• Resilienz: Auch hier hat der Ausfall eines Microservices dank der Entkopplung keine Auswirkungen auf die anderen. Und jeder Microservice kann seine eigenen Verfügbarkeitsanforderungen erfüllen, ohne die anderen Komponenten oder die gesamte Anwendung an die größten allgemeinen Verfügbarkeitsanforderungen anzupassen.

Weitere Informationen zu den Unterschieden zwischen SOA und Microservices finden Sie unter SOA im Vergleich zu Microservices: Was ist der Unterschied?

So wie die Microservices-Architektur das Potenzial hat, die Agilität, Skalierbarkeit und Ausfallsicherheit der Anwendung zu verbessern, können dieselben Techniken auch auf die Integration angewendet werden.

Dies ist wichtig, da das stark zentralisierte ESB-Muster und das damit verbundene zentralisierte Team von Integrationspezialisten im Laufe der Zeit zu Engpässen werden können. In Anlehnung an die Prinzipien von Microservices können wir den ESB potenziell in eine differenziertere, dezentrale Integration aufteilen. Dies ist eine der Kernprämissen der agilen Integration.