Schon seit längerem haben sich nicht nur die Integrationsspezialisten dem SOA-Gedanken verpflichtet. Auch die Anbieter von Unternehmensanwendungen sind auf den Zug aufgesprungen. Das Bereitstellen von Funktionen in Form von Diensten überschreitet Applikations- und Plattformgrenzen, insbesondere wenn dafür Web-Services-Standards verwendet werden. Dies gibt den Softwarehäusern die Möglichkeit, ihr gewachsenes und daher heterogenes Portfolio an Applikationen zu flexibilisieren und zu entkoppeln. Die Teile können sie dann je nach Bedarf als Composite Applications wieder zusammensetzen.

Integrationsprobleme

Auch wenn das SOA-Konzept zu einer Standardisierung innerhalb der vielfältigen Applikationslandschaft ein und desselben Herstellers führt, wäre es ein Trugschluss zu glauben, dass diese Entwicklung das Integrationsproblem insgesamt löst. Vielmehr wird es auf eine höhere Ebene verschoben. Mussten früher die diversen Anwendungen eines Anbieters miteinander integriert werden, sind es heute die Anwendungslandschaften - neudeutsch "Ökosysteme" - der Hersteller untereinander.

Das SOA-Architekturprinzip beschreibt eine Welt von Serviceanbietern und -konsumenten, die den inneren Aufbau der Services nicht kennen müssen. Obwohl dieses Konzept an keine bestimmte Technologie gebunden ist, haben sich Web-Services als konkrete Realisierung des Architekturprinzips durchgesetzt. Alle Hersteller, die dem SOA-Gedanken folgen, unterstützen und verwenden die Web-Services-Kernstandards Soap, WSDL und UDDI. Doch trotz dieses Konsenses entwickeln die gleichen Hersteller proprietäre Erweiterungen, insbesondere um Web-Services bereitzustellen, zu überwachen und deren Lebenszyklus zu steuern. Diese Erweiterungen und die Art und Weise, wie Diensteanbieter und -konsumenten miteinander kommunizieren, unterscheiden die SOA-Umgebungen der verschiedenen Anbieter voneinander und führen zu Kommunikationsproblemen zwischen ihnen. Den Nachteil haben Anwenderunternehmen, die ihre IT-Landschaften nicht durchgängig in Richtung SOA umgestalten können.

Von J2EE zu JBI

Der im August 2005 in der Version 1.0 vorgestellte Standard Java Business Integration (JBI), auch bekannt als Java Specification Request (JSR) 208, versucht, genau dieses Problem zu lösen und einen Standard für SOA-Plattformen zu etablieren. Bei den Diskussionen standen von Anfang an die Probleme der Performance und Skalierbarkeit, mit die wichtigsten Anforderungen großer Unternehmen an eine SOA, im Vordergrund. Daher musste das ursprüngliche Vorhaben der Arbeitsgruppe, die Integrationslogik in den Kernbestand des J2EE-Standards aufzunehmen, aufgegeben werden. Denn dies hätte zu einer Überlastung auch der leistungsfähigsten Applikations-Server geführt.

Das JBI-Projekt hat dementsprechend einen von Applikations-Servern unabhängigen Weg eingeschlagen. Dabei wurde das Web-Services-Prinzip, dass der innere Aufbau eines Web-Dienstes dem Servicekonsumenten nicht bekannt sein muss, auf die Ebene so genannter Container übertragen. Container enthalten Geschäftslogik und Transformationsdienste für Java-Anwendungen oder Applikationen, für die Java-APIs existieren, ferner JBI-konforme Adapter zu Anwendungen und Ressourcen, für die es keine Java-Zugangstechniken gibt. JBI definiert, wie die Container untereinander kommunizieren und von außen angesprochen werden können. Der Container-Aufbau im Innern muss dazu nicht bekannt sein. Mit diesem Ansatz lassen sich die Komponenten der unterschiedlichen SOA-Angebote in Form von Containern miteinander koppeln und verwalten. Möglich wird dies durch eine standardisierte Messaging-Infrastruktur sowie verbindliche Management-Standards.

Das Herzstück des JBI-Standards bildet die Messaging-Infrastruktur, der so genannte Normalized Message Router (NMR). Dabei handelt es sich um einen standardisierten Enterprise Service Bus (ESB), der den Nachrichtenaustausch zwischen den verschiedenen JBI-Komponenten vermittelt. Die JBI-Container sind mit dem NMR über bidirektionale "Standleitungen" verbunden, die so genannten Delivery Channels, und können Serviceanfragen sowohl senden als auch entgegennehmen.

Ein Dienstanbieter meldet dem NMR zur Laufzeit die angebotenen Services und liefert Informationen darüber, wie ein Dienst von einem Servicekonsumenten angesprochen werden kann. Die ausgetauschten Nachrichten müssen in einer standardisierten Form vorliegen, die JBI vorgibt. Die Standardisierung der Nachrichten selbst aber überlässt der NMR darauf spezialisierten Containern und unterscheidet sich gerade dadurch von proprietären ESB-Angeboten.

Standard für SOA-Management

Ein weiteres Ziel von JBI besteht in der Standardisierung des SOA-Managements: Anwender sollen von der Zwangsjacke proprietärer Erweiterungen der Hersteller befreit werden. Damit könnte sich der Widerspruch zwischen dem SOA-Gedanken der Plattform- und Technikunabhängigkeit einerseits und der Bindung an einen SOA-Hersteller andererseits auflösen.

JBI-Implementierungen inklusive JBI-Container müssen daher den Standard Java Management Extensions (JMX) ab der Version 1.2.1 unterstützen. Umgekehrt bietet die JBI-Implementierung spezielle JMX Management Beans (MBeans) für die wichtigsten administrativen Aufgaben. Dazu zählen unter anderem die Installation von JBI-Containern sowie das Bereitstellen von Service-Implementierungen und anderen Artefakten wie Policies oder Security-Vorgaben in bereits installierten Containern. Darüber hinaus lassen sich auf diesem Weg zusammenhängende Servicegruppen und JBI-Container starten und anhalten.

Nutzen von JBI

Einen Standard für Integration zu schaffen ist eine ambitionierte Aufgabe, doch sie lohnt sich: Denn der SOA-Gedanke wird so lange unvollendet bleiben, wie Unternehmen bei der Erstellung von Composite Applications auf Hürden stoßen, die in der Verschiedenartigkeit der verwendeten Entwicklungstechniken und der Integrationsinfrastrukturen begründet liegen. Solche Probleme treten in großen Unternehmen unweigerlich auf, wenn die Systemgrenzen dem Prozessgedanken wieder mal im Weg stehen.