Jakarta Connectors

Die Jakarta Connectors (JCA; früher Java EE Connector Architecture) ist eine Softwarearchitektur und Programmierschnittstelle (API) zur Integration von heterogenen Anwendungen in die Jakarta-EE-Plattform. Die Architektur besteht aus zwei Teilen, den Service Provider Interfaces (SPI), welche ein Connector Provider implementieren muss, und dem Common Client Interface (CCI), das eine Applikation verwendet, um mit dem Connector zu interagieren. Darüber hinaus enthält die JCA noch ein API für lokale Transaktionsdemarkation.

Früher wurde der Standard als J2EE Connector Architecture bezeichnet. Ab Version 1.6 der Spezifikation wurde aus J2EE Java EE.^[1]

Enterprise Application Integration (EAI)

Die Enterprise Application Integration (EAI) ist ein Ansatz für die Integration von Applikationen und Datenquellen. Dieser soll den Austausch von Daten und die Verbindung von Geschäftsabläufen vereinfachen.

Vor diesem Ansatz wurde häufig versucht, das Problem der Integration durch Eigenentwicklungen und Anpassungen zu lösen.

Bei den Anwendungen handelte es sich allerdings oft um spezielle Insellösungen auf unterschiedlichen Plattformen und mit unterschiedlichen Kommunikationsprotokollen. Deshalb war eine Integration der Produkte nur mit großem Aufwand realisierbar. EAI definiert nun einen Standard, der das Kommunizieren zwischen Applikationen und Datenquellen auf einheitlichem Wege möglich macht. Damit werden einzelne Teile der Integration leichter austauschbar.

Allerdings scheinen die technischen Unterschiede der Applikationen und Datenquellen problematisch zu sein, die für die Integration berücksichtigt werden müssen. Für Enterprise Information Systems (EIS) sind folgende Unterscheidungsmerkmale zu berücksichtigen:

Grad der technologischen Unterstützung

Beinhaltet die Möglichkeit der Durchführung von Transaktionen oder Unterstützung von Sicherheitsmechanismen.

Administrative und technologische Restriktionen

Ein EIS kann Benutzern beispielsweise unterschiedliche Zugriffsmöglichkeiten geben.

Fähigkeit der Integration mit anderen Systemen

EISs wurden oftmals auf bestimmte Systemumgebungen zugeschnitten, während die Kommunikation mit anderen Produkten nur eine untergeordnete Rolle spielte.

Systemdetails auf unterer Ebene

Die Client APIs der EISs können sich unterscheiden. Neben der Verwendung unterschiedlicher Programmiersprachen kann ihre Komplexität stark variieren.

EAI und die Jakarta EE Plattform

Aufgrund der großen Anzahl von unterschiedlichen EIS-Systemen ist die Lösung der Integrationsfrage sehr komplex. Um aus einer Anwendung heraus auf Informationen eines EIS zugreifen zu können, war bisher eine anwendungsspezifische Verbindung notwendig. Die Folge war ein hoher Entwicklungsaufwand, welcher mit der Anzahl der EIS-Systeme und Applikationsserver wuchs, da für jeden Applikationsserver eine Verbindung zu jedem EIS hergestellt werden muss. Bei m Applikationsservern und n EIS-Systemen bedeutet dies einen Aufwand von „m mal n“. (siehe Abb. 1)

Abb. 1 – „m mal n“-Integrationsproblem

Durch die Konnektor-Architektur soll dieser Aufwand reduziert werden. EIS-Entwickler müssen ihre Systeme nicht jedem Applikationsserver anpassen. Stattdessen reicht es, wenn sie für ihr EIS einen entsprechenden Ressourcenadapter entwickeln, der dann in jeden Applikationsserver integriert werden kann, wenn er die Konnektor-Architektur unterstützt.

Damit also die Applikationsserver die Ressourcenadapter einbinden können, müssen deren Entwickler lediglich einmalig die Konnektor-Architektur integrieren. Somit reduziert sich der Aufwand der Integrationsproblematik auf „m + n“. (siehe Abb. 2)

Abb. 2 – „m+n“-Integrationsproblem

Architektur

In der verwalteten Umgebung (managed environment), welche später noch näher erläutert wird, lassen sich die wichtigsten Komponenten und deren Zusammenspiel erklären.

Die verwaltete Umgebung definiert ein Umfeld für eine Jakarta-EE-basierte, mehrschichtige und webfähige Applikation, die auf ein EIS zugreift. Dabei besteht die Applikation aus einer oder mehreren Applikationskomponenten wie Jakarta Enterprise Beans (EJBs) oder Jakarta Server Pages (JSPs), die in einem Container ablaufen. Folgende Container sind möglich:

• Web-Container für JSPs, Servlets und statische HTML-Seiten
• EJB-Container für EJB-Komponenten
• Applikationsclient-Container für eigenständige Applikationsclients

Abb. 3 – Überblick JCA

Die Kommunikation der Jakarta-EE-Applikationskomponenten erfolgt über den Container-Komponenten-Kontrakt, der das Verbindungsstück zwischen einem Container und dem Applikationsserver darstellt. Dieser wird in der Jakarta-EE-Spezifikation definiert.

Um auf Funktionen des EIS zugreifen zu können, benutzen die Applikationskomponenten einen Ressourcenadapter. Der Zugriff auf diesen erfolgt über dessen Client API.

Die Systemkontrakte

Die Einbindung des Ressourcenadapters in den Applikationsserver erfolgt über die sogenannten Systemkontrakte. Von ihnen wird das Zusammenspiel von Ressourcenadapter und Applikationsserver geregelt. Ihre Implementierung wird durch die Konnektor-Spezifikation zwingend gefordert.

Ein Applikationsserver und ein Ressourcenadapter arbeiten zusammen, um alle systemnahen Mechanismen gegenüber den Applikationskomponenten transparent zu halten. Es werden daher drei wichtige Systemkontrakte benötigt:

Kontrakt für das Verbindungsmanagement

Dieser erlaubt dem Applikationsserver, Verbindungspools zum darunter liegenden EIS zu verwalten, was zu einer besseren Ausnutzung von Verbindungen führt.

Kontrakt für das Transaktionsmanagement

Dieser Kontrakt erlaubt einem Applikationsserver, einen Transaktionsmanager für die Verwaltung von Transaktionen über mehrere Ressourcenmanager zu verwenden.

Kontrakt für das Sicherheitsmanagement

Der Sicherheitsmanagement-Kontrakt soll einen sicheren Zugriff auf das EIS ermöglichen. Er bietet Unterstützung für eine sichere Applikationsumgebung, die Sicherheitsprobleme minimieren hilft und vom EIS verwaltete Informationen schützt.

Für die Implementierung der 3 Systemkontrakte definiert die Konnektor-Spezifikation Schnittstellen, welche zu großem Teil vom Ressourcenadapter implementiert werden müssen.

Nicht verwaltete Umgebung

Neben der bereits kurz erwähnten verwalteten Umgebung beschreibt die Konnektor-Spezifikation weiterhin eine nicht verwaltete Umgebung (non-managed environment). Diese definiert eine zweischichtige Applikation. Ein Applikationsclient verwendet einen Ressourcenadapter direkt, um auf ein EIS zuzugreifen. Hierbei wird kein Applikationsserver benötigt.

Abb. 4 – Nicht verwaltete Umgebung

Da für diese Art der Integration meist ein einfacher Standard-Verbindungsmanager des verwendeten Ressourcenadapters benutzt wird, werden Features wie der Gebrauch von Verbindungspools meist nicht unterstützt.

In Abbildung 4 ist zu sehen, wie ein Applikationsclient über einen Ressourcenadapter auf ein EIS zugreifen kann. Die ConnectionFactory-Schnittstelle wird angesprochen, wenn eine neue Verbindung benötigt wird. Diese Verbindungsanfrage wird an die ConnectionManager-Schnittstelle weitergereicht, dessen Implementierung die Verwaltung der Verbindung übernimmt. Die Erzeugung der physikalischen Verbindung wird dann von der ManagedConnectionFactory-Schnittstelle realisiert. Die physikalische Verbindung zum EIS wird durch die ManagedConnection-Schnittstelle repräsentiert.

Damit der Applikationsclient auf Funktionen des EIS zugreifen kann, bekommt er ein Handle einer Connection-Instanz, welche durch die eben erwähnte ConnectionFactory-Schnittstelle erzeugt wurde, worüber er Zugriff auf das EIS bekommt.

Verwaltete Umgebung

Abb. 5 – Verwaltete Umgebung

Die bereits erwähnte verwaltete Umgebung soll nun etwas näher betrachtet werden, da diese den Schwerpunkt der Konnektor-Architektur bildet. Im Gegensatz zur nicht verwalteten Umgebung sind die Applikationskomponenten und der Ressourcenadapter über Kontrakte mit einem Applikationsserver verbunden, der somit insbesondere in das Verbindungs-, Transaktions- und Sicherheitsmanagement eingreift. Im Unterschied zur nicht verwalteten Umgebung kann man feststellen, dass die Implementierung der ConnectionManager-Schnittstelle innerhalb des Applikationsservers geschieht. Über die Systemkontrakte wird zudem der Zugriff auf den Ressourcenadapter vom Applikationsserver geregelt.

Konfiguration des Ressourcenadapters

Konfigurationsinformationen des Ressourcenadapters wie zum Beispiel der Servername oder die Portnummer können über ein sogenanntes Deployment-Tool gesetzt werden. Ein so konfigurierter Ressourcenadapter wird vom Applikationsserver für die Herstellung physikalischer Verbindungen zum darunterliegenden EIS verwendet.

Verbindungsaufbau und Sicherheit

Um zu einer Verbindung zu gelangen, findet ein Aufruf der getConnection-Methode der ConnectionFactory durch die Applikationskomponente statt. Diese Anfrage wird an den ConnectionManager weitergereicht. Ein Verbindungsmanager innerhalb des Applikationsservers bearbeitet die Anfrage und sucht eine geeignete Verbindung heraus. Falls keine geeignete Verbindung besteht, wird eine neue erzeugt. Die vom Sicherheitsmanager verwalteten Sicherheitsmechanismen (Login, Passwort) müssen übereinstimmen, um eine bestehende Verbindung nutzen zu können.

Die Verwaltung des Verbindungspools liegt beim Applikationsserver und wird nicht durch die Konnektor-Spezifikation festgelegt.

Der Applikationsserver verwendet die ManagedConnectionFactory-Schnittstelle zur Erzeugung physikalischer Verbindungen, wobei es sich um ManagedConnection-Instanzen handelt.

Wie auch in der nicht verwalteten Umgebung bekommt die Applikationskomponente ein Handle auf diese physikalische Verbindung. Unter Benutzung des Common Client Interface (CCI) handelt es sich wieder um eine Connection-Instanz, über die auf das EIS zugegriffen werden kann.

Transaktionen

Abb. 6 – XARessource-basierte Transaktion

Für die lokale Steuerung (im EIS) verwendet der Applikationsserver die LocalTransaction-Schnittstelle des Ressourcenadapters. Verteilte Transaktionen werden über den Transaktionsmanager geregelt, welcher die XARessource-Schnittstelle des Ressourcenadapters benutzt.

Der Transaktionsmanager verwaltet Transaktionen über eigene interne Mechanismen, welche nicht durch die JCA-Spezifikation vorgegeben werden.

In Abbildung 6 ruft ein Client die EJB-Komponente X auf, welche einen Zugriff auf das TP-System durchführt und die EJB Y aufruft. Diese wiederum spricht ein ERP-System an. Der Applikationsserver verwendet einen Transaktionsmanager, um transaktionalen Zugriff über mehrere EIS Ressourcenmanager auszuführen.

Ereignisse

Die ConnectionEventListener-Schnittstelle informiert den Applikationsserver über unterschiedliche Ereignisse der physikalischen Verbindung ManagedConnection. Ereignisse können zum Beispiel das Schließen der Verbindung, das Auftreten von Fehlern oder der Status von Transaktionen sein.

Anmerkung

Die bisherige Ausführung zeigt grundlegende Zusammenhänge der Schnittstellen innerhalb der Konnektor-Architektur. Um diese Schnittstellen implementieren zu können, benötigt man natürlich detailliertere Informationen. Details zu den Schnittstellen können in der Konnektor-Spezifikation oder der Java-Dokumentation des Java EE SDK nachgelesen werden.

Weblinks

• JEE Connector Architecture im Java EE 7 Tutorial bei Oracle (englisch)
• JSR 112: J2EE Connector Architecture 1.5 (englisch)
• JSR 322: Java EE Connector Architecture 1.6 (englisch)
• JSR 16: J2EE Connector Architecture (englisch)

Einzelnachweise

1. ↑ JSR 322: Java EE Connector Architecture 1.6 (englisch)