Das Thema ist heiß. Kaum ein Tag vergeht, an dem nicht irgendein Artikel oder eine News zum Thema „Service-orientierte Architektur“, kurz SOA, in den Medien erscheint. Aus dem Kontext dieser Meldungen und Berichte geht jedoch selten hervor, um was es sich dabei genau handelt. Bestenfalls erfährt man was es nicht ist. „SOA ist kein Produkt, sondern eine Strategie, die mit viel Beratungsleistung verbunden ist“, sagt Accenture-Chef Bill Green. Derzeit sei der Accenture-Umsatz mit SOA noch „relativ gering“, aber für die nächsten 18 Monate erwartet Green ein „signifikantes Wachstum“ auf diesem Gebiet. Wobei der größte Teil dieses Service vermutlich schon die Erklärung des Begriffs ausmachen wird.

SOA ist in der Tat kein Produkt, keine Technologie, keine Norm und auch kein Patent, sondern vielmehr eine mehr oder minder wahlfreie Methode, mit der sich umfangreiche Unternehmensanwendungen sehr flexibel konzipieren lassen – zumindest theoretisch. Denn der Teufel steckt auch hier – wie so häufig – im Detail.

Ganz allgemein gesagt, geht es bei SOA um eine modulare Kombination von Teilen eines einzelnen oder von mehreren Anwendungs-Programmen. So stellt beispielsweise die Integration von Applikationen verschiedener Anbieter in eine geschlossene Lösung alle Beteiligten vor große Probleme. Derartige Integrationsbemühungen verlangen gründliche Fachkenntnisse bezüglich der vorhandenen Programmierschnittstellen (Application Programming Interface – API) sowie zahlreiche eins-zu-eins Integrationen zwischen jedem einzelnen System. Damit werden aber viel-zu-viel Integrationspunkte geschaffen, als dass diese auf Dauer effektiv betrieben oder in Stand gehalten werden können.

Als Antwort darauf wurde bereits vor Jahren Unified-Application-Integration (UAI) beziehungsweise Enterprise-Application-Integration (EAI) entwickelt, um durch die Schaffung einer gemeinsamen Zwischenebene die Integration verschiedener Systeme zu vereinfachen und die Integrationen besser zu verwalten.

Während die Integration von einzelnen Systemkomponenten damit wesentlich vereinfacht wurde, war nach wie vor ein komplexer Integrationscode nötig, um die verschiedenen Systeme in einer einzigen effektiven Unternehmenslösung zu vereinen. Denn auch wenn UAI die Gesamtarchitektur vereinfachte, so blieb es weiterhin sehr aufwändig und kompliziert, diese zu erstellen und fortlaufend anzupassen. Genau genommen wurde das Chaos dadurch nicht beseitigt, sondern nur gebündelt und verlagert. Genauso, als wenn man alles Herumliegende in eine große Box wirft und den Deckel zu macht - das sieht dann nur auf den ersten Blick aufgeräumt aus.

SOA verfolgt dagegen einen anderen Ansatz. Statt die detaillierten Funktionen von jedem API zu beherrschen, konzentrieren sich die SOA-Entwickler darauf, unterschiedliche System-Funktionen als so genannte „Services“ bereitzustellen. Entwickler die eine neue Anwendung erstellen, können sich damit auf ihre eigentliche Aufgabe konzentrieren, nämlich an der Schaffung von etwas Neuem zu arbeiten. Alle bereits bestehende Funktionen müssen nicht neu geschaffen werden, sondern können als Services abgerufen werden.

Es gibt keinen Bedarf mehr dafür, sich in unnötige Programmier-Arbeiten und -Kenntnisse zu verstricken. Denn indem standardisierte Datenformate und Kommunikationsprotokolle benutzt werden, sind viele Hindernisse für eine schnelle und wirksame Integration von disparaten Systemen von vornherein aus dem Weg geräumt.

Statt also vom detaillierten Verständnis der APIs jedes einzelnen Systems sowie von den EAI-Schichten abhängig zu sein, beruht SOA auf einer einfachen Interoperabilität, mit dem der Fokus auf der Nutzung eines Service statt auf dessen Erstellung ausgerichtet ist.

Ein einfaches Beispiel hierfür ist ein dezentralisiertes Lohn- und Gehaltsystem. Statt von jeder Business-Unit zu verlangen, die komplexen gesetzlichen und tariflichen Vorgaben zur Berechnung der Lohnabzüge zu kennen, benötigen diese Services lediglich grundlegende Informationen über den Arbeitnehmer, um daraus die Vergütung und die Abzüge zu ermitteln. Hierzu ist es nicht erforderlich zu wissen, auf welcher Plattform dieser Service läuft oder um was für eine Software es sich im Einzelnen handelt.

Und ein weiterer ganz entscheidender Vorteil eines solchen Services ist, dass er über konventionelle Kommunikations-Standards genutzt werden kann, sodass sich die einzelnen Services über den ganzen Globus verteilen lassen. Damit lassen sich weit auseinander liegende Geschäftsbereiche oder auch Partner und Outsourcing-Firmen effizient in die gesamte Anwendung einbinden.

Durch die Anwendung von normalen Internetprotokollen wie HTTP besteht darüber hinaus die Möglichkeit einer integrierten Nutzung von Services außerhalb eines einzelnen Unternehmens, so wie sie beispielsweise von verschiedenen „Software-as-a-Service“ (SaaS) Anbietern bereits bereit gestellt werden.

Um mit dem oben erwähnten Lohnabrechnungs-Beispiel fortzufahren: Dieser Service kann jederzeit ohne Umstände ausgelagert werden, ohne dass davon Änderungen an den vielen internen Programmen der Abteilungen erforderlich sind, die diesen Service nutzen. Vom Unternehmen selbst müssen dazu nur separat die erforderlichen Basisinformationen, wie Steuernummer, Finanzamt und Ähnliches bereitgestellt werden.

SOA hilft auch die Implementierungs- und Wartungskosten von integrierten Systemen zu reduzieren. Da bei der Integration der Fokus auf die Ergebnisse des Systems und nicht auf die Systemschnittstellen gerichtet wird, ist die Integration nicht durch Implementationsdetails beschränkt. Diese Art „Leichtbau-Integration“ ermöglicht es jeder Fachabteilung ihre Systeme unabhängig voneinander auf den neuesten Stand zu bringen. Als Einschränkung gilt nur, dass der Informations-Austausch unangetastet bleiben muss.

Für diese Integration der Services gibt es bereits allgemein gebräuchliche Methoden und Werkzeuge, mit denen die Anwendungsentwickler ihre Applikationen als Services auslegen können und mit deren Hilfe sie andere Systeme aufrufen können.

Im Wesentlichen handelt es sich dabei um die Extensible Markup Language (XML) und dem Simple Object Access Protocol (SOAP). XML ist eine quer durchs Internet für Kommunikation und Datenaustausch standardmäßig genutzte und textbasierte Plattform. Es handelt sich dabei um eine formale Spezifikation des World Wide Web Konsortium (W3C) und ist darüber hinaus zum universalen Format für strukturierte Dokumente und Daten geworden. SOAP ist ein Netzwerkprotokoll, das es ermöglicht, mittels XML-Botschaften zu kommunizieren. SOAP-Mitteilungen sind unabhängig vom Betriebssystemen und der jeweiligen Plattform und sie werden durch Standard-Internetprotokolle, meist HTTP, transportiert.

Insgesamt also bietet SOA viele Vorzüge und entsprechend hoch sind die Erwartungen und Planungen. Immer mehr Unternehmen und Abteilungen planen oder realisieren bereits SOA-Strategien. In einer Forrester-Untersuchung gaben 59 Prozent der befragten Unternehmen an, bereits SOA in Teilbereichen im Einsatz haben und weitere 17 Prozent verfügen zumindest über eine SOA-Strategie auf Unternehmensebene. Über zwei Drittel dieser Firmen (69 Prozent) sagen, dass sie die Verwendung von SOA in den nächsten zwei Jahren ausbauen werden. Keines der befragten Unternehmen will die Nutzung reduzieren.

Am häufigsten finden sich SOA-Anwendungen bei den 2000 weltgrößten Unternehmen, welche am ehesten eine entsprechende Strategie auf Unternehmensebene verfolgen. Von den befragten Firmen mit mehr als 2000 Angestellten, haben 26 Prozent nach eigener Auskunft bereits unternehmensweite Initiativen rund um SOA gestartet.

Als Hauptmotiv geben fast alle an, dass SOA die Benutzung von mehr standardisierter Technologie erlaubt und dass der zu entwickelnde und zu pflegende Source-Code wesentlich geringer ist. Was nach Ansicht von deren CIOs eine kostengünstigere Pflege und Wartung bedeutet. Doch diese euphorischen Zahlen überraschen ein wenig, denn SOA an sich ist kein Standard, keine Norm und somit sind auch die Schnittstellen der einzelnen Services nicht ohne weiteres kompatibel.

Um nochmals auf das Gehaltsbeispiel einzugehen: Natürlich muss irgendwo klar festgelegt sein, wie die Daten eines Mitarbeiters übergeben werden, wie der Übergabesatz aufgebaut sein muss und wie sich der Ergebnissatz zusammen setzt – das aber ist nirgendwo standardisiert. Und folglich beginnt an diesem Punkt auch die Konfusion, die es über den Begriff der „offenen“ Integration von SOA-Modulen gibt, vor allem wenn es um den Austausch mit Fremdsystemen oder um die Integration mit externen Dienstleistern geht. In diese Problem-Kategorie gehört auch der viel diskutierte Punkt der „Atomisierung“ von Services, das heißt, wie weit zerlegt man einen komplexen Service? Je kleiner er ist, umso flexibler lassen sich neue Strukturen schaffen, andererseits steigt damit wieder der Aufwand bei der Entwicklung und der Wartung an, und letztlich kann es auch zu Performance-Problemen kommen. Denn eines ist ganz klar, SOA verschlingt viel Rechenleistung zugunsten der gewünschten Flexibilität. Hochperformante, mission-critical Applikationen sind nur dann ein Tummelplatz für SOA-Entwickler, wenn der zugehörige Hardware- und Datenbankaufwand keine Rolle spielt.