Ein grundlegendes Integrations-Management ist notwendig, wenn Applikationen kommunikationsfähig gemacht werden sollen. Das muss in der Regel hart erarbeitet werden. Ist dieses "Enabling" einmal geschafft, sind Web-Services-Techniken wie XML, Soap, UDDI und WSDL lediglich Zusatzfunktionen, die meistens leicht und elegant implementiert werden können. Auch die Datenübertragung selbst, sei es mittels X.400, FTP, OPTP, HTTP oder über Message Oriented Middleware (MOM) wie Websphere MQ, Tibco und Webmethods, ist in der Regel nur eine nebensächliche technische Frage nach dem geeigneten Übertragungsmedium - IP-Multicast einmal ausgenommen.
Die Entscheidung hier fällt im Wesentlichen aufgrund der Plattform-Verfügbarkeit und Zuverlässigkeit des Protokolls. Der Vorteil von MOM liegt in der Entkopplung der Applikationen durch zwischengelagerte, von den Applikationen selbst unabhängige Mechanismen, welche die einmalige Übertragung der Nachrichten garantieren. Die Verantwortung für die Übertragung sowie die Fehlerbehebung liegen also nicht mehr bei der Applikation selbst, sondern bei der eingesetzten Middleware, was eine Trennung von Business-Logik und Transportschicht bedeutet.
Zur Übertragung von Nachrichten zwischen Partnerapplikationen können so genannte Message Broker eingesetzt werden, so zum Beispiel Websphere MQ Integrator, Seebeyond, Seeburger und Mercator. Message Broker verwalten die Routing-Tabellen, bilden die logischen Modelle der Nachrichten ab, übernehmen die Modell-zu-Modell-Konvertierung, Versionierung und Historisierung der eingehenden und ausgehenden Nachrichten sowie deren Übertragung.
Zunächst sollten sich die Geschäftspartner auf ein syntaktisches Modell einigen, also klären, welches Nachrichtenprotokoll verwendet werden soll. Dabei sollte man nicht zu viel Zeit mit der Frage verbringen, ob XML (bessere Lesbarkeit) oder Edifact das geeignete Format ist. Message Broker sind ohnehin durchgängig in der Lage, eine "Any-to-Any"-Konvertierung durchzuführen, also XML in Edifact und umgekehrt zu übersetzen.
Weit aufwändiger ist die Beantwortung der Frage nach dem Inhalt einer Nachricht, dem semantischen Modell. Während auf der syntaktischen Ebene diese Antwort relativ beliebig und wenig folgenschwer ist, müssen Entscheidungen auf der semantischen Ebene wesentlich besser überlegt werden. Hier beginnt die eigentliche Arbeit, denn mit der Wahl der Semantik werden Weichen gestellt. Es muss geklärt werden, welches Nachrichtenmodell man benötigt, welche Felder übertragen werden sollen, was sie bedeuten, wie lang sie sind und wie das zugehörige Datenmodell der Nachricht aussieht.
Edifact hilft hier ganz entscheidend, da sich unzählige Arbeitskreise im internationalen Rahmen seit rund 20 Jahren genau mit diesen Fragen beschäftigen. Das Resultat ist eine sehr große Anzahl von Nachrichten, die aus der Wiederverwendung genormter Elemente und Segmente mit Wertelisten zusammengesetzt werden und in unterschiedlichen Industrien zur Anwendung kommen. Dies hat auch die XML-Gemeinde erkannt, und sie versucht etwa in der Zusammenarbeit von UN/Cefact und Oasis, die EDI-Standards oder die in ihnen enthaltene Semantik nach XML zu überführen. Edifact-Nachrichten sind aber nicht nur Meldungen. Sie bilden einen Zyklus von aufeinander abgestimmten Nachrichten, die einzeln betrachtet nur einen Baustein eines Geschäftsprozesses darstellen, im Zusammenspiel jedoch einen kompletten, wohldefinierten unternehmensübergreifenden Geschäftsprozess ausmachen. Die so verbundenen Partner wissen damit sehr genau, wie eine aktuelle Nachricht zu einer anderen, gegebenenfalls von ihnen selbst zuvor versendeten oder empfangenen Nachricht gehört.
Prozessmodell kontra Publishing
Genau hier liegt die eigentliche Schwäche von XML. Betrachtet man die Dimensionen Syntax und Semantik, so fällt auf: Edifact wurde primär entwickelt, um ein semantisches Prozess-Modell bereitzustellen. XML dagegen bewegt sich hauptsächlich in der syntaktischen Dimension und spielt wegen der Nähe zu HTML im Web-Publishing eine große Rolle.
Edifact-Nachrichten sind aufgrund des Anspruchs auf hohe Wiederverwendbarkeit inzwischen sehr abstrakt geworden. Im eigentlichen Sinn sind sie die Metamodelle für einzelne Nachrichten, die in unterschiedlichen Geschäftsprozessen eingesetzt werden können. Zum Beispiel finden "Quote"-Nachrichten Anwendung im Bestellwesen des Procurements, bei Börsen und im Devisenhandel. Einzelne Industrien wie etwa die Automobilbranche oder der Handel sind dazu übergegangen, eigene Sub-Sets auf Basis von Edifact zu entwickeln. Vergleichbares lässt sich auch im Umfeld von XML bei Banken (FIXML und FpML im Börsen- und Devisenhandel) sowie bei Versicherungen (Acord) feststellen.
Ein weit verbreiteter Irrglaube ist, dass in Zukunft Milliarden Transaktionen durch die neuen XML-Technologien elektronisch abgearbeitet werden können.
Schon seit zehn Jahren wickelt zumindest die europäische Industrie nahezu ihren gesamten wertschöpfenden Geschäftsverkehr in und zwischen Unternehmen elektronisch mittels Edifact-Nachrichten ab. Ganz zu schweigen von der Bankenindustrie: Hier wäre ohne Swift die Einführung eines elektronischen Zahlungsverkehrs gar nicht denkbar gewesen.
Unabhängig von B-to-B oder EAI
Die eigentliche Herausforderung, der sich Unternehmen zu stellen haben, ist die Verarbeitung der eingehenden und ausgehenden Nachrichten durch Applikationen im Kontext von Geschäftsprozess-Modellen. Wer das effizient beherrscht, für den ist auch die Integration von Web-Services kein Problem, da die entsprechende Syntax von den Message Brokern generiert werden kann. Da ein Nachrichtenaustausch sowohl zwischen Unternehmen als auch intern erfolgen kann, tun Anwender gut daran, zwischen B-to-B und EAI gar nicht mehr zu unterscheiden. Sie sollten sich von Integrationen verabschieden, die auf einzelnen synchronen Low-Level-Transaktionen basieren und daher schwer beherrschbar sind.
Der bessere Weg sind höherwertige Modelle der asynchronen Kommunikation in Form von Nachrichten und Message Brokern. Das heißt, auch Applikationen innerhalb eines Unternehmens müssen als Partneranwendung in einem übergreifenden Geschäftsprozess begriffen werden.
Broker für Doppelstrategie
In Großunternehmen wie Banken ist diese Sicht alltäglich, da die vorherrschende räumliche und rechtliche Struktur sie bereits vorgibt. Die Architektur nutzt den Message Broker als Integrationsplattform, so dass zwei unterschiedliche Strategien verfolgt werden können. Sollte zum einen die Applikation in der Lage sein, selbst Nachrichten auf Geschäftsprozessebene zur Verfügung zu stellen, dann übernimmt die Plattform lediglich deren Bereitstellung und Übermittlung. Sollte die Applikation dies jedoch nicht beherrschen (Legacy) oder eine bewusste Entscheidung für diese Variante zugrunde liegen, dann kann die Integrationsplattform auf Basis von Low-Level-Interfaces (viele einzelne Transaktionen) die Daten zu höherwertigen Nachrichten zusammenfassen und nach außen hin darstellen (Business Façade Pattern).
Bei beiden Varianten geht es darum, eine Nachricht in das interne Objekt- oder Datenmodell einer Applikation zu überführen. Das bedeutet am Beispiel einer Lieferscheinnachricht (im Jargon von Edifact: DESADV), dass Datenelemente in zirka 30 unterschiedliche Objekte oder Datenbanktabellen (etwa Teil, Kunde oder Lieferbedingung) zu überführen sind. Meist bilden Applikationen jedoch keine Edifact-Modelle in ihrem internen Datenmodell ab. Das bedeutet, die Felder heißen anders, sind unterschiedlich lang oder haben gar einen anderen Typ.
Eine DESADV-Nachricht lässt zudem offen, ob die Artikel nach Lieferscheinposition verpackt sind oder Verpackungseinheiten übermittelt werden. Beim Mapping auf das interne Datenmodell, dem Ein- und Auslesen der Nachricht, ist in der Regel viel Programmierarbeit zu leisten. Message Broker können auch hier helfen, indem sie eingehende Nachrichten in ein internes, für die Anwendung verstehbares Modell konvertieren.
Die Welt des automatisierten Nachrichtenverkehrs zwischen Applikationen bleibt schwierig. Nachrichten können Fehler aufweisen, und die Industrie fordert die Implementierung neuer Logistikmodelle, im Investment Banking werden permanent neue Instrumente eingeführt, die Versicherungsbranche sieht sich mit den "Riester"-Produkten konfrontiert. Ein Großteil der Aufwände für die Implementierung entsteht hier oft gar nicht im Kern der Applikationen selbst, sondern im Bereich der Integration von Nachrichten. Unternehmen, die sich hierfür wappnen wollen, sind gut beraten, ihre Applikationen strategisch so vorzubereiten, dass ein großer Teil der Anpassungen zur Laufzeit durchgeführt werden kann, ohne kostspielige Releases erstellen zu müssen. (ue)
*Ulrich Hildebrand ist Senior IT Consultant und Chief Architect bei der Systor AG in Zürich.
Worauf es ankommt
Die eigentliche Herausforderung beim Thema B-to-B und EAI liegt nicht in einer Auswahl des allerneuesten syntaktischen XML-Modells, sondern in der Flexibilität und Erweiterbarkeit von Applikationen und deren Interfaces. Das vom angelsächsischen Raum geprägte Stimmungsbild, Edifact sei teuer, komplizierter und deshalb schlechter als XML, führt zu einer oberflächlichen Technologiediskussion und hat keine Allgemeingültigkeit. Es lenkt vom eigentlichen Thema ab. Die wichtigen Schritte auf dem Weg zum Erfolg bestehen in der Einigung auf ein internes Nachrichtenmodell, der Verwendung bestehender semantischer Modelle sowie dem Einsatz von Message Brokern.
Abb: Referenzarchitektur für Integration
Unternehmen sollten ihre Integrationen auf höherwertige Modelle der asynchronen Kommunikation aufsetzen. Quelle: Systor