MuleSoft - Das Mule-Projekt
Die Motive hinter dem Mule-Projekt waren -
um es den Programmierern einfacher zu machen,
die Notwendigkeit einer leichten und modularen Lösung, die von einem Messaging-Framework auf Anwendungsebene zu einem unternehmensweiten, hochverteilbaren Framework skaliert werden kann.
Mule ESB ist sowohl als ereignisgesteuertes als auch als programmatisches Framework konzipiert. Es ist ereignisgesteuert, da es mit einer einheitlichen Darstellung von Nachrichten kombiniert wird und mit steckbaren Modulen erweitert werden kann. Es ist programmatisch, da Programmierer leicht einige zusätzliche Verhaltensweisen wie die spezifische Nachrichtenverarbeitung oder die benutzerdefinierte Datentransformation implantieren können.
Geschichte
Die historische Perspektive des Mule-Projekts ist wie folgt:
SourceForge-Projekt
Das Mule-Projekt wurde im April 2003 als SourceForge-Projekt gestartet. Nach zwei Jahren wurde die erste Version veröffentlicht und in das CodeHaus verschoben. Die UMO-API (Universal Message Object) war das Kernstück ihrer Architektur. Die Idee hinter der UMO-API war es, die Logik zu vereinheitlichen und sie gleichzeitig von den zugrunde liegenden Transporten isoliert zu halten.
Version 1.0
Es wurde im April 2005 mit zahlreichen Transporten veröffentlicht. Das Hauptaugenmerk vieler anderer Versionen lag auf dem Debuggen und Hinzufügen neuer Funktionen.
Version 2.0 (Übernahme von Spring 2)
Spring 2 als Konfigurations- und Verkabelungsframework wurde in Mule 2 übernommen, erwies sich jedoch aufgrund der mangelnden Ausdruckskraft der erforderlichen XML-Konfiguration als große Überholung. Dieses Problem wurde behoben, als in Spring 2 eine XML-Schema-basierte Konfiguration eingeführt wurde.
Bauen mit Maven
Die größte Verbesserung, die die Verwendung von Mule sowohl zu Entwicklungs- als auch zu Bereitstellungszeiten vereinfachte, war die Verwendung von Maven. Ab Version 1.3 wurde mit Maven begonnen.
MuleSource
Im Jahr 2006 wurde MuleSource integriert, um „die schnell wachsende Community bei der Verwendung von Mule in unternehmenskritischen Unternehmensanwendungen zu unterstützen und zu unterstützen“. Es erwies sich als der wichtigste Meilenstein für das Mule-Projekt.
Konkurrenten von Mule ESB
Im Folgenden sind einige der Hauptkonkurrenten von Mule ESB aufgeführt:
- WSO2 ESB
- Oracle Service Bus
- WebSphere Message Broker
- Aurea CX-Plattform
- Fiorano ESB
- WebSphere DataPower Gateway
- Workday Business Process Framework
- Talend Enterprise Service Bus
- JBoss Enterprise Service Bus
- iWay Service Manager
Mules Kernkonzept
Wie bereits erwähnt, ist Mule ESB eine leichte und hoch skalierbare Java-basierte Enterprise Service Bus (ESB) - und Integrationsplattform. Unabhängig von verschiedenen Technologien, die von Anwendungen verwendet werden, ermöglicht Mule ESB die einfache Integration von Anwendungen und den Datenaustausch. In diesem Abschnitt werden wir über das Kernkonzept von Mule sprechen, das ins Spiel kommt, um eine solche Integration zu ermöglichen.
Dazu müssen wir sowohl die Architektur als auch die Bausteine verstehen.
Die Architektur
Die Architektur von Mule ESB besteht aus drei Schichten: Transportschicht, Integrationsschicht und Anwendungsschicht, wie in der folgenden Abbildung dargestellt:
Im Allgemeinen gibt es drei Arten von Aufgaben, die zum Konfigurieren und Anpassen der Mule-Bereitstellung ausgeführt werden können:
Entwicklung von Servicekomponenten
Diese Aufgabe umfasst die Entwicklung oder Wiederverwendung der vorhandenen POJOs oder Spring Beans. POJOs ist eine Klasse mit Attributen, die die Methoden get und set, Cloud Connectors, generiert. Auf der anderen Seite enthält Spring Beans die Geschäftslogik zur Anreicherung von Nachrichten.
Service-Orchestrierung
Diese Aufgabe stellt im Wesentlichen die Dienstvermittlung bereit, bei der der Nachrichtenprozessor, die Router, die Transformatoren und die Filter konfiguriert werden.
Integration
Die wichtigste Aufgabe von Mule ESB ist die Integration verschiedener Anwendungen, unabhängig von den verwendeten Protokollen. Zu diesem Zweck bietet Mule Transportmethoden an, mit denen die Nachrichten auf verschiedenen Protokollverbindern empfangen und versendet werden können. Mule unterstützt viele vorhandene Transportmethoden, oder wir verwenden möglicherweise auch eine benutzerdefinierte Transportmethode.
Bausteine
Die Maultierkonfiguration hat die folgenden Bausteine:
Frühlingsbohnen
Die Hauptverwendung von Spring Beans besteht darin, eine Servicekomponente zu erstellen. Nach dem Erstellen der Spring Service-Komponente können wir sie über eine Konfigurationsdatei oder manuell definieren, falls Sie keine Konfigurationsdatei haben.
Agenten
Es handelt sich im Grunde genommen um einen Dienst, der in Anypoint Studio vor Mule Studio erstellt wurde. Ein Agent wird erstellt, sobald Sie einen Server starten, und wird zerstört, sobald Sie den Server stoppen.
Verbinder
Es ist eine Softwarekomponente, die mit den für Protokolle spezifischen Parametern konfiguriert ist. Es wird hauptsächlich zur Steuerung der Verwendung eines Protokolls verwendet. Beispielsweise wird ein JMS-Connector mit a konfiguriertConnection und dieser Verbinder wird unter verschiedenen Einheiten geteilt, die für die tatsächliche Kommunikation verantwortlich sind.
Globale Konfiguration
Wie der Name schon sagt, werden mit diesem Baustein die globalen Eigenschaften und Einstellungen festgelegt.
Globale Endpunkte
Es kann auf der Registerkarte Globale Elemente verwendet werden, die in einem Flow so oft verwendet werden kann.
Globaler Nachrichtenprozessor
Wie der Name schon sagt, beobachtet oder ändert er eine Nachricht oder einen Nachrichtenfluss. Transformatoren und Filter sind Beispiele für Global Message Processor.
Transformers- Die Hauptaufgabe eines Transformators besteht darin, Daten von einem Format in ein anderes zu konvertieren. Es kann global definiert und in mehreren Flows verwendet werden.
Filters- Es ist der Filter, der entscheidet, welche Mule-Nachricht verarbeitet werden soll. Filter gibt grundsätzlich die Bedingungen an, die erfüllt sein müssen, damit eine Nachricht verarbeitet und an einen Dienst weitergeleitet werden kann.
Modelle
Im Gegensatz zu Agenten handelt es sich um eine logische Gruppierung von Diensten, die im Studio erstellt werden. Wir haben die Freiheit, alle Dienste innerhalb eines bestimmten Modells zu starten und zu stoppen.
Services- Services sind diejenigen, die unsere Geschäftslogik oder Komponenten umschließen. Außerdem werden Router, Endpunkte, Transformatoren und Filter speziell für diesen Dienst konfiguriert.
Endpoints- Es kann als ein Objekt definiert werden, für das Dienste eingehende (empfangene) und ausgehende (sendende) Nachrichten senden. Dienste sind über Endpunkte verbunden.
Fließen
Der Nachrichtenprozessor verwendet Flows, um einen Nachrichtenfluss zwischen einer Quelle und einem Ziel zu definieren.
Struktur der Maultiernachrichten
Eine Mule-Nachricht, die vollständig unter dem Mule-Nachrichtenobjekt verpackt ist, sind die Daten, die über Mule-Flows durch Anwendungen geleitet werden. Die Nachricht von Structure Mule ist in der folgenden Abbildung dargestellt:
Wie im obigen Diagramm zu sehen, besteht Mule Message aus zwei Hauptteilen -
Header
Es sind nichts anderes als die Metadaten der Nachricht, die durch die folgenden zwei Eigenschaften weiter dargestellt werden:
Inbound Properties- Dies sind die Eigenschaften, die von der Nachrichtenquelle automatisch festgelegt werden. Sie können vom Benutzer nicht manipuliert oder eingestellt werden. Eingehende Eigenschaften sind in der Natur unveränderlich.
Outbound Properties- Dies sind die Eigenschaften, die Metadaten wie eine eingehende Eigenschaft enthalten und im Verlauf des Flusses festgelegt werden können. Sie können automatisch von Mule oder manuell von einem Benutzer eingestellt werden. In der Natur sind ausgehende Eigenschaften veränderlich.
Ausgehende Eigenschaften werden zu eingehenden Eigenschaften, wenn die Nachricht über einen Transport vom ausgehenden Endpunkt eines Flusses zum eingehenden Endpunkt eines anderen Flusses übertragen wird.
Ausgehende Eigenschaften bleiben ausgehende Eigenschaften, wenn die Nachricht über einen Flow-Ref und nicht über einen Connector an einen neuen Flow übergeben wird.
Nutzlast
Die tatsächliche Geschäftsnachricht, die vom Nachrichtenobjekt übertragen wird, wird als Nutzlast bezeichnet.
Variablen
Es kann als benutzerdefinierte Metadaten zu einer Nachricht definiert werden. Grundsätzlich sind Variablen temporäre Informationen zu einer Nachricht, die von der Anwendung verwendet wird, die sie verarbeitet. Es ist nicht dazu gedacht, zusammen mit den Nachrichten an sein Ziel weitergeleitet zu werden. Es gibt drei Arten von Typen, wie unten angegeben -
Flow variables - Diese Variablen gelten nur für den Fluss, in dem sie existieren.
Session variables - Diese Variablen gelten für alle Flows innerhalb derselben Anwendung.
Record variables - Diese Variablen gelten nur für Datensätze, die als Teil eines Stapels verarbeitet werden.
Anhänge und zusätzliche Nutzlast
Hierbei handelt es sich um einige zusätzliche Metadaten zur Nachrichtennutzlast, die nicht unbedingt jedes Mal im Nachrichtenobjekt angezeigt werden.