Mule 2 - JAXenter

Mule 2

Transports

Die neue Konfiguration hat vor allem bei den Transports eine Auswirkung und erleichtert dem Entwickler das Leben ungemein. Jeder Transport wird in Version 2 mit einem eigenen Konfigurationsschema ausgeliefert, was den großen Vorteil hat, dass es nun transportspezifische Konnektoren und Endpoints gibt und man nicht mehr auf das generelle DTD von Mule angewiesen ist. In Version 1 hat man Konnektoren und Endpoints immer auf die gleiche Art und Weise konfiguriert und den Konnektor ausschließlich über das className-Attribut und die Property Tags konfiguriert. Der Entwickler musste die Namen der Eigenschaften und Klassennamen immer wissen bzw. ein paralleles Arbeiten mit der API. Nicht selten kam es da zu Tippfehlern, und mühsames Auffinden von Fehlern, die erst beim Start des Servers aufgetreten sind, war die Folge. Eine ClassNotFoundException war dabei an Tagesordnung, weil sich ein Tippfehler in der XML-Konfiguration eingeschlichen hat. Betrachten wir Listing 3, welche die alte und neue Konfiguration des Active MQ Connectors für den Active MQ Server darstellt. Benutzerdefinierte Einstellungen der Konnektoren wurden ausschließlich über die property Tags festgelegt. Die neue Konfiguration abstrahiert nicht nur Klassendetails, sondern macht die Definition auch lesbarer. Die property Tags werden durch eigene Attribute im Konnektor ersetzt.

Listing 3: Active-MQ-Konfiguration in Mule 1
    

Mule-2.x-Konfiguration

    

Der Aufbau und das Zusammenspiel von Connector, Message Adapter, Message Receiver und Message Dispatcher sind im Prinzip gleich wie in Mule 1.x. Durch die schemabasierte Konfiguration sollte jeder neue Provider ein Schema anbieten, wie der Konnektor und folglich auch die Endpoints konfiguriert werden können. Für diesen Zweck muss zusätzlich zu der Implementierung der Standardklassen nun auch ein Namespace Handler implementiert werden, damit Mule die neue Konfiguration interpretieren kann. Ich möchte an dieser Stelle auch auf die Spring-Dokumentation verweisen, die eine gute Einführung in dieses Thema gibt. Im Zuge der Änderungen wurden nun auch die Zuständigkeiten der MuleMessage (ehem. UMOMessage) und des MessageAdapter klar voneinander getrennt. Der MessageAdapter kümmert sich nun nur mehr um das Wrapping der spezifischen Nachricht für die MuleMessage. In Version 1.x hat der MessageAdapter auch die Konvertierung in byte[] und String übernommen. Werden Transformatoren auf die MuleMessage angewendet, so wird nun der Payload geändert. Um weiterhin Zugriff auf den originalen Payload zu haben, kann die neue Methode getOrginalPayload() verwendet werden.

Transformer wurden in Version 1.x in einem <transformers>-Block konfiguriert und wie viele andere Elemente durch den className konkret definiert. Viele Transporte liefern ihre eigenen Transformer mit, die nun auch über das vom Transport bereitgestellte Schema definiert werden. Listing 4 listet den Unterschied der Konfiguration auf. Benutzerdefinierte Transformer sind nun über einen custom-transformer definiert worden. Auch zusätzliche Eigenschaften des Transformers werden dank der Schemakonfiguration über Attribute gesetzt, nicht mehr über das property Tag. Standardtransformer oder von einem Drittanbieter bereitgestellte Transformer werden über die entsprechenden Namespaces angesprochen (siehe xls-transformer).

Listing 4: Mule-1.x-Konfiguration

Mule-2.x-Konfiguration

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.