Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Messe-Rundgang CeBIT 2000: Enterprise Application Integration


18.02.2000 - 

Intelligente Middleware verbindet Anwendungsinseln

MÜNCHEN (bs) - Mehr als 35 Prozent ihrer IT-Budgets geben Unternehmen für die Integration von Anwendungen aus. Rund 70 Prozent des insgesamt programmierten Codes werden für den Informationsaustausch zwischen DV-Systemen erstellt. Anbieter von Enterprise-Application-Integration-(EAI-)Software zeigen auf der CeBIT Einsparungspotenziale.

Die Integration unterschiedlicher Anwendungen ist so alt wie die Datenverarbeitung selbst. Welches Unternehmen kann heute seine Finanzbuchhaltungssoftware ohne die Verknüpfung mit Warenwirtschaft und Logistikanwendungen Gewinn bringend einsetzen? Verschiedenste Softwaresysteme im Verbund sind heute genauso Status quo wie der Einsatz heterogener Hard- und Betriebssystemplattformen.

Auch Werkzeuge und Methoden für die Verknüpfung von Softwareinseln sind nicht grundsätzlich neu: Middelware, ob transkations- oder nachrichtenorientiert, Application-Server, Gateways und Datentransformations-Tools (Mapping) gehören seit langem zur Ausstattung von IT-Shops. Was ist denn dann eigentlich neu an EAI-Software? Handelt es sich nur um ein weiteres Buzzword oder einen von Anbietern und Analysten gesteuerten Marketing-Coup?

EAI ist mehr als Marketing-HypeFestzustellen ist, dass die Entwicklungen im Bereich Integrationssoftware nicht stehen geblieben sind. Bedingt durch den vermehrten Einsatz von Standardsoftwarelösungen im Bereich Enterprise Resource Planning (ERP), Customer-Relationship- (CRM) und Supply-Chain-Management (SCM), erhält die Integration von Lösungen eine neue Qualität. Mussten bis dato unterschiedlichste Individualanwendungen, die in der Regel nicht über definierte Interfaces verfügten, mittels aufwändiger Schnittstellen-Programmierung zusammengebunden werden, so ist bei modernen Standardprodukten eine Vielzahl von Andockpunkten vorgesehen. Der EAI-Markt birgt laut Analysten von Gartner Group und IDC ein Potenzial von weltweit rund 82 Milliarden Dollar. Neben der starken Verbreitung von Standardsoftware forcierte die Anbindung von Altanwendungen an das Web sowie die zunehmende Zahl von Firmenzusammenschlüssen den EAI-Gedanken, so die Marktforscher weiter.

Die Lücken zwischen den Standardlösungen wollen die EAI-Anbieter schließen: Mit Hilfe vorgefertigter Adapter, Connectoren oder schlicht Schnittstellen soll sich der Aufwand für die Integration unterschiedlichster Applikationen verringern. Zudem seien die so geschaffenen Verbindungen wartungsfreundlicher und meist recht bequem an neue Release-Stände anpassbar. Das ist bei individuell programmierten Kopplungen oft nicht der Fall. EAI-Anbieter versprechen, dass sowohl verschiedene ERP-Anwendungen wie SAP, Baan, Peoplesoft als auch Front-Office-Lösungen etwa von Clarify, Siebel und Vantive per "Standardstecker" integrierbar seien.

Bei EAI-Produkten handelt es sich um eine Art "intelligente" Middleware, die zum einen mehr oder weniger fertige Integrationsbausteine umfasst. Ein wesentliches Kennzeichen der neuen Middleware besteht darin, die Programmierung zu vereinfachen. Dazu werden Softwarebausteine geliefert, die sich wie vorgefertigte Anschlussstücke für die herstellerspezifischen Application Programming Interfaces (APIs) verwenden lassen.

Entwickler sind dadurch nicht mehr gezwungen, sich mit den proprietären Datenstrukturen und Interfaces der zu verbindenden Produkte auseinander zu setzen, da die jeweils benötigten Adapter von den EAI-Anbietern geliefert werden.

Intelligenz bedeutet zum anderen aber auch, dass neben den bisher üblichen technischen Verbindungen die betriebswirtschaftlichen Anforderungen von ERP-, SCM- und CRM-Systemen berücksichtigt werden. EAI-Lösungen bieten also mehr als die heute technologisch orientierte Middleware: Sie kümmern sich um den Transport von Daten (meist Message-basiert), gleichen unterschiedliche Formate ab und sorgen dafür, dass die Informationen in den richtigen Anwendungen zur Verfügung stehen. Zusätzlich lässt sich mit einer Reihe von Produkten eine eigenständige Geschäftslogik entwickeln.

Viele alteingesessene Middleware- oder Entwicklungs-Tool-Hersteller möchten verständlicherweise von dem EAI-Boom profitieren und springen auf den Zug auf. Doch liefern die meisten allenfalls Bruchstücke einer EAI-Lösung, beispielsweise Message- und Transaktions-Middleware, Broker-Software oder auch Tools für die Datenkonvertierung (Mapping). Dem Anspruch einer Systemintegration per Plug and Play auf dem Niveau von Geschäftsprozessen oder Applikationen werden sie nicht gerecht. Das vielfältige Angebot erschwert es Anwendern, den richtigen Anbieter und das passende Verfahren zu finden.

Ein Manko von EAI-Paketen ist zudem, dass je stärker ein Anwender sein eingesetztes Standardpaket modifiziert hat, universelle Adapter per Plug and Play umso weniger funktionieren können. Für diesen Fall haben die Anbieter vorgesorgt: Sie stellen Workbenches bereit, mit denen sich individuelle Ausprägungen realisieren lassen sollen.

Hilfreich für die Anbieterauswahl ist eine Betrachtung der unterschiedlichen Softwarearchitekturen der erhältlichen Produkte. Grundsätzlich gibt es zwei Verfahren, Anwendungen miteinander zu integrieren: die datentechnische Verbindung auf der Ebene von Datenbanken oder eine Brücke via APIs. Bei der Auswahl der passenden Methode muss zunächst geklärt werden, ob die Verbindung ereignis- oder zeitgesteuert sein soll und ob eine Batch-Integration oder eine Echtzeitverbindung benötigt wird. Unternehmen können Techniken wählen:

1. Individuelle Integration

Das Konzept basiert auf dem Einsatz von Middleware als Transportmedium und ist individuell programmiert. Diese Möglichkeit wird zunehmend vereinfacht, da die Endpunkte des Workflows mit Hilfe von Standardkonnektoren, wie sie etwa Neon Software liefert, an ein ERP-Paket angebunden werden können.

2. Traditionelle Datenbankintegration:

Die Technik ist seit vielen Jahren im Einsatz und durch einen hohen Anteil an Individualentwicklung gekennzeichnet. Heute bieten einige EAI-Hersteller wie Constellar zusätzlich vorgefertigte Datenbankkonnektoren an, sodass sich der Programmieraufwand reduzieren lässt. Die Daten werden periodisch extrahiert, eventuell umgeformt und in der Zieldatenbank gespeichert. Dieses Konzept ist auch als Drehscheibentechnik (Hub) bekannt. Dabei schreibt eine Anwendung in die Datenbank hinein, und die nächste liest diese Sätze aus dem Speicher wieder aus.

3. EAI-Framework:

Hersteller wie Active oder Oberon bieten ein Entwicklungs- und Runtime-Framework, um über die APIs der beteiligten Anwendungen die erforderliche Integration zu bewerkstelligen, sofern eine API überhaupt vorhanden ist. Diese Integration umfasst sowohl den Workflow als auch den Transport der benötigten Daten zwischen den Applikationen. Über die APIs der Anwendungen wird in der EAI-Middleware die erforderliche Intelligenz bereitgestellt, um allen betroffenen Anwendungen Datenveränderungen ereignisgesteuert mitzuteilen.

4. Prozessintegration:

Die Verbindung auf dem Niveau von Geschäftsprozessen ist die fortschrittlichste, aber auch komplexeste. Bei diesem Verfahren lassen sich sowohl die Adapter erstellen, also die Anschlüsse an Standardprodukte, als auch eine eigene Anwendungslogik definieren. Beides ist strikt voneinander getrennt.

So lassen sich eigenständige "neue" Anwendungsfunktionen entwickeln, die in den Einzelanwendungen so nicht vorgesehen sind. Gebildet werden diese neuen Funktionen, indem die Programmlogik der Prozess-Middleware auf die unterschiedlichen zu integrierenden Softwarepakete zurückgreift und die dort vorhandenen Prozesse zu einem neuen virtuellen Vorgang verbindet.

Somit lassen sich beispielsweise Call-Center-Software und ERP-Pakete so verknüpfen, dass ein Mix aus beiden Systemen entstehen kann. Zu klären ist im Vorwege allerdings, welche Geschäftsprozesse mit welchen Durchlaufvarianten zu unterstützen und welche Daten dazu zu transportieren sind.

Prozess-Middleware basiert auf einem zentralen Applikations-Server, mit dessen Hilfe sich der Workflow und alle dazugehörenden Regeln definieren lassen. Daneben bietet er die Möglichkeit, Geschäftslogik in Form eines ablauffähigen Codes zu generieren.

Ausgehend von den vier theoretischen Integrationsansätzen stehen Anwendern vier technische Verfahren zur Verfügung, um die Integration in die Tat umzusetzen:

Die Point-to-Point-Implementierung, das Bus- oder Pipline-Verfahren, die Hub-and-Spoke-Technik sowie die Realisierung auf Basis von Prozess-Middleware.

Die Punkt-zu-Punkt-Implementierung verknüpft zwei Anwendungen durch eine direkte Middleware-Kopplung. Ob diese über individuelle Programmierung realisiert wird oder ob bereits Standardkonnektoren eingesetzt werden, ist eine Frage des benötigten Programmieraufwands. Ist er gering, lohnt die Anschaffung eines Standardadapters nicht. In der Regel fußt diese Lösung auf einer synchronen Middleware-Verknüpfung. Genutzt wird dieses Verfahren bei der individuellen Integration und wenn nur wenige Schnittstellen sowie eine kleine Zahl unterschiedlicher Systeme verbunden werden soll.

Für Integrationsanforderungen, die eine direkte Verteilung von Informationen entlang einer linearen Workflow-Kette in Form eines Publish- und Subscribe-Mechanismus benötigen, bieten sich die Bus- und Pipeline-Implementierung als direkte Verteilung an. So kann ein Messaging-System die Auftragsdaten von einer Fabrik zur anderen transportieren - wenn nötig rund um den Erdball. Damit ließe sich ein Produktionsprozess ausreichend gut integrieren. Auch für die Verteilung von Börsenkursen an bestimmte Empfänger anhand vorab definierter Ereignisse ist dieses Verfahren geeignet. Die Architektur ist dabei in der Regel datenbankorientiert, da die beiden Endpunkte des Workflows Datenspeicher sind.

Bei der Hub-and-Spoke-Implementierung verbindet ein zentraler Softwarebaustein unterschiedliche Anwendungen über diverse Hardware- und Betriebssystem-Plattformen hinweg. Der Hub steuert sowohl den Geschäftsprozess als auch die Umsetzung der Integrationsregeln. Deshalb gibt es hier keine Trennung zwischen Workflow und Geschäftslogik. Für viele Integrationsanforderungen ist das ausreichend; problematisch wird es allerdings, wenn neue Geschäftsprozesse hinzukommen oder sich Abläufe oft verändern. In diesem Fall sind die Interfaces permanent anzupassen. Es lohnt sich daher, die späteren Wartungskosten bereits vor der Entscheidung für eine Lösung rechtzeitig zu berücksichtigen. Als Middleware kommen häufig asynchrone Messaging-Systeme zum Einsatz. EAI-Frameworks bilden die Architektur, weil damit die Integration unterschiedlicher Anwendungen mit geringstem Aufwand möglich ist.

Trennung von Konnektor und WorkflowDie Realisierung mittels Prozess-Middleware umfasst eine Trennung zwischen Konnektoren, die die technische Anbindung der Anwendungen gewährleisten, und der Definition des Workflows, um die Regeln aufzustellen, nach denen ein bestimmter Geschäftsprozess abläuft.

Dabei gehören Konnektoren entweder zum Standardumfang der EAI-Produkte oder müssen mit Hilfe einer von einigen Herstellern mitgelieferten Entwicklungsumgebung individuell für unternehmensspezifische Anwendungen gebaut werden. Diesen Abläufen werden wiederum Programme mit bestimmter Geschäftslogik zugeordnet, um die Integrationslogik zwischen allen angeschlossenen Anwendungen an einer zentralen Stelle programmieren und kontrollieren zu können.

Der Ansatz mittels Prozess-Middleware ist sinnvoll, wenn viele Anwendungen gleichzeitig miteinander integriert werden müssen. Vor allem auch unter dem Gesichtspunkt der späteren Erweiterung beziehungsweise der Notwendigkeit, Geschäftsprozesse und deren Abläufe ändern zu können, ohne immer wieder von vorn beginnen zu müssen. Lohnen soll sich der EAI-Einsatz ab fünf zu integrierenden Systemen.

Viele Hersteller bieten mittlerweile EAI-orientierte Middleware an. Es handelt sich jedoch meist um junge Firmen. Anwendern sollte also klar sein, dass die Lösungen oft noch reifen müssen. Diese Zeit sollte man den Herstellern einräumen und die eigene Projektplanung darauf abstellen - es lohnt sich.

Um Anwendern und auch den Anbietern durch den EAI-Dschungel zu helfen, formierte sich im Mai 1999 das Enterprise Integration Council (EIC), dem mittlerweile mehr als 70 Anbieter angehören. Ziel sei es, so erklärt David McGoveran, einer der Gründerväter, Anwendern und Herstellern gleichermaßen eine Übersicht über mögliche Kopplungstechniken zu geben und eine Markttransparenz zu schaffen. Es sollen aber auf keinen Fall neue Standards entwickelt werden, dies überlasse man lieber Organisationen wie der Open Management Group (OMG) oder der Open Application Group (OAG). Ein nächstes Ziel der Gruppe ist es, eine Art Lexikon einzurichten, mit dessen Hilfe Anwender die passende EAI-Lösung für ihr spezifisches Problem finden können.

Auch die COMPUTERWOCHE hat sich dem Thema EAI angenommen und richtet in Kürze einen entsprechenden Ratgeber auf ihrer Homepage ein (www.computerwoche.de).

Daneben wurde unter der Ägide des Münchner Beratungsunternehmens CSA Consulting ein EAI-Forum ins Leben gerufen (www.eaiforum.de). Hier finden sich neben Grundsatzartikeln auch Hersteller- sowie Produktbeschreibungen.

Abb.: Nur wenige Anbieter liefern ein vollständiges Integrationskonzept mit entsprechenden Tools. Quelle: CSA Consulting