Der Titel des Artikels gibt Ihnen einen Vorgeschmack auf die folgenden Zeilen, denn EAI - also Enterprise Application Integration - ist ein hochaktuelles Thema. Für alles und jeden gibt es mittlerweile Schnittstellen, um proprietäre Systeme miteinander zu verbinden und neue Geschäftsprozesse zu realisieren. Angefangen hat das Ganze mit dem Aufkommen von XML als standardisierte Basis für den Datenaustausch. Doch der Austausch von Daten ist nicht immer das, was reicht. Vielmehr geht es im EAI Bereich auch darum, Anwendungslogik zu integrieren, um Geschäftsfunktionalitäten nicht neu entwickeln zu müssen. Datenschleudern zu integrieren ist sicherlich eine recht einfache Übung. Schnell ein paar XML-Schnittstellen in die Altsoftware eingebaut und schon steht dem applikationsübergreifenden Datenaustausch nichts mehr im Wege. Wenn man allerdings Applikationen selbst in Prozesse integrieren will, stößt man schnell an die Grenzen der existierenden Standards. Sicher kann man CORBA-basierte Anwendungen schneller integrieren als die Geschäftslogik einer DOS-Anwendung, doch auch Microsoft COM oder die BAPI-Schnittstellen von SAP wollen integriert werden und da spielen meist die nativen Bibliotheken der Plattformen eine wesentliche Rolle. Zur Integration auf Standards braucht man eine Standardarchitektur, die den aktuellen und kommenden Anforderungen gerecht wird. Für den Bereich der Integration und Neuentwicklung bietet sich momentan nur J2EE an. Für diese Architektur gibt es inzwischen eine Menge Anbieter von Applikationsservern. Auch wenn BEA und IBM diesen Markt bisher anführen, so ist die Schlacht um den Kunden noch lange nicht beendet. Es gibt einfach zu viele Aspekte in diesem Umfeld, die bisher noch nicht richtig berücksichtigt werden. Andererseits kann man bei genauerer Betrachtung der bisher gelaufenen J2EE-Projekte auch erkennen, dass viele Features noch wenig bis gar nicht genutzt werden. So ist es nicht verwunderlich, dass einige Features kaum handhabbar sind und sich Produkte trotzdem durchsetzen konnten. JBOSS beispielsweise hat mit seinem bisherigen Zuspruch der Entwicklergemeinde sehr gute Chancen, sich schnell an die Fronten zu begeben und dort signifikante Anteile zu erhaschen.

Der Standard

Der J2EE-Standard erlaubt den Entwicklern einige Dinge nicht. So beispielsweise das Laden von nativen Bibliotheken. Eine Zeit lang versuchten Entwickler dann über Socketprogrammierung eigene Services einzuhängen, die ansonsten nicht nutzbar gewesen wären. Mit der Einführung der JCA (Java Connector Architecture) wird auch dieser wichtige Punkt beantwortet. JCA fühlt sich für Entwickler so an wie JDBC, was zu einer effektiven Handhabung bei der Einbindung vorhandener Systeme führt. Das CCI (Common Client Interface) ist die Schnittstelle für Clientprogramme wie beispielsweise Enterprise JavaBeans, die damit über ein und dieselbe Schnittstelle auf vorhandene Systeme wie SAP und Siebel zugreifen können. Inzwischen gibt es einige Anbieter von JCA-Adaptern für SAP, Siebel und andere ERP und CRM-Systeme. Ein Anbieter im SAP-Umfeld ist die inzwischen aus der ProSyst AG hervorgegangene IN-Q-MY GmbH. Als hundertprozentiges Tochterunternehmen der SAP liefert IN-Q-MY einen echten zertifizierten J2EE-Applikationsserver aus. Das besondere an dem Produkt ist, dass SAP für ihren Web Application Server auch einen JCA-Adapter entwickelt hat. Über diesen Adapter ist es für die Entwicklergemeinde sehr einfach möglich, die Funktionalität von SAP in ihre J2EE-Architektur zu integrieren. Doch dazu später mehr.

Kontrollfluss und Processlayer

Wenn man verschiedene Applikationsbausteine in einen Geschäftsprozess integrieren will, stellt man sich als Entwickler schnell eine Reihe von Fragen. Verschiedene Systeme liefern verschiedene Benutzerverwaltungen mit. Also ist die erste immer wieder gestellte Frage, wie man die unterschiedlichen Loginverfahren homogenisieren und konsolidieren kann. Als weitere Frage kommt der Kontrollfluss ins Spiel. Was muss ich tun, um die gewünschten Daten von Anwendung A nach Anwendung B zu transportieren. Und welche Funktionalität muss ich aufrufen, um die gewählte Aktion auszuführen? Kann ich meinen Geschäftsprozess auch unterbrechen? Wenn ja, was muss ich tun, um später wieder aufzusetzen? Kann ich meinen Anwendern eine Liste mit Aufgaben präsentieren, die noch erledigt werden müssen, um meine Prozesse zu beenden? Diese und viele weitere Fragen sind von den EAI- Anbietern bislang unzureichend beantwortet geblieben und jeder Entwickler hat sich spätestens seit dem ersten Integrationsprojekt diese Fragen gestellt und eine eigene Lösung implementiert. Das ist nichts Ungewöhnliches, denn einen Persistenzlayer hat schließlich auch fast jeder Programmierer schon einmal entwickelt. Dabei ist die Konsequenz so logisch wie einfach und heißt Workflow. In einem weiteren Artikel gehen wir auf ähnliche Aspekte in der WebServiceswelt ein, wo Konzepte wie Workflow (Ansätze gibt es in der WSFL = WebServices Flow Language) noch nicht existieren, aber dringend gefordert sind. Momentan jedoch soll uns der Fokus auf die EAI-Ebene reichen.

Workflow == eProcess Management

Wenn heute über Workflow geredet wird, kommt schnell der schale Beigeschmack der neunziger Jahre hoch. In dieser Zeit hatten Workflowsysteme kaum mehr zu tun, als Dokumentenmanagement zu betreiben. Standards für die Integration von Systemen lagen noch in weiter Ferne. Während damals jedes Workflowsystem eine proprietäre Lösung war und Fragen nach Skalierbarkeit, Sicherheit und anderen Aspekten der verteilten Architekturen selbst beantworten musste, können neuartige Workflowsysteme viele Aufgaben an Applikationsserver delegieren und offene Standards unterstützen. Damit werden Integrationsaufwände tatsächlich minimiert und Entwickler nicht mit proprietären Schnittstellen und API alleingelassen. Daher spricht man heute weniger über Workflowsysteme sondern über Werkzeuge zum Prozessmanagement, eben eProcess Management oder Prozessintegration. Wichtig ist bei der Konsolidierung der IT-Landschaft, dass keine proprietären Ansätze verwendet werden. So ist J2EE eine Sammlung von offenen Standards, die von der Softwareindustrie voll unterstützt werden. Im Bereich von Geschäftsprozessen und dem damit verbundenen Workflowgedanken spielt die WfMC (Workflow Management Coalition) eine ganz wesentliche Rolle. Die WfMC ist vergleichbar mit der OMG und kümmert sich besonders um die Fragen des Workflows. Das was ein Workflowmanagement System laut WfMC ausmacht, sind im Wesentlichen drei Elemente:

• Eine Modellierungsumgebung für Geschäftsprozesse


• Eine Ablaufumgebung für die modellierten Prozesse


• Eine Administrationumgebung und Monitoringwerkzeuge für das gesamte Workflowsystem

Des Weiteren legt die WfMC fünf unterschiedliche Schnittstellen für Hersteller von Workflowmanagement Systemen fest (Abb.1). Dabei handelt es sich im Wesentlichen um Schnittstellen für den Datenaustausch und die Kommunikation von Systemen unterschiedlicher Hersteller. So spielt beispielsweise die Interoperabilität via XML eine wichtige Rolle. Eine andere Schnittstelle beschreibt, wie Client-Applikationen mit dem System zusammenarbeiten sollen. Des Weiteren existiert ein Metamodell zur Beschreibung von Geschäftsprozessmodellen, das die folgenden Elemente nennt: Modelle sind die Wurzeln der Geschäftsprozessmodellierung und gliedern sich in folgende Bereiche auf:

• Prozesse


• Applikationen


• Daten


• Ressourcen

Prozesse beschreiben den eigentlichen Geschäftsprozess als wieder verwendbare Einheit der technischen Abpictureung von Abläufen in einem Unternehmen. Ein Prozessablauf wird beschrieben durch seine Aktivitäten und den Übergängen (Transitionen) zwischen diesen Aktivitäten. Aktivitäten sind die atomaren Arbeitseinheiten innerhalb eines Prozesses. Für jede Aktivität wird eine verantwortliche Ressource festgelegt. Eine Aktivität kann sein:

• eine "manuell" ausgeführte Tätigkeit


• ein ausgeführtes Programm


• ein (Unter-)Prozess


• eine Schleife


• eine "Dummy"-Aktivität, die der Synchronisation von Arbeitsschritten dient

Transitionen beschreiben Übergänge zwischen Aktivitäten. Jede Transition "trägt" eine Bedingung für die Daten des Prozesses. Ist die Bedingung nach Ausführen der Aktivität von der die Transition ausgeht erfüllt, so wird die Transition durchlaufen. Applikationen werden in Aktivitäten aufgerufen, wobei eine Applikation von mehreren Aktivitäten aufgerufen werden kann. Die Eingangs- und Ausgangsparameter der Applikation müssen aus den Daten des Prozesses bestimmt werden. Daten sind die durch die Aktivitäten eines Prozesses bearbeiteten Geschäftsdaten sowie Steuerdaten des Prozesses. Sie können von primitivem Typ (Integer, String) sein oder vom Typ einer Referenz auf komplexere Daten. Ressourcen führen Aktivitäten aus und können sein:

• Mitarbeiter,


• Geräte oder


• Gruppen von Ressourcen

Diese Workflowbegriffe sind bei der WfMC standardisiert und sind keine proprietären Dinge. Verwendet man diese Begriffe für die Beschreibung von Geschäftsprozessen, können leicht Schätzmodelle für Entwicklungsprojekte entwickelt werden. Außerdem können Aktivitäten als Einstiegspunkte für Komponenten sein, so dass eine Aktivität ein Arbeitsschritt einer Komponente sein kann. Dabei können eben auch die verwendeten Applikationen integriert und so transparent für den Benutzer aufgerufen werden.

eProcess Management in der Entwicklung

Die zuvor beschriebenen Elemente von Geschäftsprozessmodellen sind für Entwickler nichts wirklich Unbekanntes. Diese Begriffe wurden lediglich nicht immer konsequent angewendet. Da ist es kein Wunder, wenn die Fachleute und Entwickler oft genug aneinander vorbei geredet haben. Mit dem gleichen Vokabular lässt es sich ja bekanntlich viel einfacher arbeiten und fachliche Fehler werden weitgehend ausgeschlossen. Als Entwickler hat man die Wahl zwischen zwei Ansätzen, um diese Workflowkonzepte in verteilten Anwendungen zu realisieren. Die eine Möglichkeit ist das Selbermachen. Damit muss der Entwickler die einzelnen Komponenten quasi miteinander verkleben. Die Programmierarbeit liegt also auf der Ebene der Semantik. Für den Kontrollfluss wird also Code geschrieben, der den Prozessablauf festlegt. Bei Änderungen am Prozessablauf müssen allerdings folgende Bedingungen erfüllt sein, damit diese Art der Realisierung Erfolg bringt:

• Der Quellcode für den Klebcode muss vorhanden sein


• Es muss jemanden geben, der diesen Code auch versteht


• Ein Wartungsprojekt wird aufgesetzt


• Ein neues Release wird in die Produktion überführt

Je nachdem wie komplex und häufig diese Änderungen in Abläufen vorkommen, desto schwieriger und teurer wird so ein Vorhaben. Die Alternative ist der Einsatz eines auf J2EE-basierenden eProcess Management-Produktes. Mit generischen Schnittstellen ist so ein Produkt branchenneutral und anwendungsunabhängig einsetzbar. In einer der nächsten Ausgaben werden wir das Produkt CARNOT Process Engine vorstellen, das über die genannten Schnittstellen verfügt und die Umsetzung von Geschäftsprozessen auf Modellierungsebene ermöglicht. Damit betreffen Änderungen am Prozessablauf lediglich Änderungen am Modell. Die neue Version der Prozesse kann dann in die Laufzeitumgebung eingespielt werden, ohne den Produktionsbetrieb zu unterbrechen. Doch dazu mehr in einer der nächsten Ausgaben.

JCA

Um die heterogenen Systeme und Anwendungen in die neue Welt der Enterprise JavaBeans zu überführen, gibt es, wie bereits weiter oben beschrieben, die JCA (Java Connector Architecture). In der nächsten Ausgabe zeigen wir, wie mit JCA ein SAP-System in die J2EE-Welt integriert werden kann. Dabei geht es direkt ans Eingemachte, denn jeder kann ein einfaches SAP-System auf seinem Rechner installieren und die Integration durchführen. Mehr wird aber noch nicht verraten. JCA ist die Architektur, die es erlaubt auch native Ressourcen in die Umgebung eines Applikationsservers zu integrieren. Dabei besteht JCA eigentlich aus zwei Teilen:

• Einem containerseitigen Teil


• Einem clientbezogenen Teil

Für den Client gibt es das CCI (Common Client Interface), mit dem Entwickler so arbeiten, als wären sie bei JDBC und Co. zuhause. Eine ConnectionFactory liefert Verbindungen zu Backendsystemen, die der Client nutzen kann, um ResultSets abzufragen. Vom Prinzip her läuft jeder Funktionsaufruf über CCI gleich, weshalb es sich anbietet diesen generischen Ansatz mit in eine Workflowumgebung aufzunehmen. Praktisch müssen die Eingabeparameter für einen Funktionsaufruf gesetzt werden und dann die Funktion selbst ausgeführt werden. Die ResultSets enthalten nach der Ausführung dann die Rückgabewerte, die man wiederum auslesen und verwerten kann. Auf diese Art und Weise lassen sich sehr einfach die unterschiedlichsten Backendsysteme miteinander verbinden. Eine CRM-Anwendung kann so mit vielen verschiedenen Kundenverwaltungen und Auftragsbüchern verknüpft werden, ohne dabei auf die proprietären Schnittstellen des unterliegenden Systems zurückgreifen zu müssen.

EAI = J2EE + JCA + eProcess Management

Zusammengefasst bedeuten alle diese Technologien nichts anderes als Enterprise Application Integration (Abb. 3). J2EE ist dabei die Ablaufarchitektur mit Features wie Transaktionalität, Sicherheit und Skalierbarkeit. Die JCA-Adapter bieten die notwendige Connectivity zu heterogenen Systemen hin. Und eProcess Management ist die Summe aus Prozessdefinition und Ablaufumgebung auf Basis offener Standards. eProcess Management steuert den Kontrollfluß zwischen den Aktivitäten, die wiederum an Applikationen gebunden sind. Im nächsten Teil der Artikelreihe zu Prozessintegration geht es um die Integration von SAP in eine J2EE- Umgebung. Wenn Sie Anregungen zum Thema haben, schreiben Sie uns.

Dipl.-Ing. Michael Johann ist Vorstandsvorsitzender der CARNOT AG und als Java-Experte über die Grenzen von Europa hinaus bekannt. Als ehemaliger Chefredakteur und Mitgründer von JavaSpektrum widmet er sich heute dem Bereich Enterprise Java. Email: mjohann@carnot.ag