Enterprise Application Integration Entwicklung einer Integrationsplattform mit der Java Connector Architecture

Transkript

1 Enterprise Application Integration Entwicklung einer Integrationsplattform mit der Java Connector Architecture Studienarbeit im SS 2001 bei Prof. Manfred Bues an der Fachhochschule Furtwangen Hochschule für Technik und Wirtschaft Fachbereich Wirtschaftsinformatik vorgelegt von Richert, Jürgen Matrikelnr.: Furtwangen, den 18. August 2001

2 Abstract Bei Enterprise Application Integration handelt es sich nicht um ein neues Zauberwort der Unternehmensberater sondern um ein konkretes Konzept zur systematischen Integration vorhandener IT-Systeme. Die Verwendung von Produkten anstatt von Eigenentwicklungen, moderne Infrastruktursoftware in Form von Middleware und die Etablierung von Standards ermöglichen die Vernetzung der verteilten und isolierten IT-Systeme und die Schaffung einer ganzheitlichen Unternehmensanwendung. Ziel dieser Studienarbeit ist die Entwicklung eines konkreten Konzepts auf der Basis modernster Erkenntnisse aus dem Bereich der Enterprise Application Integration unter der Verwendung der Java Connector Architecture und CORBA. Die Integrationsplattform beruht auf zwei Konzepten, die im Rahmen dieser Arbeit entwickelt werden. Das Enterprise Process Interface ist eine Weiterentwicklung des Method-Warehouse Gedankens und ist die Basis für eine regelbasierte Verarbeitung von Geschäftsvorfällen. Der Enterprise Communication Adapter ist eine Weiterentwicklung der Java Connector Architecture im Sinne einer CORBA-basierten Middleware. Es wird eine kurze Einleitung in das Thema geboten, gefolgt von einigen, für das Verständnis relevanten Grundlagen. Anschließend wird die Java Connector Architecture und das ihr zugrundeliegende Adapterpattern vorgestellt. Im letzten Kapitel wird die Konfiguration der Architektur entwickelt und die Komponenten der Integrationsplattform zusammengestellt.

3 INHALTSVERZEICHNIS 1 EINLEITUNG Historie Business-driver und Definition Die ganzheitliche Integration verteilter, heterogener Systeme GRUNDLAGEN Szenario Integrationsebenen Definitionen Middleware Application Server JAVA CONNECTOR ARCHITECTURE Der Adapter Designpattern nach Gamma et al Architekturpattern: das Integration Adapter Pattern Connector Architecture System Contracts Connection Management Transaction Management Security Management Common Client Interface Bewertung im Kontext der EAI DIE INTEGRATIONSPLATTFORM Voraussetzungen Vorgehensweise: Evolution statt Revolution Enterprise Process Interface Enterprise Communication Adapter Metadatenmanagement Rules Processing Übersichtsgrafik: Die Integrationsplattform Die Zukunft...29

4 ABSTRACT... 2 ABKÜRZUNGSVERZEICHNIS...31 LITERATURVERZEICHNIS ABBILDUNGSVERZEICHNIS... 33

5 Einleitung Einleitung 1.1 Historie Integration ist ein Thema, welches die IT schon seit ihrem Bestehen begleitet. Im Unternehmensbereich und ausschließlich damit werden wir uns befassen gibt es schon immer zwei unterschiedliche Kategorien von Softwaresystemen: Legacy Applications Packaged Applications Unter Legacy Applications werden Anwendungen verstanden, die unternehmensintern von der IT-Abteilung in der Vergangenheit entwickelt wurden. Unter Packaged Applications werden zugekaufte Produkte von Drittanbietern verstanden. Spätestens mit den immensen Investitionen in ERP-Systeme ist die Integration zur Daueraufgabe geworden. Legacy und Packaged Applications müssen im heterogenen Unternehmensnetzwerk miteinander über verschiedenste Hardwarearchitekturen, Plattformen, Schnittstellen und Protokolle hinweg kommunizieren. Die zugrundeliegenden Architekturen in den unternehmensweiten IT-Landschaften sind organisch gewachsen. Meist ungeplant und problemorientiert. Aufgrund des immer bestehenden Zeitdrucks wurden ad-hoc Punkt-zu-Punkt Verbindungen zwischen den Systemen erstellt. Mit dem Fortschreiten der Entwicklung und der Zeit ergeben sich aus dieser sogenannten vollvermaschten Architektur die folgenden Probleme durch die wachsende Zahl n der im System aktiven Knoten: Die Zahl der benötigten Koppelelemente steigt exponentiell mit n*(n-1)*2. Für jede Punkt-zu-Punkt Kombination muss der Entwickler zwei Systeme beherrschen. Abbildung 1 Die vielfältigen Abhängigkeiten in einem vollvermaschten System 1. Jede Änderung eines Systems zieht schlechtestenfalls (n-1) Änderungen in den korrespondierenden Koppelelementen nach sich. Abbildung eins zeigt die vielfältigen Abhängigkeiten in einem vollvermaschten System. 1 Nußdorfer 2001, S. 90

6 Einleitung Business-driver und Definition Da die Abhängigkeit der Unternehmen von ihrer IT-Infrastruktur und den darauf abgebildeten Prozessen wächst, nimmt der Bedarf zur Vereinheitlichung der Geschäftsprozesse stark zu. Nachdem Generationen von Managern und Entwicklern aufgrund von Zeitdruck und mangelnder Integrationssoftware Anwendungsinseln produziert haben, erwacht heute der Bedarf alle unternehmensweiten Anwendungen zu einer ganzheitlichen Unternehmensanwendung zu verschmelzen. Dieser Bedarf begründet sich nicht auf einem plötzlichen Sinn für Ästhetik sondern aus konkreten Zwängen des Wettbewerbs. Es geht nicht nur um die Reduzierung von Kosten, sondern um den Mehrwert für die Unternehmung der durch eine ganzheitliche Unternehmensanwendung geschaffen werden kann. Denn nur wer seine Anwendungen unternehmensweit integriert hat, kann sie auch mit Geschäftspartnern und Kunden integrieren. Enterprise Application Integration (EAI) befasst sich zunächst mit der Application-to- Application Integration, welche eine Vorraussetzung für alle Wettbewerbsvorteile bildet, die durch Business-to-Business und Business-to-Consumer Geschäftsmodelle geschaffen werden können. Business-driver für diese Entwicklung sind Supply Chain Management, Customer Relationship Management, e-marketplaces usw. Enterprise Application Integration ist nach Ruh folgendermaßen definiert: Enterprise Application Integration is the creation of business solutions by combining applications using a common middleware. 2 Diese Definition greift nicht sehr exakt und ich möchte sie deswegen erweitern: Enterprise Application Integration is the creation of value-added business solutions by combining existing applications using a common middleware and extended application servers which reduce the complexity of the task by reducing the interfaces within the system. 1.3 Die ganzheitliche Integration verteilter, heterogener Systeme Die Komplexität bei der Integration der unternehmensweiten IT-Landschaft lässt sich nur durch die Minimierung der Schnittstellen beherrschen. Alle weiteren Konzepte ordnen sich diesem Konzept unter. Untergeordnet sind die Kategorien Wiederverwendung, Standardisierung und die Beseitigung von Abhängigkeiten. Diese Kategorien werden nun auf die Enterprise Application Integration heruntergebrochen. Wiederverwendung lässt sich durch die Integration auf Funktionsebene 3 erreichen. Durch die Kapselung der Anwendungslogik und der Vermeidung eines direkten Zugriffs auf die Da- 2 Ruh 2001, S. 2

7 Einleitung tenbank, werden die Systeme transparent, organisiert und wiederverwendbar im Bezug auf die Anwendungslogik. Standardisierung ist das Mittel zur Produktivitätssteigerung bei EAI Vorhaben. Standardisierungen tragen maßgeblich dazu bei, dass Entwickler in allen Bereichen sich immer mehr auf ihre wesentlichen, fachlichen Aufgaben konzentrieren können. Basisfunktionalitäten werden von Drittanbietern hinzugekauft (Third Party Produkte). Eigenentwicklungen werden sorgfältig geplant und mit Hilfe von Entwurfsmustern designt und implementiert. Im Rahmen der EAI meint die Beseitigung von Abhängigkeiten das Einführen eines Common-Point-of-Reference und das Decoupling bestehender Anwendungen. Der Common- Point-of-Reference reduziert die Komplexität des Gesamtsystems wesentlich. Alle Anwendungen mappen ihre Datenstrukturen Wiederverwendung Integratin auf Funktionsebene Third-Party-Produkte Minimierung der Schnittstellen Standardisierung Entwurfsmuster Common-Point-of Reference Beiseitigung von Abhängigeiten Decoupling Abbildung 2 Komplexitätsreduzierung durch Schnittstellenminimierung und Interfaces nur noch gegen eine zentrale Instanz, dadurch steigt die Komplexität mit dem Hinzufügen neuer Elemente in das System nur noch linear. Decoupling heißt Technologien, Implementierungsmethoden und Vorgehensweisen einzusetzen, welche die gegenseitigen Kenntnisse, die die Anwendungen voneinander haben müssen, verringern. Optimalerweise sollte ein System definierte Schnittstellen und Datenformate zur Verfügung stellen und über geeignete Middleware kommunizieren können, ohne von der konkreten Existenz anderer Anwendungen etwas zu wissen. 3 Siehe dazu Kapitel 2.2

8 Grundlagen Grundlagen Im folgenden werden verschiedene Integrationsszenarien vorgestellt und dabei die Enterprise Application Integration von anderen Szenarien abgegrenzt. Anschließend werden die drei Integrationsebenen, die Integration auf Daten-, Benutzerschnittstellen- und Funktionsebene diskutiert und ihre Vor- und Nachteile analysiert. Es folgen weitere wichtige Merkmale von integrierten IT-Systemen. Kapitel 2.4 und Kapitel 2.5 befassen sich mit der EAI Infrastruktur, der Kommunikations- und der Funktionsinfrastruktur. 2.1 Szenario Bei den vielen, heute gebräuchlichen, sog. Buzzwords ist es schwierig geworden die Begrifflichkeiten und deren Bedeutung zu unterscheiden. Was versteht man unter e-business, was unter e-commerce? Es gibt keine eindeutigen Definitionen. Im Rahmen dieser Arbeit unterscheiden wir unter anderem nach der wirtschaftlichen Ausdehnung der Lösung und bilden die Kategorien Application-to-Application Integration, Business-to-Business Integration und Business-to-Consumer Integration. Application-to-Application Integration war schon immer ein Thema für die IT. Im Unterschied zu früher, werden nun aber die Anforderungen an die Lösungen immer anspruchsvoller und Punkt-zu-Punkt Lösungen mit der Folge einer vollvermaschten Architektur 4 sind nicht mehr akzeptabel. Heutige B2C Lösungen erfordern, dass die Schritte A2A und B2B bereits abgeschlossen sind. Als Application-to-Application Integration wird somit die Zusammenführung der IT- Systeme eines Unternehmens zur Lösung interner Integrationsaufgaben bezeichnet. Um moderne Lösungen von den früheren ad-hoc Punkt-zu-Punkt Lösungen abzugrenzen wird dieses Szenario als Enterprise Application Integration bezeichnet. Business-to-Business Integration ist der zweite Schritt nach einer erfolgreichen EAI. Dabei wird Partnerunternehmen der Zugriff auf die internen Anwendungen über wohldefinierte Schnittstellen gewährt. Optimalerweise sieht der jeweilige Partner die vielfältigen IT-Systeme nur über eine zentrale, konsistente Schnittstelle er sieht nur eine Unternehmensanwendung. 4 Siehe Abbildung 1

9 Grundlagen Abbildung 3 Ein B2C Szenario. Die kleine Elipse zeigt das A2A, die mittlere das B2B und die große das B2C Szenario. Noch einen Schritt weiter geht die Business-to-Consumer Integration. Darunter versteht man die Öffnung der Systeme nicht nur den Geschäftspartnern gegenüber, sondern auch gegenüber den eigenen Kunden. 2.2 Integrationsebenen Die Integration von Anwendungen kann an drei Stellen angesetzt werden, an der Daten-, der Funktions- und der Schicht der Benutzerschnittstelle. Das oberste Ziel der Integration ist die gegenseitigen Abhängigkeiten so gering wie möglich zu halten. Man spricht von sogenanntem loose coupling, wenn die Abhängigkeiten gering und von sogenanntem tight coupling, wenn die Abhängigkeiten stark sind. Je stärker die Abhängigkeiten zwischen den Anwendungen sind, desto komplexer und aufwändiger ist deren Wartung 5. Auf welchem Level die Integration einer Anwendung ansetzen muss, ist stark vom Kontext abhängig und nicht verallgemeinerbar. Auf die Vor- und Nachteile wird im folgenden eingegangen. In der Literatur finden sich weitere Integrationsebenen 6. Sie sind hier nicht aufgeführt, da sie keine neuen Erkenntnisse beinhalten, sondern die hier genannten Ebenen lediglich unter einem anderen Blickwinkel betrachten oder zusätzliche Services mit einbeziehen, die bei einer rein analytischen Betrachtung keine Rolle spielen. Die EAI auf der Ebene der Benutzerschnittstelle 7 ist weitgehend erforscht. Es existieren Standardadapter für nahezu alle Terminals. Die Idee ist, lediglich bereits vorhandene Benutzerschnittstellen in einer neuen Benutzerschnittstelle zusammenzufassen. Z.B. zwei Terminalan- 5 Ruh 2001, S Linthicum 1999, Nußdorfer Ruh 2001, S. 22ff.

10 Grundlagen wendungen, welche auf einem Mainframe laufen, werden unter einem neuen Web-Frontend zusammengefasst. Dabei wird die Integrationslogik in einer neuen Schicht implementiert und die älteren Terminalanwendungen meist über Screen-Scrapping Verfahren angesteuert. Vorteile Integration in kurzer Zeit Verfahren weitestgehend erforscht Gut dokumentiert / selbsterklärend Nachteile Nur bereits definierte Prozesse können integriert werden Performance Auf unterliegende Businesslogik und Daten kann nicht zugegriffen werden Gute Auswahl an Tools Die EAI auf Datenebene 8 beschäftigt sich hauptsächlich mit den Techniken und Technologien, welche zum Datenaustausch zwischen Datenbanken eine Rolle spielen. Die grundsätzliche Vorgehensweise ist sehr einfach: 1. Lesen der Daten aus einer Datenbank. 2. Verarbeiten der Daten. 3. Speichern der Daten in einer Datenbank. So einfach diese Vorgehensweise klingt, so komplex wird sie, sobald einige hundert Datenbanken mit mehreren tausend oder zehntausend Tabellen betroffen sind. Nichtsdestotrotz ist die Integration auf Datenebene eine der meistverwendeten Vorgehensweisen und hat mit der Schaffung der extensible Markup Language (XML) wieder stark an Bedeutung gewonnen 9. Die breite Akzeptanz von XML wird die Integration speziell im B2B Bereich beschleunigen. Sobald Formate und Semantiken standardisiert und etabliert sind, wird die ad-hoc Kommunikation zumindest auf Datenebene zwischen Anwendungen möglich, die nie zuvor in irgendeiner Weise aufeinander angepasst wurden! 8 Linthicum 2001, S. 27f. 9 Linthicum 2001, S. 37ff.

11 Grundlagen Vorteile Zugriff auf alle Daten Integration in kurzer Zeit Performance Nachteile Geschäftslogik muss jedes mal neu implementiert werden Gefahr der Dateninkonsistenz Bei Änderung der Datenstruktur müssen alle angekoppelten Anwendungen angepasst werden Ein bedeutender Teil der IT-Budgets wird für die Implementierung und Wartung von Businesslogik ausgegeben. Die Businesslogik-Implementierungen enthalten die Regeln, um die Daten der Anwendungen zu interpretieren, zu erzeugen und zu verändern. Die eleganteste Art der EAI ist somit die EAI auf Funktionsebene 10. Dabei werden die Application Programming Interfaces (API) der Anwendungen genutzt oder speziell zu Integrationszwecken welche geschaffen. Vorteile Performance Flexibilität Stabilität Nachteile Komplexität Integration dauert länger Auf Sourcecode oder eine dokumentierte API angewiesen Hoher Grad an Wiederverwendbarkeit Konsistenz 2.3 Definitionen Es gibt zwei Arten von Kommunikationsmodellen die bei der Integration unterschieden werden müssen: synchrone und asynchrone Kommunikation 11. Unter synchroner Kommunikation wird die Kommunikation zwischen zwei oder mehreren Partnern verstanden, die stark miteinander gekoppelt sind. Die Anwendung, welche synchron eine Methode in einer anderen Anwendung aufruft, stoppt die eigene Verarbeitung bis sie eine Antwort erhält. Synchrone Kommunikation wird immer dann gebraucht, wenn die realtime Anforderungen sehr hoch oder eine direkte Antwort auf einen Request erwartet wird. Unter asynchroner Kommunikation wird die Kommunikation zwischen zwei oder mehreren Partnern verstanden, die nur schwach miteinander gekoppelt sind. Die Infrastruktur, wel- 10 Ruh 2001, S. 27ff. 11 Linthicum 2000, S. 132

12 Grundlagen che eine asynchrone Kommunikation zur Verfügung stellt, löst somit nahezu jede Abhängigkeit zwischen der Quell- und der Zielanwendung auf. Die sendende Anwendung muss mit der Verarbeitung nicht anhalten, da sie keine direkte Antwort auf ihre Nachricht erwartet. Ein nur a- synchron arbeitendes System ermöglicht es somit allen Anwendungen unabhängig von dem Zustand der Anderen im System die Verarbeitung fortzuführen. Messaging, Interface Definition und Connectoren 12 sind die drei Methoden zur Übermittlung von Informationen von einer Anwendung zur Anderen. Messaging bedeutet, dass die Quellanwendung eine Nachricht an die Zielanwendung verschickt, die sowohl die Daten als auch die Verarbeitungsanweisungen für die Daten enthält. Eine Nachricht könnte somit eine vollständige Anschrift enthalten und die Anweisung, diese Anschrift als neuen Kunden in die Kundendatenbank einzufügen. Interface Definition bedeutet, dass die Zielanwendung eine wohldefinierte Schnittstelle anbietet und die Quellanwendung dieses Interface zur Übermittlung von Daten und zum Anstoßen von Prozessen in der Zielanwendung nutzt. Die Aufgabe eines Connectors oder auch Adapters ist es, einen Zugriff auf die dahinterliegende Anwendung auf strukturierte Art zur Verfügung zu stellen. Der Adapter verbirgt die Komplexität der Nachrichtentransformation oder des Schnittstellenmappings zum Zugriff auf die dahinterliegende Anwendung vor der zugreifenden Anwendung. 2.4 Middleware Middleware ist eine Software, welche die Kommunikation mehrerer Softwarekomponenten miteinander durch den Einsatz von wohldefinierten Schnittstellen und Nachrichtenformaten stark vereinfacht. Middleware stellt die Laufzeitumgebung zur Verwaltung der Requests zwischen den Softwarekomponenten zur Verfügung 13. Im Rahmen der Enterprise Application Integration ist Middleware die Kommunikationsinfrastruktur der Lösung. Sie lässt sich in die folgenden keinesfalls analytischen aber historischen - Kategorien 14 einteilen: Remote Procedure Calls Database Access Middleware Message Oriented Middleware Distributed Object Technology Transaction Processing Monitors 12 Ruh 2001, S. 49ff. 13 Nach Ruh 2001, S Ruh 2001, S. 53

13 Grundlagen Middleware ist zum Werkzeug, zu einer Komponente innerhalb einer Enterprise Application Integration geworden. Die Herausforderungen der EAI liegen nicht mehr in der technischen Verbindung zweier Anwendungen, sondern in der Integration auf Prozessebene. Um diese Aufgabe bewältigen zu können, muss auf spezielle Tools zurückgegriffen werden. Middleware ist die Infrastruktur auf die diese Tools aufsetzen. Der Unterschied zwischen Middleware und klassischen Interprozess- Kommunikationsmechanismen ist die physisch getrennte Lokalität der beteiligten Softwarekomponenten. Während auf einem physischen System zwei Softwarekomponenten mit den Mitteln des Betriebssystem verbunden werden können, z.b. über Shared Memory oder Pipes, ist dies über mehrere physische Systeme hinweg nur über Netzwerkprotokolle möglich. Ob Remote Procedure Call oder Message Oriented Middleware, die Vorgehensweise ist immer die Gleiche: Standardisierung eines gemeinsamen Protokolls zur Kommunikation über ein Netzwerk. Es folgen die Definitionen der Middlewarekategorien nach Ruh 15. Remote Procedure Calls ist eine Middleware, welche mit dem Ziel entwickelt wurde, verteilte Anwendungen auf Funktionsebene integrieren zu können. Remote Procedure Calls ist ein Protokoll, um Methodenaufrufe über ein Netzwerk hinweg zu ermöglichen. Database Access Middleware ist eine Middleware, welche mit dem Ziel entwickelt wurde, auf verteilte Datenbestände in Dateien wie auch in Datenbanken zuzugreifen und auf Datenebene zu integrieren. Database Access Middleware erlaubt das absetzen von Abfragen und das Verschieben von Daten über ein Netzwerk hinweg. Message Oriented Middleware 16 ist eine Middleware, welche mit dem Ziel entwickelt wurde, einige Nachteile der Remote Procedure Calls durch die Benutzung von Nachrichten auszugleichen. Message Oriented Middleware benutzt Informationseinheiten auf Byteebene, welche über ein Netzwerk hinweg verschickt werden können. Zusammengehörende Einheiten werden als Nachrichten bezeichnet und bestehen aus den zu transferierenden Daten und den zugehörigen Verarbeitungsanweisungen. Die Verarbeitungsanweisungen sind unabhängig von einer bestimmten Anwendung. Distributed Object Technology ist eine Middleware, welche mit dem Ziel entwickelt wurde, die Konzepte des objekt-orientierten Paradigma auf die verteilte Verarbeitung anzuwenden. Distributed Object Technology basiert auf Remote Procedure Calls, arbeitet jedoch mit Nachrichten an Objekten anstatt dem Aufruf zustandsloser Methoden in einem prozeduralen System. Transaction Processing Monitors ist eine Middleware, welche mit dem Ziel entwickelt wurde, die Integrität einer Transaktion sicherzustellen. Konnte man früher die Middleware Produkte noch nach den Kategorien einteilen, besteht heute eine starke Konvergenz zwischen ihnen. Eine Art Produktintegration hat stattgefunden und eine neue Art von System hervorgebracht, den Application Server. 15 Ruh 2001, S. 53ff. 16 Nach Linthicum 2001, S. 138f.

14 Grundlagen Application Server Ein Application Server ist ein Softwaresystem, welches eine Laufzeitumgebung für andere Softwaresysteme zur Verfügung stellt. Ein Betriebssystem ist ebenfalls eine solche Laufzeitumgebung, der Application Server bietet jedoch zusätzliche Services auf einem höheren Level an. Fehlertoleranz, Loadbalancing, Quality-of-Service, Transactionmanagement u.v.m. Entsprechend aufgerüstet und mit den nötigen Tools integriert, wird diese Laufzeitumgebung schnell zur Entwicklungsplattform für Anwendungen. Moderne Application Server zeichnen sich neben den umfangreichen Services dadurch aus, dass sie Adapter mitbringen, um auf vielfältige Back-End-Systeme und Protokolle zugreifen zu können. Das heißt auch: Zugriff auf Middleware. Der Application Server fügt sich somit auf einer neuen Ebene in die Anwendungsarchitektur ein. Er ist selbst Middleware und doch ist seine Hauptaufgabe die verschiedenen Middlewarekategorien miteinander zu verbinden. Im Rahmen der Enterprise Application Integration ist der Application-Server die Funktionsinfrastruktur der Lösung. Ein Application Server hostet zentral die Anwendungslogik und ist Common-Point-of- Reference beim EAI Vorhaben. Mit entsprechenden zusätzlichen, EAI-spezifischen Services ausgestattet und mit zusätzlichen Komponenten wie einem Metadatenrepository, wird der Application Server zum Integration Server, dem Herzstück der Integrationsplattform.

15 Java Connector Architecture Java Connector Architecture 3.1 Der Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces. 17 Die Definition von Gamma et al. ist auch im Kontext der Enterprise Application Integration gültig. Die bestechende Logik und Einfachheit des Adapterkonzepts macht es zu einem weitverbreiteten Entwurfsmuster. Die Philosophie des Adapters ist es, zwei Komponenten miteinander arbeiten zu lassen, die dazu eigentlich nicht in der Lage sind. Bildlich gesprochen ist der Steckeraufsatz für italienische Steckdosen zur Benutzung deutscher Geräte ein gutes Beispiel für einen hervorragenden Adapter. Die Schwierigkeit der Adapterentwicklung liegt im Detail. Wie viel der Funktionalität der Komponente soll über den Adapter zugänglich sein, wie viel Wissen muss die andere Komponenten über das Innenleben der Komponente haben, um den Adapter zu benutzen? Die Java Connector Architecture (JCA) ist eine Spezifikation die genau hier eine Abgrenzung vornimmt, um jegliche Art von Enterprise Information System mit einem J2EE konformen Application Server zusammenarbeiten zu lassen Designpattern nach Gamma et al. Das Adapterdesignpattern 19 nach Gamma et al. ist ein wiederverwendbares Design, ein Entwurfsmuster. Gamma et al. unterscheiden zwischen einem Class Adapter und einem Object Adapter. In Abbildung vier ist das UML Diagramm des hier relevanten Object A- dapter zu sehen. Abbildung 4 UML Diagramm des Adapterpatterns Gamma 1995, S Gamma 1995, S. 141

16 Java Connector Architecture Folgende Aufgaben werden von den Beteiligten übernommen: Target Definiert das vom Client erwartete Interface. Client Arbeitet mit Objekten zusammen, die das Target Interface unterstützen. Adaptee Definiert ein bereits bestehendes Interface. Diese Klasse soll adaptiert werden. Adapter Implementiert das vom Client erwartete Interface und integriert die Funktionalität von A- daptee. Aus dem UML Diagramm wird ersichtlich, dass unter dieser Funktionalität auch von einem Wrapper gesprochen werden kann. Eine Klasse oder auch eine Komponente wird wiederverwendbar, wenn die Vermutungen, die andere Komponenten über die Benutzung des Interfaces machen müssen, geringer werden. Sind diese Vermutungen gering, so handelt es sich um einen Pluggable Adapter. Resourceadapter im Sinne der Java Connector Architecture sind Pluggable Adapter Architekturpattern: das Integration Adapter Pattern Das Konzept des Adapterdesignpatterns lässt sich hinauf zu einem Adapterarchitekturpattern skalieren. Ein Architekturpattern beschreibt das grundlegende, strukturelle Organisationsschema für Softwaresysteme. Es stellt eine Menge von vordefinierten Subsystemen zur Verfügung, bestimmt ihre Abhängigkeiten und beinhaltet Regeln und Richtlinien, um diese Abhängigkeiten zu verwalten. 20 Die Adapterarchitektur hat die gleichen Ziele wie das entsprechende Designpattern. Innerhalb der Softwarekomponenten einer Adapterarchitektur muss somit implizit das Adapterdesignpattern verwendet werden. Client Application Plugin Integration Adapter client-side server-side (Adapter) Enterprise Information System Das Ziel jeder Integration mit Adaptern auf Architektur- wie auch auf Designebene ist die Koppelung der Systeme stark zu verringern (Decoupling). Common Client Interface Adapter Interface (Target) EIS-specific Interface (Adaptee) Abbildung 5 Architektur des Integration Adapter Pattern. Abbildung fünf beschreibt das grundlegende, strukturelle Organisationsschema der Adapterarchitektur 21. Wichtig für die Hauptaufgaben Wieder- 19 Gamma 1995, S. 139ff. 20 Siehe dazu Lutz Siehe dazu Lutz 2000; Mowbray 1997, S. 121ff.

17 Java Connector Architecture verwendbarkeit und Integration mit anderen Enterprise Information Systems (EIS) ist die unternehmensweit gültige Definition der Clientschnittstelle und der Adapterschnittstelle. Dadurch wird ermöglicht, dass sich jede Unternehmensanwendung an jeden Application-Server und jeder ausgerüstete Application-Server an das EIS anschließen kann. Diese beiden Schnittstellen sind technischer Natur, es werden und können keine Standardschnittstellen zur Behandlung der Geschäftsvorfälle definiert werden. Definiert werden Kommunikations-, Sicherheits-, Transaktions-, Verbindungs-, Zugriffs- und Metadatenschnittstellen. Ein Beispiel wäre eine festdefinierte Schnittstelle zum unternehmensweiten Connectionpooling. D.h. jedes EIS mit Adapter wird vom Application Server bei der Einrichtung des Connectionpooling genau gleich behandelt. Die Umsetzung der allgemeinen Schnittstelle auf die Spezifika des EIS übernimmt der serverseitige Teil des Integrationsadapters. 3.2 Connector Architecture Die diesen Kapiteln zugrundeliegende Spezifikation der Java Connector Architecture 22 hat die Version 1.0 und den Status eines proposed final Draft #2 im Rahmen des Java Community Process 23. Die Java Connector Architecture basiert auf dem Adapterpattern. Die Schnittstellen sind nach dem Designpattern, die übergeordnete Architektur nach dem Architekturpattern entworfen. Über diese Abstraktion hinaus, spezifiziert die Connector Architecture ein Common Client Container Component Contract Application Server Application Component Application Contract Connection Manager System Contract Resource Adapter Transaction Manager Security Manager EIS specific Interface Enterprise Information System Connection Management Security Management Transaction Management Abbildung 6 J2EE Connector Architecture Überblick Interface für den Zugriff auf den sog. Resourceadapter, dem Adapter des spezifischen Enterprise Information Systems. Es werden Schnittstellen zu technischen Verfahren der Kommuni- 22 Sharma

18 Java Connector Architecture kation festgelegt. Der Umfang des Wissens, welches der Client besitzen muss, um den Adapter zu nutzen, wird in den sog. System Contracts festgelegt. Das Wissen, welches der Client besitzen muss, um Prozesse im EIS anzustoßen und Daten auszutauschen, wird im Application Contract festgehalten. Im Rahmen der J2EE Architektur werden Komponenten - Enterprise Java Beans in einem Container auf dem Application Server ausgeführt. Die Schnittstellen, welche der Container anbieten und welche die Komponenten implementieren müssen, sind im Container Component Contract festgehalten. Resourceadapter sind EIS-spezifische Komponenten, die es einem Application-Server ermöglichen mit dem spezifischen EIS zu kommunizieren. Sie ermöglichen Anwendungen, die auf dem Application-Server laufen, das entsprechende EIS anzusprechen. Ein Application- Server und ein EIS arbeiten so zusammen, dass alle Mechanismen auf Systemebene Transaktionen, das Security und Connectionmanagement für die Anwendungskomponenten transparent bleiben. Der Anwendungsentwickler kann sich auf die Implementierung der Geschäftsund Präsentationslogik konzentrieren und muss sich nicht um die Probleme der Integration auf Systemebene kümmern. Dies führt zu einem schnelleren und einfacheren Entwicklungsprozess für skalierbare, sichere, transaktionale Unternehmensanwendungen im Rahmen einer Enterprise Application Integration. 3.3 System Contracts Connection Management Unter Connection Management versteht man die Verwaltung von Kommunikationsverbindungen. Diese Verbindungen müssen im Moment noch synchron sein, zukünftige Spezifikationen werden aber auch asynchrone Kommunikationsformen unterstützen. Eine Anwendungskomponente benutzt eine durch den Resourceadapter zur Verfügung gestellte Connection Factory, um auf eine Instanz einer EIS-Verbindung zuzugreifen. Der Connection Management Contract bietet eine standardisierte Schnittstelle hierfür an. Die Ziele bei der Entwicklung des Connection Management Contract waren: Eine einheitliche API für den Zugriff auf Verbindungen. Es einem Resourceadapter zu ermöglichen, Connection Factory und Connection Interfaces auf Basis des Common Client Interfaces zur Verfügung zu stellen. Einen generischen Mechanismus zu entwickeln, der es einem Application-Server ermöglicht unterschiedliche Implementierungen für Quality of Service, Transactionshandling, Securityhandling, Errortracing und logging zuzulassen. Unterstützung für Connectionpooling.

19 Java Connector Architecture Transaction Management Eine Transaktion ist die Implementierung einer oder mehrere Geschäftsvorfälle, sie ist nur dann erfolgreich, wenn alle notwendigen Geschäftsvorfälle erfolgreich waren. Eine Transaktion muss ACID-Eigenschaften haben. Atomicity, Consistency, Isolation, Durability. D.h. eine Transaktion muss atomar und konsistent sein, sie darf keine Wechselwirkungen mit Komponenten außerhalb der Transaktion verursachen und muss ein eindeutiges und dokumentiertes Ergebnis haben. Systeme, die an Transaktionen teilnehmen, befinden sich immer in einem wohldefinierten Zustand. Um diese Eigenschaften zu garantieren haben sich verschiedene Verfahren etabliert. Eine Transaktion wird mit einem commit abgeschlossen, wenn sie erfolgreich war oder bei nicht erfolgreicher Durchführung wird das System mit einem sog. rollback wieder in den Zustand gebracht, den das System vor dem Start der Transaktion inne hatte. Die Java Connector Architecture spezifiziert Schnittstellen zur Behandlung von Transaktionen auf Basis der Java Transaction API und der Java Transaction Service API. Es werden lokale und verteilte Transaktionen unterstützt und somit auch ein One-Phase und ein Two-Phase Commit Security Management Für ein Unternehmen ist es überlebensnotwendig, dass es sich auf die Daten in ihren EIS verlassen kann. Jede fälschliche Manipulation der Daten oder unauthorisierter Zugriff auf das EIS kann für das Unternehmen sehr kostspielig sein. Es existieren Verfahren, die die EIS vor solchen sicherheitsrelevanten Bedrohungen schützen: Identifikation und Authentifizierung von Benutzern, um sicherzustellen, dass sie sind wer sie vorgeben zu sein. Authorisierung und Zugriffskontrollverfahren, um festzustellen, dass ein Benutzer die benötigten Zugriffsrechte hat. Sicherheit der Kommunikation zwischen Application-Server und EIS durch die Verwendung von Sicherheitsprotokollen und Verschlüsselung. Die Architektur des Security-Konzepts der Java Connector Architecture wurde entworfen, um folgende Ziele zu erreichen: Die Erweiterung des end-zu-end Sicherheitsmodells für J2EE-basierende Anwendungen, um die Integration von EIS mit der Connector Architecture zu ermöglichen Unterstützung der Authentifizierung und der Authorisierung der Benutzer Die Architektur neutral zu halten, um spezifische Sicherheitsmodelle zu unterstützen. Bestehende Sicherheitsumgebungen zu unterstützen und möglichst offen für proprietäre Modelle zu sein. Unterstützung der Konfiguration der Sicherheitsmodelle zur Laufzeit.

20 Java Connector Architecture Das Security-Modell der Connector Architecture möglichst für den Anwendungsentwickler transparent zu halten und ein Single-Sign-on zu ermöglichen, d.h. nach einmaliger Authentifizierung und Autorisierung gegenüber dem Application-Server Zugriff auf alle EIS zu haben. 3.4 Common Client Interface Das Common Client Interface spezifiziert eine Client API für Anwendungen. Das CCI ermöglicht es Anwendungen und EAI Frameworks Interaktionen über mehrere EIS hinweg über die gleiche Schnittstelle auszuführen. Das CCI wurde definiert, um folgende Ziele zu erreichen: Die Definition eines Remote Function Call Interface welches darauf spezialisiert ist, Funktionen des EIS auszuführen und ein Ergebnis zu erhalten. Das CCI ist der kleinstmögliche Nenner, um die abstrakte, standardisierte Interaktion mit einem EIS zu ermöglichen. Komplexere und somit komfortablere Schnittstellen können on-the-top entwickelt werden. Spezielle Ausrichtung für die Benutzung innerhalb von Anwendungsentwicklungstools und EAI Frameworks. Ein erweiterbares Application Programming Model. Konformität mit J2SE und den J2EE Plattformen Unabhängigkeit von bestimmten EIS und trotzdem über ein Metadatenrepository beeinflussbar. Die System-Contracts bestimmen sozusagen die Annahmen, welche der Application-Server gegenüber dem Resourceadapter machen muss und kann, das Common Client Interface spezifiziert eine konkrete Schnittstelle, um den Resourceadapter anzusprechen. 3.5 Bewertung im Kontext der EAI Ein Standard ist nur so gut wie seine Akzeptanz. Sollte sich die JCA durchsetzen, wäre dies ein großer Schritt für die EAI. Noch einmal zusammengefasst: Die JCA definiert eine Architektur und die nötigen Schnittstellen, um Adapter für Enterprise Information Systems zu entwickeln, die sich ad-hoc an einen Application-Server anbinden lassen. Der Anwendungsentwickler kann sich auf die Entwicklung der Geschäftslogik konzentrieren und systemnahe Dienste einfach benutzen. Darüber hinaus ist die Behandlung dieser Dienste auf Systemebene bei jedem EIS die Gleiche. Selbst wenn es für eine Legacyanwendung keinen fertigen Resourceadapter gibt, so hat man doch bei der Eigenentwicklung bereits einen Standard, der bereits unternehmensweit gilt. Aufwändige Standardisierungsprozesse entfallen. Die Entwicklung unter dem Java Community Process führt zu einer offenen, geprüften Architektur mit breiter Zustimmung in der Entwicklergemeinde und Akzeptanz bei den Produktherstellern. Die JCA wird den Zeitrahmen zur Integration von Anwendungen deutlich verkleinern und somit wieder Platz für neue, produktivitätssteigernde Maßnahmen schaffen.