Was vielen unbekannt ist: Web-Services-Definitionen nach WSDL sind zunächst nicht an HTTP/Soap gebunden. WSDL trennt die Definition der Services von der technischen Bindung an ein Protokoll. Interessant wäre also ein Framework, das es erlaubt, einen Serviceaufruf zu formulieren und dabei die Details der Kommunikation generieren zu lassen. Ein solches Framework gibt es im Open-Source-Lager mit Apaches "WebService Invocation Framework" (WSIF). Neben dem ganzen SOA-Hype scheint WSIF kaum beachtet zu werden. Allerdings mehren sich die Hinweise, dass diese Ideen in aktuellen SOA-Standards (hier JBI/JSR-208) wieder aufgegriffen werden. Web-Services mit Soap über http sind also nur eines von mehreren denkbaren Übertragungsprotokollen und keineswegs die unvermeidbare Grundvoraussetzung für eine SOA - und oft nicht mal die beste Wahl (siehe Kasten: "Empfehlungen für die Web-Services-Kommunikation").

Kommunikationsmuster

Neben der Kommunikationstechnik (Protokoll) bringt auch das Kommunikationsmuster Abhängigkeiten mit sich. Der Code für einen synchronen (blockierenden) Service-Call unterscheidet sich von einem asynchronen (nicht blockierenden) Aufruf, bei dem die Antwort später eintrifft. Kann und will man diese Abhängigkeiten in der Geschäftslogik akzeptieren? Nachdem Einvernehmen darüber besteht, dass eine formale Servicebeschreibung (Signatur) nebst Festlegung der Semantik der Services und ihrer Parameter notwendig ist, wird sich hier ein weiterer Festlegungsbedarf in einer SOA ergeben. Ohne diese Vorgaben muss man sich darauf einstellen, dass alle Spielarten auch genutzt werden (synchron blockierend, asynchron mit und ohne Quittungen, Notifications mit und ohne Quittungen). Da sich prinzipiell alle Muster auf allen Kommunikationstypen implementieren lassen, obwohl die Grundidee des Protokolls gelegentlich eine andere ist, sind die Kommunikationsmuster im Vorfeld als Teil einer SOA abzustimmen.

Java Business Integration (JBI, JSR 208), eine Standardisierungsbemühung der Java-Gemeinde, deren Nutzen eher umstritten ist, hat immerhin erkannt, dass man diese Kommunikations-Patterns definieren muss, da sonst keine Interoperabilität gewährleistet werden kann. JBI definiert folgerichtig ein Profil der unterstützten Muster.

Neben dem Aspekt der Kommunikation und des Messaging wird im Kontext von SOA heftig über Geschäftsprozesse diskutiert: Die Fachabteilungen sollen durch SOA in die Lage versetzt werden, selbst und möglichst ohne Zutun der IT Geschäftsabläufe zu implementieren - selbstredend grafisch, ohne Programmierkenntnisse. So weit die Versprechen der Hersteller. Mag sein, dass dies in Zukunft Realität werden kann, zurzeit ist man jedoch eher geneigt, von einer Fata Morgana zu sprechen. Wichtig ist allerdings, dass man bei der Konzeption einer SOA-fähigen Anwendung unterscheiden muss zwischen möglichst universellen, auf Wiederverwendung in unterschiedlichen Kontexten ausgelegten Services sowie der Verkettung dieser Services, also Workflows als oberster Verdrahtungsebene. Services sind demnach universell, stabil und wiederverwendbar ausgelegt, Workflows dagegen spezifisch für einen Kunden oder eine Anwendung konfiguriert und müssen flexibel änderbar sein. Daher ist unbedingt erforderlich, diese Schichten zu trennen, insbesondere dann, wenn projektübergreifende Lösungsbausteine und kunden- oder projektspezifische Anwendungsteile voneinander isoliert werden müssen. Die Praxis zeigt jedoch, dass die Workflows nie geändert werden, ohne dass es eines neuen oder geänderten Service bedarf.