Java EE 5 Architekturen. Java Patterns und Idiome

Integration Tier Patterns (S. 125-126)

„Das einzig Beständige ist der Wandel" …und die Entstehung von Legacy Software [Friedrich Engels]

Neuentwicklungen sind selten. Noch seltener sind Projekte, welche vollständig in einer Technologie realisiert werden können. Fremdsysteme und bereits bestehende Funktionalität sind mit einer anderen, meist älteren Technologie realisiert. Auch in der schönen, neuen Java EE 5-Welt wird man nicht nur mit J2EE-Komponenten, sondern auch mit Host-Systemen, Messaging-Servern und Rechenkernen konfrontiert, für die oft keine Dokumentation mehr existiert.

In diesem Kapitel werden einige Ideen, Patterns und Vorgehensweisen für den Umgang mit externen Schnittstellen beschrieben.

3.1 Integration Service (IS)
3.1.1 Die Essenz

Vereinfachung des Zugriffs auf Datenquellen. Ein IS ist ein ServiceDelegate der Integrationsschicht.

3.1.2 Anforderungen/Kontext

- ,Lesender/schreibender Zugriff auf Stored Procedures einer relationalen Datenbank ist notwendig. ,
- Inkompatible oder „unbequeme" Datenquellen müssen integriert werden. ,
- Die konkrete, möglicherweise proprietäre, Technologie des externen Systems sollte möglichst gut gekapselt werden. ,
- Die Realisierung des Datenzugriffs sollte austauschbar sein. ,
- Die Fachlichkeit der Datenquelle sollte hervorgehoben und von der Realisierung möglichst gut getrennt werden.

3.1.3 Einsatzempfehlung
Die Fähigkeiten der Java EE 5-Plattform bezüglich der Persistenz wurden mit der JPASpezifikation erheblich erweitert. Der Bedarf für die Realisierung einer eigenen Persistenzschicht ist kaum noch vorhanden. Die JPA-Spezifikation ermöglicht bereits sowohl die Ausführung von nativen Abfragen und Massen-Updates als auch die Rückgabe von einzelnen Attributen einer Entität. Dennoch gibt es Bedarf, bestehende Stored Procedures zu integrieren oder auf Daten von Java-EE-inkompatiblen Ressourcen (auch Flat- Files), Host-Systemen usw. zuzugreifen. Die Realisierung des Zugriffs auf eine solche inkompatible Datenquelle oder Senke ist oft mit hohem Aufwand und „esoterischen" Implementierungen verbunden.

Der Einsatz von Integration Service (IS) ist kein Best Practice, sondern ein notwendiges Übel. Dieses Pattern sollte lediglich für die Integration von inkompatiblen Ressourcen und nicht zur Realisierung von Geschäftslogik oder eigener Persistenz eingesetzt werden.

3.1.4 Lösung

Bei der Lösung des Integrationsproblems wird wieder das Leitprinzip „Trennung der Fachlichkeit von der Technik" verfolgt. Im ersten Schritt sollten die Fähigkeiten bzw. der fachliche Mehrwert der inkompatiblen Ressource definiert und hervorgehoben werden.

Anleitung

Die Fähigkeiten des IS werden in einem Java-Interface zusammengefasst. Es handelt sich hier um eine technologieneutrale Schnittstelle (ohne die @Local-, @Remote-Annotationen). Die Methoden dieser Schnittstelle haben serviceorientierten Charakter, d.h., sie drücken mit ihrem Namen Vorgänge bzw. fachliche Aktivitäten aus. Bei den Methodenparametern kann es sich sowohl um primitive Datentypen als auch um DTOs, GDTOs, PAOs oder PDOs handeln. Die Methoden der IS-Schnittstelle können beliebige Exceptions werfen, wobei dadurch auf keinen Fall eine Abhängigkeit von der Realisierung der Schnittstelle entstehen sollte. Bei einer SQL-IS-Realisierung sollten keine SQLException in der Schnittstelle deklariert werden. Stattdessen sollte die Realisierung die Transformation von technologiebehafteten in neutrale Exceptions übernehmen.

Die Schnittstelle des IS ist gleichzeitig das @Local-, in Ausnahmefällen das @Remote-Interface einer Stateless Session Bean. Die Session Bean implementiert den Datenzugriff und kapselt eine möglicherweise proprietäre Technologie. Die Transaktionssteuerung liegt in den Zuständigkeiten der aufrufenden Einheit (z.B. einer Service Facade). Die IS-Session Bean wird mit der Transaktionseinstellung TransactionAttributeType.MANDATORY deployed und verlässt sich somit auf einen Aufruf ihrer Methoden in einer bereits existierenden Transaktion.