Middleware/Integrations-Middleware hilft Brick-and-Mortar-Unternehmen

E-Business: Herkömmliche Firmen machen den Dotcoms Konkurrenz

16.06.2000
Moderne Middleware-Konzepte gehen oft an der Anwenderrealität vorbei. In heterogenen IT-Landschaften verlangt Integration mehr Anpassungsfähigkeiten, als sie Standards wie Corba, Javabeans oder EAI-Adapter zu bieten haben.Von Angelika Siffring und Harald Nehring*

Die schöne neue Welt des elektronischen Geschäfts im Internet verspricht wirtschaftlichen Erfolg durch bessere Kundenbindung, kostengünstigere Lieferketten und transparente Geschäftsprozesse. Dazu sollen sich die Firmen schnell und kompromisslos der neuen Techniken bedienen. Sind somit diese Möglichkeiten nur den Unternehmen der New Economy, den Dotcoms vorbehalten? Sind klassische Unternehmen und Organisationen mit ihren jahrzehntelangen Investitionen in interne IT-Systeme und damit optimierten Geschäftsprozessen auf dem Abstellgleis gelandet?

Glaubt man Analysten wie George Colony, CEO des Marktforschungsunternehmens Forrester Research, entpuppen sich viele Dotcoms schnell als Hollow.com ohne bleibende Werte und ernst zu nehmende Geschäftsperspektiven. Traditionelle Firmen mit Weitsicht und genügend Mut, diese neuen Technologien massiv einzusetzen, können sich mit ihren eingespielten Prozessen gegen viele dieser jungen, unerfahrenen Unternehmen durchsetzen.

Integration Broker verbinden WeltenDabei helfen Produkte und Dienstleistungen zur Integration vorhandener Plattformen, die bereits erfolgreich eingesetzt werden. Sie unterstützen die Anwender dabei, bestehende, erprobte und zuverlässige Systeme für neue Anwendungen des Electronic Business nutzbar zu machen. Eine Produktkategorie ist für diesen Einsatzbereich besonders geeignet, die so genannten Integration Broker - eine Software, mit der sich unterschiedliche Systemwelten verbinden oder zu einem neuen System verknüpfen lassen. Diese Programme bieten die Plattformdienste und Anschlusstechniken, um Anwendungsintegration möglich zu machen. Dabei werden zwei Ansätze unterschieden: der integrations- und der anwendungszentrische.

Integrationszentrisch arbeiten Produkte für Enterprise Application Integration (EAI) wie Neons "E-Biz Integrator" oder STCs "E-Gate Integrator". Ziel ist es alle Logik zur Verbindung bestehender Anwendungen und Anwendungspakete im Integrationsprodukt zu hinterlegen. Hierzu gehören die Abbildung und Konvertierung der unterschiedlichen Datenstrukturen von Quell- und Zielanwendung genauso wie die Regeln zur Nachrichtenadressierung und -verteilung. Im Idealfall sorgt der Integration Broker mit Hilfe seines Regelwerks für die automatische Verbindung verschiedenster Anwendungen - ganz ohne Anwendungsprogrammierung. Der Programmieraufwand hält sich in Grenzen.

Anwendungszentrische Integration Broker unterstützen demgegenüber bei Integrationsaufgaben, die sich nicht durch die einfache Zusammenschaltung bestehender Anwendungen lösen lassen. Hier kommen moderne Middleware-Produkte wie IBMs "MQ Series" oder Software AGs "Entire X" zum Einsatz. Sie gestatten es durch ihre Vielfalt an unterstützten Kommunikationsmodellen, Netzwerk-, Systemplattformen und Programmier-Schnittstellen, die unterschiedlichsten Anwendungen in neue Systeme für das Electronic-Business zu integrieren. Das bedeutet, dass mit steigender Komplexität der Integration auch die Funktionsvielfalt und -flexibilität des Middleware-Produkts wachsen muss.

Für die Zusammenführung von Standardanwendungen, etwa einer Peoplesoft-Personalanwendung mit einem betriebswirtschaftlichen SAP-System, bieten sich EAI-Produkte an, die auf die Integration spezialisiert sind. Zu den großen Herausforderungen gehört es jedoch, die Vielzahl und Vielfalt der Bestandsanwendungen und der von ihnen abgedeckten Funktionen zusammenzufügen. Hinzu kommen unterschiedlichste Betriebssystem-Plattformen, von Arbeitsplatzsystemen über Unix und klassische Midrange-Systeme bis hin zu Großrechnern, die heute wieder vermehrt einen großen Anteil der geschäftskritischen Inhouse-Anwendungen abdecken.

Zusätzlich basieren viele zu integrierende Applikationen auf etablierten Subsystemen, etwa auf Transaktionsmonitoren wie "CICS" im IBM-Großrechnerbereich oder "Tuxedo" auf Unix-Plattformen, sowie Middleware-Architekturen wie Corba. Daraus ergibt sich eine kaum mehr zu überblickende Zahl von Integrationspunkten, die theoretisch zur Verfügung stehen und genutzt werden können.

Ein weiteres Kriterium bei der Anwendungsintegration in Electronic-Business-Systeme ist die Art der Kommunikation zwischen den unterschiedlichen Anwendungselementen. Für die Kopplung von Komponenten, die zu einer Anwendung gehören, bietet sich die synchrone Kommunikation an. Sie ist seit langem in Technologien für den Fernaufruf von Anwendungen wie dem Distributed Computing Environment (DCE) oder auf Objektebene mit Corba verfügbar und gehört zur Grundausstattung jedes Integrationsprojekts.

Notwendig ist die synchrone Kommunikation zwischen Anwendungsteilen immer dann, wenn die Antwort des Kommunikationspartners den weiteren Ablauf der Anwendung bestimmt. Beispielsweise kann eine Online-Kreditvergabe ohne die definitive Antwort der Kreditprüfungsfunktion nicht im Anwendungsfluss fortfahren. Ebenso muss ein Online-Bestellsystem synchron auf interne Bestellfunktionen zugreifen, um dem Kunden eine sofortige Auftragsbestätigung erteilen zu können.

Wie die Beispiele zeigen, ist die synchrone Kommunikation in den meisten Fällen funktionsorientiert - die zu erledigende Aufgabe spielt die dominierende Rolle, die ausgetauschten Informationen sind meist begrenzt und dienen hauptsächlich der Statusübermittlung. Anders sieht die Kommunikation zwischen stark getrennten Systemen aus. Hier benötigt man asynchrone Techniken, wie sie von Message-orientierter Middleware (MOM) zur Verfügung gestellt werden. Asynchroner Meldungsaustausch ist immer dann nötig, wenn Partnersysteme nicht ständig verfügbar sind oder mit längeren Antwortzeiten zu rechnen ist.

Speziell bei den verstärkt aufkommenden Business-to-Business-Anwendungen (Integration zwischen Unternehmensgrenzen) kommt nur eine lose Kopplung über asynchrone Nachrichten in Frage. Katalog-Update-Systeme für die Online-Beschaffung (E-Procurement) oder Bestellaufträge in der Zulieferkette werden einmal erzeugt, auf eine Antwort des empfangenen Systems kann nicht gewartet werden. Hier muss die Middleware gewährleisten, dass die Nachrichtenübermittlung zuverlässig funktioniert. Moderne MOM-Systeme sind für diese Anforderung mit persistenten Nachrichtenspeichern ausgerüstet, um den einmaligen und garantierten Transport einer Meldung sicherzustellen.

Zum Aufbau leistungsfähiger Marktplätze oder unternehmensübergreifender Abrechnungssysteme ist XML-basierte, nachrichtenorientierte Middleware unerlässlich. Die einschlägigen Anbieter erweitern derzeit ihr Angebot um Möglichkeiten, mit XML- Datenformaten umzugehen und diese mit bestehenden Anwendungssystemen zu koppeln.

Die Anforderungen an EAI wurden durch neue Technologie nicht immer entscheidend vereinfacht. In der zweiten Hälfte der 90er Jahre verstärkte sich der Trend zur Verbindung von Middleware mit Komponententechnologie und Anwendungsinfrastruktur wie Transaktionsmonitoren und Datenbanksystemen.

Ausgehend von der objektorientierten Anwendungsentwicklung und der Konzentration auf verteilte Anwendungsarchitekturen, beispielsweise Client-Server, entstanden Technologien wie Corba und DCOM. Letzteres setzt allerdings eine homogene Systemumgebung voraus. Für beide gilt, dass alle Teile einer Anwendung dem jeweiligen Programmiermodell entsprechen müssen. Somit eignen sich weder Corba noch DCOM dazu, die Integration heterogener Systeme und Programmiermodelle zu erleichtern.

Auch der nächste Schritt - die Einbeziehung von immer mehr Anwendungsdiensten wie Transaktionen, Sicherheitsfunktionen oder Datenbankzugriffsverfahren in Middleware-Konzepte wie Suns Enterprise Javabeans (EJB) oder Microsofts COM+ - macht die Integration heterogener Systemwelten nicht einfacher. Weiterhin gehen sie von einem homogenen Weltbild aus, in der lediglich die Vorgängertechnologie, beispielsweise Corba bei EJB, als "Legacy" integrierbar bleibt. Insofern ist es nicht verwunderlich, dass EJB und COM+ zwar für die enge, synchrone Kopplung von Anwendungskomponenten erfolgreich eingesetzt werden, für die lose, asynchrone Kopplung unterschiedlichster Anwendungen auch über Unternehmensgrenzen hinweg jedoch Integration Broker unersetzlich bleiben. Das heißt zudem, dass eine einseitige Ausrichtung auf Application-Server-Technologie zwar Fortschritte bei der Vereinheitlichung der Anwendungsentwicklung und des -betriebs bringen können, sie aber keinen Ersatz für heterogene Middleware zur Anwendungsintegration darstellen.

Betrachten wir die vielfältigen Integrationsanforderungen im Electronic Business anhand eines Beispiels aus der Praxis, einem Webshop-Projekt. Ziel war ein integriertes System von der Bestellung über die Auslieferung bis zu Zahlungssystemen.

Während die Web-Anwendung, die die Interaktion mit dem Kunden sowie die gesamte Transaktion steuert, neu entwickelt wurde, verwendet die Abwicklung von Kreditkartenzahlung, Buchung und Fakturierung existierende interne Anwendungssysteme. Die Logistik wird von einem Partnerunternehmen übernommen.

Bei allen beteiligten Systemen handelt es sich um firmenspezifische Individualanwendungen. Solche Anwendungen verfügen üblicherweise nicht über wohl definierte externe Schnittstellen, wie dies bei Standardpaketen der Fall ist. Der Ansatz des einfachen Zusammenstöpselns mittels vorgefertigter Adapter stößt hier auf seine Grenzen. Vielmehr sind zur Integration Adapter gefragt, die sowohl einfach individuell programmierbar sind, als auch ein breites Spektrum von Plattformen und Programmiersprachen unterstützen - die Logistikanwendung des Partners ist beispielsweise eine Cobol-Anwendung auf AS/400.

Eine weitere Anforderung an die eingesetzte Middleware ist die Unterstützung unterschiedlicher Kommunikationsmodelle. Um dem Kunden den Ärger über eine angenommene, dann aber nicht ausführbare Order zu ersparen, wird eine Bestellung erst dann bestätigt, wenn das Kreditkartenzahlungssystem grünes Licht gegeben und die Logistikanwendung die Reservierung des Artikels bestätigt hat. Die Kommunikation mit den beteiligten Systemen muss in diesem Schritt synchron erfolgen, da der Kunde auf die Bestätigung wartet.

Zur Sicherstellung möglichst kurzer Antwortzeiten wird ein weiterer Service der Middleware genutzt, der es ermöglicht, Anwendungs-Server automatisch zu starten und bei Bedarf Replikate zu erzeugen. Die Lastverteilung zwischen den Replikaten übernimmt ebenfalls die Middleware. Damit sind Verfügbarkeit und Skalierbarkeit auch bei Spitzenlast gewährleistet, ohne dass die Server-Anwendung dafür etwas tun muss. Ein völlig anderes Anforderungsprofil setzen asynchron angestoßene Prozessschritte wie die Erteilung des Versandauftrags an das Logistikunternehmen voraus. Hier ist sicherzustellen, dass die Aufträge nicht verloren gehen.

Um flexibel auf neue Geschäftsanforderungen reagieren zu können, muss die Integrationsschicht außerdem garantieren, dass innerhalb kürzester Zeit weitere Hersteller, Zulieferer oder Logistikunternehmen in das Business-Modell einbezogen werden können.

Das Beispiel zeigt, dass für E-Business-Konzepte Prozesse nicht neu erfunden werden müssen. Vielmehr kommt es darauf an, bestehende Prozesse und Systeme intelligent zu verbinden.

*Angelika Siffring und Harald Nehring arbeiten im Produktmarketing für Middleware bei der Software AG, Darmstadt.

XML-ZukunftKünftig wird der Internet-Standard XML (Extensible Markup Language) das Integrationsgeschäft speziell bei firmenübergreifender Kommunikation erheblich vereinfachen, da damit eine einheitliche Beschreibungssprache für Dokumente, also den Informationsaustausch, zur Verfügung steht. Weil Electronic Data Interchange (EDI), das diese Aufgabe heute vielfach übernimmt, vergleichsweise unflexibel, aufwändig und teuer ist, wird es überwiegend von größeren Unternehmen eingesetzt.

XML dagegen erfährt schon jetzt unabhängig von der Firmengröße eine breite Akzeptanz. Kaum ein Anbieter von Standardsoftware oder Middleware, der nicht bereits XML-Unterstützung angekündigt hat. Mit der Spezifikation von Simple Object Access Protocol (Soap) durch Microsoft wird XML beispielsweise genutzt, um ein Standardformat für den synchronen Aufruf entfernter Funktionen zu definieren. Anders als bei CORBA und DCOM ist die Art, wie diese implementiert werden,unerheblich.

Weder die standardisierte Beschreibung der auszutauschenden Informationen noch die per XML standardisierte Art und Weise, Objekte und Funktionen zu nutzen, stellen jedoch ein Allheilmittel für die Anwendungsintegration dar. Es bleibt die Herausforderung für die Anwender, einen möglichst eleganten Übergang von der schönen neuen, standardisierten XML-Welt in die traditionellen geschäftskritischen Anwendungen ihres Unternehmens zu finden mit der gesamten Middleware-Palette.

Abb.1: Integrationsarten

Anforderungen an die Integration für E-Business. Quelle: SAG

Abb.2: Integration Broker

Je proprietärer und heterogener eine IT-Landschaft ist, desto flexibler muss der Intergration Broker sein. Quelle: SAG