Zumindest können die Datenstrukturen als Schema (XSD) in allgegenwärtigem XML beschrieben werden. Darüber hinaus ist, gerade zur Klarstellung der Semantik, textuelle Dokumentation – zum Beispiel in Form von Wikis – viel wichtiger als formale Register. Zur Laufzeit wohnen die Komponenten in Service Containern – J2EE Application Server (z. B. JBoss) bieten dazu viel Komfort. Je nach Anwendungsfeld machen auch leichtgewichtigere Alternativen Sinn.

Theoretisch kann das Aufbrechen monolithischer Anwendungen in Komponenten dazu führen, dass die „Make-or-buy Entscheidungen“ nun auf Komponentenebene getroffen werden. So verkündet SAP beispielsweise auf einer letztjährigen JAX Keynote das „versöhnliche Nebeneinander von SAP und Eigenbau dank SOA“. Man darf gespannt sein, wie das in der Praxis aussieht.

Im Konzert

Komplexe Landschaften, zerlegt in Komponenten und Geschäftsprozesse, erfordern wiederum Integration der Bauelemente und die Kommunikation zwischen ihnen. Das ist so gesehen die Kehrseite der Modularisierung und erhöht die Komplexität des Gesamtsystems. Je loser die Kopplung, desto komplizierter gestaltet sich das Zusammenwirken, spätestens dann, wenn nicht nur der Gutfall Betrachtung findet. EAI Lösungen in Form von „Integration Backbones“ mildern das Problem, sollten aber kein Selbstzweck einer SOA Initiative sein. Insbesondere ist es wünschenswert, die Abhängigkeiten Ihrer Services und Komponenten von der Middleware zu minimieren. Dazu gibt es im Wesentlichen zwei Ansätze, so genannte „Invocation Frameworks“ (z. B. WSIF [4] ) und Generatoren, die den Kleber zwischen fachlicher Logik und technischem Kommunikationsmechanismus automatisch erzeugen.

Ein mittlerweile aufgeklärtes Missverständnis ist, dass SOA WebServices, also SOAP über HTTP, erfordere. Das ist nicht so. WebServices ist für Kommunikation über Unternehmensgrenzen hinweg (B2B) meistens die richtige Wahl, innerhalb von Unternehmen in der Regel nicht. Die Firma Danet verwendet dazu drei verschiedene Lösungsmuster: RMI/IIOP für enge Kopplungen zwischen Java Komponenten, XML über JMS für asynchrone, lose Kopplungen und WebServices für externe (B2B) Interfaces. Dabei wurde die Erfahrung gemacht, dass verfügbare Open-Source-Infrastruktur (z. B. Axis, ActiveAQ, JBoss Messaging, Xerces) sehr gut anwendbar ist. Eigenentwicklungen auf dieser Ebene sind für Dienstleister und Lösungshersteller normalerweise nicht sinnvoll. Auf der anderen Seite sind Abhängigkeiten von kommerziellen SOA und EAI Produkten eher hinderlich. In der Praxis wählen große Kunden Integrationsplattformen selbst aus und lassen Dienstleistern kaum Freiraum, während kleinere Kunden die Lizenzkosten kommerzieller Middleware nicht tragen können.