Enterprise Application Integration
Anwendungen werden meist für einzelne Aufgaben und Abteilungen einer Unternehmung angeschafft oder erstellt. Geschäftsprozesse erstrecken sich oft über größere Teile des Unternehmens und sollten Daten und Funktionalität mehrerer Systeme vereinen. Integrierte Systeme, die alle Funktionen des Unternehmens in einen System bereitstellen, vermeiden diese Problematik. Unglücklicherweise gibt es für viele Branchen und Bereiche keine integrierte Software, die alle gewünschten Funktionen abdeckt. Ein anderer Ansatz stellt die Integration verschiedener Anwendungen dar. Über eine Middleware wird eine gemeinsame Ebene geschaffen, mit der die verschiedensten Systeme angebunden werden können.
In der Praxis existiert beides nicht selten nebeneinander: Ein integriertes System, welches den Großteil der Funktionalität abdeckt und zahlreiche kleinere und mittlere Systeme, die Aufgaben übernehmen, die in dieser Form nicht oder nur unzureichend vom Integrierten System bereitgestellt werden. Die einzelnen Systeme stellen Inseln dar, die es zu integrieren gilt.
1. Verschiedene Arten der Integration
Es gibt zwei grundsätzliche Arten der Integration. Zum einen über die Daten und zum anderen über die Funktionalität. Je nach Umfeld, kann jeder der beiden Ansätze interessant sein. Im Folgenden stelle ich beide Arten vor.
1.1. Integration mit Daten
1.1.1. Import und Export
Die trivialste Art der Integration stellen Import und Export über Dateien dar. Leider benutzen die beteiligten Systeme selten die selben Formate, so daß eine Umwandlung durchgeführt werden muß. In der Vergangenheit leisteten Skriptsprachen wie Perl hierfür gute Dienste. Leider sind diese Skripte nicht besonders gut lesbar, geschweige denn wartbar. Viele Programmierer verstehen ihre eigenen Skripte schon nach kurzer Zeit nicht mehr. Man spricht von Wegwerfskripten. Erschwerend kommt hinzu, daß diese Konverter nicht selten unter Zeitdruck erstellt wurden. Abhilfe verspricht die Verwendung von XML. Zunehmend werden Programme mit XML Import und Export Funktionen ausgestattet. In selten Fällen unterstützen die beteiligten Anwendungen die selben XML Dialekte. Die Umwandlung von einem XML Format in ein anderes können wir uns nicht ersparen. Beispielsweise die Umwandlung von BMECat, einem Katalogformat, in proprietäres XML. Die Aufgabe der Umwandlung können XML Konverter übernehmen, die sich leicht mit der eXtensible Stylesheet Language for Transformation XSLT realisieren lassen.
Die Integration über Dateien ist zwar einfach, besitzt jedoch einige Nachteile. Die Daten kommen mit einer Verzögerung in den Zielsystemen an, da der Zugriff auf die Quellen nicht in Echtzeit erfolgt. Auf importierte Daten sollte nur lesend zugegriffen werden, da Updates nicht automatisch ins Quellsystem übermittelt werden. Änderungen der gleichen Daten in zwei Systemen ist sehr problematisch und erfordert ein Konfliktmanagement bzw. Replicationsmechanismen. Bei der Integration mobiler Geräte wie Palmtops und Notebooks ist der Import und Export über Dateien durchaus interessant.
1.1.2. Gemeinsamer Zugriff auf Datenquellen
Eine nicht gerade empfehlenswerte Möglichkeit ist die Integration mittels Zugriff auf die Datenbank fremder Anwendungen. Leider findet man diese Architektur recht oft in der Praxis. In Laufe der Zeit verzahnen sich dabei die Anwendungen so sehr, daß sie zu einem einzigen komplexen System verschmelzen und nicht mehr getrennt ablauffähig sind. Sind beide Systeme mit unterschiedlichen Sprachen und Technologien realisiert kommt dies erschwerend hinzu.
Es gibt eine Ausnahme, bei der der Zugriff auf fremde Datenquellen gerne in Kauf genommen wird. Ich möchte dies Anhand eines Beispiels verdeutlichen. Ein Unternehmen hat über die Jahre eine komplexe Anwendung mit 4GL Tools erstellt, die sie jetzt gerne durch eine neue objektorientierte und webfähige Lösung ersetzten möchte. Im Altsystem stecken mehrere duzend Mannjahre und das Fachwissen vieler Experten. Die Dokumentation wurde seit mindestens 8 Jahren nicht mehr gepflegt und beschränkt sich auch auf die Definition von Masken. Das Datenmodell der Anwendung ist ständig gewachsen und enthält die gesamten betriebswirtschaftlichen Daten der letzten Jahre. Das neue System ist frühestens in 3 Jahren komplett fertig und soll dann das Altsystem ablösen. Bereits heute möchte das Unternehmen seinen Kunden und Lieferanten über eine Web Oberfläche und über Web Services anbinden. Da das Unternehmen, was Funktionalität, Ausfallsicherheit und Performance angeht, mit der bestehenden Anwendung sehr zufrieden ist, soll das neue System im wesentlichen das selbe leisten und lediglich das alte System in einer Technologie und Architektur abbilden. Anschließend möchte das Unternehmen am neuen System wieder Verbesserungen und Weiterentwicklungen durchführen.
1.1.2.1 Migration mit Enterprise JavaBeans
Enterprise JavaBeans sind für solche Fälle ideal. Für den geschilderten Fall könnte ein Ansatz der folgende sein. Im alten System werden zunächst alle Weiterentwicklungen eingestellt und das Datenmodell nicht mehr verändert. Bugfixes in den Clients werden noch vorgenommen. Die Altanwendung wird analysiert und dokumentiert. Anschließend werden die Anforderungen an das neue System dokumentiert und eine Architektur entwickelt. Aus dem Altsystem wird eine Teilfunktionalität ausgewählt aus der sich ein Modul bilden läßt. Für das Modul werden mit Enterprise JavaBeans Geschäftsobjekte erstellt, die auf den bestehenden Tabellen aufsetzen. Nach der Fertigstellung des Moduls, wird dieses auf einem Application Server in Betrieb genommen. Die EntityBeans des Moduls greifen auf Tabellen der Produktionsdatenbank zu. Das alte System und das neue Modul greifen lesend und schreibend auf ein und dieselbe Datenbank zu. Für die Transaktionssicherheit sorgt die Datenbank. Daß der Cache des Applicationservers deaktiviert wurde, ist Voraussetzung für den Parallelbetrieb. Nach einer Testphase wird die Funktionalität, die das Modul übernommen hat im Altsystem deaktiviert. Die Benutzer können diese Funktionalität jetzt im neuen Modul nutzen. Es bietet sich an, einige schicke Features in das neue Modul zu integrieren, um die Akzeptanz der Benutzer zu erhöhen. Dafür eignen sich grafische Statistiken und Auswertungen. Nach und nach kommen immer mehr neue Module hinzu, bis das Altsystem deaktiviert werden kann.
1.1.3 EAI Tools
Eine ganze Reihe von Produkten unterstützt die Integration von Systemen über die Daten. Eine Middleware sorgt dafür, daß Datenänderungen in einem System auch die Änderung dieser Daten in anderen System nach sich zieht. Trigger auf Datenbankebene können diese Vorgänge auslösen. Die Middleware benötigt dafür genaue Kenntnisse über die Struktur der Daten und damit über die Implementierung der beteiligten Programme. Ändert sich eines dieser Programme, so muß überprüft werden, ob die Middleware noch wie gewünscht funktioniert und muß gegebenenfalls angepaßt werden.
1.1.4 Replication
Die Replication von Daten hat ihre Berechtigung, wenn die zu integrierenden Systeme nicht dauerhaft über ein Netzwerk miteinander verbunden sind und Datenänderungen nicht nur an einem System durchgeführt wird. Ein Beispiel ist die Synchronisation von Adressen zwischen PC und Palmtop. Ein Konflikt tritt auf, sobald die selbe Adresse auf beiden Seiten geändert wird. Für die Auflösung dieser Konflikte gibt es mehrere Stragegien wie Versionierung oder das Speichern beider Versionen.
1.2 Funktionale Integration
Im Gegensatz zu der Integration über Daten, werden bei der funktionalen Integration Implementierungsdetails hinter Schnittstellen verborgen. Eine Schnittstelle enthält eine Reihe von Funktionen, die jeweils eine Aktion auslösen. Die beteiligten Systeme bieten Dienste an, die über das Netzwerk angesprochen werden können. Für die Kommunikation stehen den Entwicklern eine Reihe von Standards und Produkte zur Verfügung. In einem heterogenen Umfeld zeichnet sich CORBA durch seine Plattformunabhängigkeit aus. Über Gateways können Systeme mit unterschiedlichen Technologien wie CORBA, RMI, DCOM oder SOAP miteinander kommunizieren. Eine Integration von Systemen mit verschiedenen Schnittstellen kann über eine Middleware realisiert werden.
Mit der funktionalen Integration ist der Zugriff auf Daten und Funktionalität in Echtzeit möglich. Beispielsweise kann ein Web Shop den Lagerbestand beim Aufruf einer Webseite von einem ERP System erfragen und anschließend an einen Webbrowser mitteilen.
1.2.1 Systemintegration über Organisationsgrenzen
Firewalls, mit denen sich Unternehmen vor unberechtigtem Zugriff schützen, erschweren die Integration von Systemen über Organisationsgrenzen hinweg. Der Zugriff auf das Web und auf eMail ist in den meisten Organisationen möglich. Über diese Kanäle lassen sich ganze Systeme integrieren. Nachrichten werden über HTTP oder SMTP getunnelt. Ein Standard für den Austausch von XML Botschaften oder den Aufruf von Funktionalität stellt das Simple Object Access Protocol SOAP dar.
1.2.2 Anpassen von Schnittstellen
Bei der Integration verschiedenartiger Systeme ohne gemeinsame Schnittstellen ist eine Anpassung oder Übersetzung notwendig. Die Anpassung kann in einer Middleware erfolgen, die die Formate und Konventionen der beteiligten Systeme versteht und diese übersetzen kann.
1.2.3 Anbindung an Enterprise JavaBeans Server
Anwendungen, die mit EJB realisiert wurden, können Ihre Dienste anderen Organisation über Web Services zur Verfügung stellen. Mit Hilfe von Tools können die Methoden von Stateless Session Beans über SOAP zugänglich gemacht werden.
2. Referenzen
CORBA and XML; conflict or cooperation? Beitrag von der OMG
Web Service Zone Web Services und SOAP bei IBM
