SOA, oder serviceorientierte Architektur, definiert eine Möglichkeit, Softwarekomponenten über  Serviceschnittstellen wiederverwendbar und interoperabel zu machen. Services verwenden gemeinsame Schnittstellenstandards und ein Architekturmuster, sodass sie schnell in neue Anwendungen integriert werden können.  Dadurch wird der Anwendungsentwickler von Aufgaben entlastet, die er zuvor neu entwickeln oder bestehende Funktionen duplizieren musste, oder er musste wissen, wie er eine Verbindung oder Interoperabilität mit bestehenden Funktionen herstellen kann.

Jeder Service in einer SOA enthält den Code und die Daten, die zur Ausführung einer vollständigen, diskreten Geschäftsfunktion erforderlich sind (z. B. Prüfung der Kreditwürdigkeit eines Kunden, Berechnung einer monatlichen Kreditrate oder Bearbeitung eines Hypothekenantrags). Die Serviceschnittstellen bieten eine lose Kopplung, d. h. sie können mit wenig oder gar keinem Wissen darüber aufgerufen werden, wie der Service darunter implementiert ist, wodurch die Abhängigkeiten zwischen den Anwendungen verringert werden. 

Diese Benutzerschnittstelle ist ein Servicevertrag zwischen dem Serviceanbieter und dem Servicekonsument. Anwendungen hinter der Serviceschnittstelle können in Java, Microsoft, Net, Cobol oder anderen Programmiersprachen geschrieben werden und werden durch einen Anbieter (z. B. SAP), SaaS-Anwendungen (z. B. Salesforce CRM) als gepackte Softwareanwendungen bereitgestellt oder als Open-Source-Anwendungen bezogen.  Serviceschnittstellen werden häufig mithilfe der Web-Service Definition Language (WSDL) definiert, einer Standard-Tag-Struktur auf der Grundlage von XML (Extensible Markup Language).  

Die Services werden über Standard-Netzprotokolle wie SOAP (Simple Object Access Protocol)/HTTP oder Restful HTTP (JSON/HTTP) bereitgestellt, um Anfragen zum Lesen oder Ändern von Daten zu senden. Die Service-Governance steuert den Lebenszyklus der Entwicklung, und in der entsprechenden Phase werden die Services in einer Registry veröffentlicht, die es den Entwicklern ermöglicht, sie schnell zu finden und für die Zusammenstellung neuer Anwendungen oder Geschäftsprozesse erneut zu nutzen.

Diese Services können von Grund auf neu erstellt werden, werden jedoch häufig durch die Bereitstellung von Funktionen aus traditionellen Systemen des Datensatzes als Serviceschnittstellen erstellt.

Auf diese Weise stellt SOA einen wichtigen Schritt in der Evolution der Anwendungsentwicklung und -integration der letzten Jahrzehnte dar. Bevor SOA in den späten 1990er Jahren entstand, erforderte die Verbindung einer Anwendung mit Daten oder Funktionen, die in einem anderen System untergebracht waren, eine komplexe Punkt-zu-Punkt-Integration – eine Integration, die Entwickler bei jedem neuen Entwicklungsprojekt ganz oder teilweise neu erstellen mussten. Die Bereitstellung dieser Funktionen durch SOA-Services ermöglichte es dem Entwickler, einfach die vorhandenen Funktionen wiederzuverwenden und eine Verbindung über die SOA-ESB-Architekturherzustellen (siehe unten).

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

Ein ESB, oder Enterprise Service Bus, ist ein Architekturmuster, bei dem eine zentralisierte Softwarekomponente Integrationen zwischen Anwendungen durchführt.  Es führt Transformationen von Datenmodellen durch, verwaltet die Konnektivität/Nachrichtenübermittlung, führt das Routing durch, konvertiert Kommunikationsprotokolle und verwaltet möglicherweise die Zusammenstellung mehrerer Anfragen. Die ESB kann diese Integrationen und Transformationen als Serviceschnittstelle zur Wiederverwendung durch neue Anwendungen zur Verfügung stellen. Das ESB-Muster wird in der Regel mit einer speziell entwickelten Integrationslaufzeit und einem Toolset implementiert, das die bestmögliche Produktivität gewährleistet.

Es ist möglich, ein SOA ohne ein ESB zu implementieren, aber das wäre gleichbedeutend mit einem Bündel von Services.  Jeder Anwendungseigner müsste eine direkte Verbindung zu jedem von ihm benötigten Dienst herstellen und die erforderlichen Datentransformationen vornehmen, um jede der Serviceschnittstellen zu erfüllen. Dies ist eine Menge Arbeit (selbst wenn die Schnittstellen wiederverwendbar sind) und schafft ein erhebliches Wartungsproblem in der Zukunft, da jede Verbindung von Punkt zu Punkt geht.  Tatsächlich wurden ESBs schließlich als De-facto-Element jeder SOA-Implementierung angesehen, dass die beiden Begriffe manchmal synonym verwendet werden, was zu Verwirrung führt.

Weitere Informationen zu ESBs

Im Vergleich zu den Architekturen, die ihr vorausgingen, bietet SOA erhebliche Vorteile für Unternehmen:

• Effizientere Prozessabwicklung; kürzere Entwicklungszeit: Wiederverwendbarkeit  ist der entscheidende Faktor.  Die Effizienz der Zusammenstellung von Anwendungen aus wiederverwendbaren Services – d. h. durch die Erstellung von Blöcken, statt sie bei jedem neuen Entwicklungsprojekt neu zu schreiben und zu integrieren, können Entwickler Anwendungen viel schneller erstellen, um auf neue Geschäftsmöglichkeiten zu reagieren. Der serviceorientierte Architekturansatz unterstützt Szenarien für die Anwendungsintegration, die Datenintegration und die Automatisierung von Geschäftsprozessen oder Arbeitsabläufen im Stil von Servicekoordination.   Dies beschleunigt das Softwaredesign und die Softwareentwicklung, da die Entwickler deutlich weniger Zeit für die Integration aufwenden müssen und sich viel mehr auf die Bereitstellung und Verbesserung ihrer Anwendungen konzentrieren können. 
  
  
• Fähigkeit, traditionelle Funktionalität in neuen Märkten zu nutzen: Ein gut durchdachtes SOA ermöglicht es Entwicklern, die in einer Computerplattform oder -umgebung „eingeschlossene“ Funktionalität auf einfache Weise auf neue Umgebungen und Märkte auszuweiten. So haben viele Unternehmen SOA eingesetzt, um die Funktionalität von Mainframe-basierten Finanzsystemen auf neue Webanwendungen zu übertragen und ihren Kunden die Möglichkeit zu geben, Prozesse und Informationen zu nutzen, die zuvor nur durch direkte Interaktion mit den Mitarbeitern oder Geschäftspartnern des Unternehmens zugänglich waren.
  
  
• Verbesserte Zusammenarbeit zwischen Unternehmen und IT: In einem SOA können Services in geschäftlichen Begriffen definiert werden (z. B. „Versicherungsangebot erstellen“ oder „ROI für Investitionsgüter berechnen“). Auf diese Weise können Business-Analysten effektiver mit Entwicklern zusammenarbeiten, um wichtige Erkenntnisse zu gewinnen, z. B. über den Umfang eines mit Services definierten Geschäftsprozesses oder die geschäftlichen Auswirkungen einer Prozessänderung, die zu einem besseren Ergebnis führen können.

Bis 2010 liefen SOA-Implementierungen bei führenden Unternehmen in praktisch allen Branchen auf Hochtouren. Zum Beispiel:

• Delaware Electric ging zu SOA über, um Systeme zu integrieren, die zuvor nicht miteinander kommunizierten. Dies führte zu Effizienzsteigerungen in der Entwicklung, die dem Unternehmen halfen, während eines fünfjährigen, staatlich verordneten Einfrierens der Strompreise zahlungsfähig zu bleiben.
  
  
• Cisco führte SOA ein, um sicherzustellen, dass die Produktbestellung über alle Produkte und Kanäle hinweg konsistent ist, indem die Bestellprozesse als Services dargestellt werden, die die Abteilungen, Übernahmen und Geschäftspartner von Cisco in ihre Websites integrieren können.
  
  
• Independence Blue Cross (IBC) in Philadelphia führte SOA ein, um sicherzustellen, dass die verschiedenen Beteiligten, die mit Patientendaten zu tun haben – IBC-Kundendienstmitarbeiter, Arztpraxen, IBC-Website-Benutzer – mit derselben Datenquelle arbeiten (eine „Single Source of Truth“).

Experten haben einige tausend gedruckte und digitale Seiten damit gefüllt, SOA und Microservices zu vergleichen und die Feinheiten ihrer Beziehung zueinander zu definieren. Dieser Artikel geht auf die Hauptunterschiede zwischen beiden ein – die Kopplung von Komponenten und der Anwendungsbereich:

• SOA ist ein Integrationsarchitekturstil und ein unternehmensweites Konzept. Bestehende Anwendungen können über lose gekoppelte Schnittstellen, die jeweils einer Geschäftsfunktion entsprechen, offengelegt werden, sodass Anwendungen in einem Teil eines erweiterten Unternehmens in anderen Anwendungen die Funktionalität wiederverwenden können.
  
  
• Microservices-Architektur ist ein Anwendungsarchitekturstil und ein anwendungsspezifisches Konzept. Sie ermöglicht es, die Interna einer einzelnen Anwendung in kleine Teile zu zerlegen, die unabhängig voneinander geändert, skaliert und verwaltet werden können. Sie legt nicht fest, wie Anwendungen miteinander kommunizieren – damit wären wir wieder beim Unternehmensbereich der von der SOA bereitgestellten Serviceschnittstellen.

Die Microservices-Architektur ist mit dem Aufkommen von Virtualisierung, Cloud-Computing, agilen Entwicklungspraktiken und DevOps entstanden und hat an Bedeutung gewonnen. Die meisten Vorteile von Microservices in diesem Zusammenhang ergeben sich aus der Entkopplung der Komponenten, die Folgendes vereinfacht und verbessert:

• Agilität und Produktivität der Entwickler: Microservices ermöglichen es den Entwicklern, neue Technologien in einen Teil der Anwendung einzubinden, ohne den Rest der Anwendung zu beeinträchtigen. Jede Komponente kann unabhängig von den anderen geändert, getestet und implementiert werden, was die Iterationszyklen beschleunigt.
  
  
• Skalierbarkeit: Microservices können die Skalierbarkeit der Cloud maximal ausnutzen – jede Komponente kann unabhängig von den anderen skaliert werden, um schnellstmöglich auf Workload-Anforderungen zu reagieren und die Rechenressourcen möglichst effizient zu nutzen.
  
  
• Ausfallsicherheit: 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 gemeinsamen Verfügbarkeitsanforderungen zu binden.

Für einen tieferen Einblick in die Unterschiede zwischen SOA und Microservices siehe „SOA  vs.  Microservices: Was ist der Unterschied?“

Auf die gleiche Weise, wie die Microservices-Architektur das Potenzial hat, Verbesserungen in Bezug auf Agilität, Skalierbarkeit und Ausfallsicherheit für das Anwendungsdesign zu bringen, können dieselben Techniken auch auf die Integration angewendet werden. Dies ist wichtig, weil das stark zentralisierte ESB-Muster und das damit verbundene zentralisierte Team von Integrationsspezialisten mit der Zeit zu einem Engpass werden kann. In Anlehnung an Microservices-Prinzipien können wir den ESB potenziell in differenziertere, dezentralisierte Integrationen aufteilen. Dies ist eine der Grundvoraussetzungen für die agile Integration.