Mehrere Gründe sprechen für den Wechsel von herkömmlichen Anwendungspaketen zu objektorientiert konfigurierbaren Umgebungen. Zum einen wird durch die gezielte Wiederverwendung von Anwendungs-Frameworks oder -komponenten eine höhere Produktivität bei der Entwicklung erreicht; zum anderen können die Business-Objekte - vorausgesetzt, sie weisen eine gut definierte Schnittstelle auf - jederzeit durch eine effizientere Komponente ausgetauscht werden, ohne daß sich an der Schnittstelle etwas ändern muß. Dies gilt unabhängig von der Implementierungssprache, die für das Objekt verwendet wurde.

Die meisten Anwendungspakete für die Bereiche Logistik, Produktion und Finanzen wurden bereits vor Jahren entwickelt, als Objektorientierung bei den Standardsoftware-Anbietern noch kein Thema war und es auch noch keine Infrastruktur zur Verteilung der Business-Objekte gab. Aus heutiger Sicht läßt sich dieses Manko nicht durch Erweiterungen oder den sprachlichen Mißbrauch des Begriffs "Objekttechnologie" kompensieren.

Der Einsatz grafischer Entwicklungs-Tools brachte den Durchbruch im Softwaremarkt: Mit diesen Werkzeugen war es leicht, ein grafisches Objekt auf dem Interface mit einem in der Datenbank definierten Feld zu verknüpfen. Die Integration wurde über ein gemeinsames logisches und physisches Datenmodell erreicht. Aus diesem Grund war die Änderung eines Feldeintrags im Vertriebsmodul nach einem Update auch im Finanzmodul sichtbar. Dieser datenzentrierte Ansatz machte SQL zu einem dominanten Interface.

Doch die darunterliegende Datenbank stößt bei der Integration unternehmensweiter Anwendungen sehr schnell an ihre Grenzen: Es ist praktisch nicht möglich, alle Anwendungen in einem "Big Bang" zu implementieren, da sie nicht die gleiche logische oder physikalische Datenbank benutzen und nicht Teil eines integrierten Datenbankschemas sind.

Message-Broker als Objekt-Vermittler

Message-basierende Integration erlaubt die lose Kopplung von Anwendungen oder Business-Objekten über ein Wide-Area-Netzwerk. Dabei ist ein Message-Broker für die Verwaltung und Registrierung von Nachrichten verantwortlich: Er entscheidet, welche Message von einem Objekt gesendet wird und welches Objekt am Empfang dieser Nachricht Interesse hat. Ein Vorgang, der auch als "Publish-Subscribe"- Mechanismus bekannt ist. Er erlaubt sowohl eine asynchrone (der Empfänger muß nicht aktiv sein) als auch eine synchrone (aktiver Empfänger) Verarbeitung der Messages. Neue Nachrichtentypen und neue Interessenten können dynamisch durch die vom Message-Broker verwaltete Registrierung hinzugefügt werden.

Als Integrationsmöglichkeit bot sich die Schnittstellen-Technik des Application Programming Interface (API) an. Ihr Nachteil liegt jedoch in gewissen Restriktionen etwa bei der Aufrufsequenz und beim Datentyp. Die daraus resultierende geringere Flexibilität bedeutet einen erhöhten Pflegeaufwand auf beiden Seiten der betroffenen Applikationen.

Unter den Anbietern wächst deshalb mehr und mehr das Bewußtsein, daß solche Schnittstellen Message-basierend sein müssen: Eine Anwendung würde dann eine Liste der unterstützten Messages zur Verfügung stellen, damit IS-Programmierer, Integratoren oder andere Hersteller diese Schnittstelle nutzen können. Messages sind auf Business-Ebene implementiert und nicht auf technologischer Ebene. Somit unterstützen sie Business-Transaktionen im Ganzen, was den Prozessen innerhalb einer Organisation entspricht.

Das Problem dieses Paradigmenwechsels ist jedoch, daß die Unterschiede zwischen den einzelnen Anbietern bei der Adaption dieser Technologie sehr groß sind. Bevor eine Standardsoftware einem Re-Engineering unterzogen werden kann, muß das Messaging als Mechanismus benutzt werden, um Informationen zwischen verschiedenen Anwendungspaketen austauschen zu können - unabhängig davon, welche Integrationstechnologie innerhalb der kooperierenden Software genutzt wird. Diese Strategie wird von der Open Application Group (OAG) verfolgt, einem 1995 gegründeten Zusammenschluß diverser Standardsoftware-Anbieter, darunter Marcam, SAP, Dun & Bradstreet, Oracle und Peoplesoft.

Im vergangenen Jahr demonstrierte die OAG eine eingeschränkte Form von Interoperabilität zwischen der Lagerverwaltung und der Finanzbuchhaltung unterschiedlicher Anbieter. Da sich diese Integrationsbemühungen auf die Lösungen der OAG-Mitglieder beschränken und weitere Bemühungen eher zaghaft sind, ist der Nutzen solcher Systeme für die Anwender fraglich.

Task Force für semantisches Messaging

Einen auf den ersten Blick ähnlichen Weg geht die 1989 gegründete Object Management Group (OMG), die mehr als 650 Mitglieder zählt und in der sich beispielsweise auch SSA aktiv beteiligt. Die in der OMG festgelegten Spezifikationen für die Common Object Request Broker Architecture (Corba) liefern eine Infrastruktur für die Kommunikation von verteilten Objekten über Hardware- und Netzwerkgrenzen hinweg - definieren jedoch nicht die Semantik der Messages.

Corba bietet also in der Spezifikation noch wenig für Business-Objekte. Aus diesem Grund wurde innerhalb der OMG eine Gruppe für die Ebene oberhalb der Kommunikationsinfrastruktur gebildet: die Business Object Domain Task Force. Sie beschäftigt sich mit Business-Objekten und kommt den Anforderungen der Endanwender nach, ein Framework für den Austausch von semantischen Messages bereitzustellen - eine sogenannte Business Object Facility (BOF).

Unterschiede zwischen OAG- und OMG-Ansatz

Zwar ermöglicht auch die OAG den Austausch von Messages zwischen existierenden Anwendungspaketen, indem eine bestimmte Anzahl von Nachrich-ten für einige spezifizierte Anwendungen festgelegt wird, die OMG geht jedoch einen Schritt weiter: Sie definiert Business-Objekte, die miteinander über ein Framework kooperieren, als einen Bestandteil des Business-Systems.

Diese Business-Objekte können sowohl neu entwickelt als auch von vorhandenen Anwendungen abgeleitet sein. Deshalb umfaßt die OMG-Spezifikation beides: die Intra- und die Inter-Anwendungsintegration. Der Fokus der OAG liegt ausschließlich auf der Definition von Messages für die Inter-Kommunikation zwischen existierenden Anwendungen ihrer Mitglieder. Sie entspricht somit in bestimmten Teilbereichen dem weiter gefaßten OMG-Ansatz.

Die Vision von einem Anwendungspaket, bestehend aus Business-Objekten, basiert auf der Distributed Object Computing Architecture (Doca). Durch die Nutzung von semantischen Messages können verteilte Business-Objekte dynamisch auf Business-Ereignisse reagieren und stellen somit die Basis für die Unterstützung ständig variierender Geschäftsprozesse dar. Eine Echtzeitintegration von externen Anwendungen ist nur durch ein Semantic Message Gateway möglich.

Die Objekte müssen künftig von dem spezifischen Anwendungsmodul vollkommen gelöst sein. Sie werden lose gekoppelt und kooperieren je nach Organisationsanforderung über Netzwerk- und Hardwaregrenzen hinweg mittels semantischer Messages. Das Ergebnis ist eine integrierte Anwendung, die je nach Bedarf konfiguriert und rekonfiguriert werden kann. SSA selbst liefert Business-Objekte mit einem Anwendungs-Framework. Als Mitglied in der OMG ist man bemüht, innerhalb der Business Object Domain Task Force auch den Message-Austausch zu standardisieren.

*Thomas Xander ist Technologie-Manager der System Software Associate GmbH (SSA) in Düsseldorf