Dieser Artikel ist noch nicht wirklich Teil einer Roadmap und er beschreibt auch noch nicht wirklich einen zu erreichenden Meilenstein. Vielmehr beleuchtet er einen spezifischen Aspekt bezüglich des Themenbereiches Enterprise Integration.

Warum?

Wie bereits in anderen Artikeln diskutiert, steht und fällt ein System mit seinen äußeren Schnittstellen. Auch ein Produkt wie dWb+ kann nicht existieren, wenn es sich nur selbst bespiegelt. Es muß in der Lage sein, Informationen aus der Umgebung zu verarbeiten und die Resultate wiederum in die Umgebung zu kommunizieren. Das System stellt verschiedene Modul-Templates zur Verfügung, die es Entwicklern erleichtern, Schnittstellenmodule zu entwickeln.

Es wäre aber unter Umständen erstrebenswert, automatisch solche Module zu erstellen und diese dann noch nicht einmal kompilieren zu müssen. Die Vision - ich bitte um Entschuldigung für dieses Wort - ist: man lässt eine Definition der Schnittstelle auf den Arbeitstisch fallen und das System generiert das passende Schnittstellenmodul dynamisch.

Das genau soll der Versuch sein, der demnächst für dWb+ unternommen wird. Über die Ergebnisse - sollten sie positiv sein - wird hier berichtet werden.

Vorüberlegungen

Schnittstellenbeschreibung

Zunächst muß man sich Gedanken darüber machen, welche Informationen in einer solchen Schnittstellendefinition enthalten sein müssen - momentan ist folgendes Schema dafür in der Diskussion:

Client/Server

Ist dWb passiver Befehlsempfänger (Server) oder aktiver Initiator der Kommunikation (Client)?

Schema

Wie sind die Daten aufgebaut? Ein Beispiel für die Realisierung könnte XML Schema sein. Vorschlag für das Datenformat: URI.

Data

Definition der Schnittstelle - soll die Schnittstelle als HTTP-Client funktionieren, also zum Beispiel aine URL. Vorschlag für das Datenformat: URI.

Realisierung

Es wäre beispielsweise möglich, einen BeanContextService zu erstellen, der die oben beschriebenen Schnittstellendefinitions-Tupel als ServiceLocator benutzt und daraus die Schnittstellen-Module erzeugt.

Datentypen

Die Ausgangsdatentypen solcher dynamisch zur Laufzeit erzeugten Module sind naturgemäß immer ein Problem: da sie zur Laufzeit erzeugt werden, existieren naturgemäß keine Module, die genau diesen Typ als Eingangstyp haben.

Das lässt sich durch verschiedene Strategien abmildern:

JSON

Die Ausgangsobjekte könnten als JSON-Objekte definiert werden - alle Module, die mit JSON-Objekten umgehen können, können dann auch damit arbeiten.

JAXB

Für die Daten in der Schnittstellendefinition können (sofern XML Schema als Datendefinitions-Sprache verwendet wird) per JAXB Klassen erzeugt werden, die in dWb integriert werden können. Für diese Klassen können dann spezifische Module geschrieben werden. Sie können aber auch einfach mittels BeanSplitter-Modulen in ihre Einzelteile zerlegt werden und man kann anschließend mit diesen weitere Module beschicken.

BeanShell

Aus den einkommenden Informationen werden Beanshell-Objekte erzeugt. Können diese mittels Reflection und Introspektion analysiert werden, steht evtl. wieder der Weg über BeanSplitter-Module offen.

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )