MuleSoft - Il progetto Mule

Le motivazioni alla base del progetto Mule erano:

• per rendere le cose più semplici per i programmatori,

• la necessità di una soluzione leggera e modulare in grado di scalare da un framework di messaggistica a livello di applicazione a un framework altamente distribuibile a livello aziendale.

Mule ESB è progettato come framework basato su eventi e programmatico. È guidato dagli eventi perché è combinato con una rappresentazione unificata dei messaggi e può essere espandibile con moduli collegabili. È programmatico perché i programmatori possono facilmente impiantare alcuni comportamenti aggiuntivi come l'elaborazione di messaggi specifici o la trasformazione personalizzata dei dati.

Storia

La prospettiva storica del progetto Mule è la seguente:

Progetto SourceForge

Il progetto Mule è stato avviato come progetto SourceForge nell'aprile 2003, e dopo 2 anni la sua prima versione è stata rilasciata e spostata in CodeHaus. L'API UMO (Universal Message Object) era il fulcro della sua architettura. L'idea alla base dell'API UMO era di unificare la logica mantenendola isolata dai trasporti sottostanti.

Versione 1.0.0

È stato rilasciato nell'aprile 2005 contenente numerosi trasporti. L'obiettivo principale di molte altre versioni seguite da esso era il debug e l'aggiunta di nuove funzionalità.

Versione 2.0 (adozione della primavera 2)

La Spring 2 come struttura di configurazione e cablaggio è stata adottata in Mule 2 ma si è rivelata una grande revisione a causa della mancanza di espressività della configurazione XML richiesta. Questo problema è stato risolto quando la configurazione basata su XML Schema è stata introdotta nella primavera 2.

Costruire con Maven

Il più grande miglioramento che ha semplificato l'utilizzo di Mule, sia in fase di sviluppo che di distribuzione, è stato l'uso di Maven. Dalla versione 1.3, ha iniziato a essere costruito con Maven.

MuleSource

Nel 2006, MuleSource è stata incorporata "per aiutare a supportare e abilitare la comunità in rapida crescita che utilizza Mule in applicazioni aziendali mission-critical". Si è rivelata la pietra miliare chiave per Mule Project.

Concorrenti di Mule ESB

Di seguito sono riportati alcuni dei principali concorrenti di Mule ESB:

• WSO2 ESB
• Oracle Service Bus
• WebSphere Message Broker
• Piattaforma Aurea CX
• Fiorano ESB
• WebSphere DataPower Gateway
• Framework dei processi aziendali di Workday
• Talend Enterprise Service Bus
• JBoss Enterprise Service Bus
• iWay Service Manager

Il concetto di base di Mule

Come discusso, Mule ESB è un bus di servizi aziendali (ESB) basato su Java e una piattaforma di integrazione leggera e altamente scalabile. Indipendentemente dalle varie tecnologie utilizzate dalle applicazioni, Mule ESB consente una facile integrazione delle applicazioni, consentendo loro di scambiare dati. In questa sezione, discuteremo del concetto fondamentale di Mule che entra in gioco per realizzare tale integrazione.

Per questo, abbiamo bisogno di capire la sua architettura e gli elementi costitutivi.

Architettura

L'architettura di Mule ESB ha tre livelli, ovvero livello di trasporto, livello di integrazione e livello di applicazione, come mostrato nel diagramma seguente:

In generale, ci sono i seguenti tre tipi di attività che possono essere eseguite per configurare e personalizzare la distribuzione di Mule:

Sviluppo di componenti di servizio

Questa attività implica lo sviluppo o il riutilizzo dei POJO esistenti, o Spring Beans. POJOs è una classe con attributi che genera i metodi get e set, connettori cloud. D'altra parte, Spring Beans contiene la logica di business per arricchire i messaggi.

Orchestrazione dei servizi

Questa attività fornisce fondamentalmente la mediazione del servizio che implica la configurazione del processore di messaggi, router, trasformatori e filtri.

Integrazione

Il compito più importante di Mule ESB è l'integrazione di varie applicazioni indipendentemente dai protocolli che stanno utilizzando. A tale scopo, Mule fornisce metodi di trasporto che consentono di ricevere e inviare i messaggi su vari connettori di protocollo. Mule supporta molti metodi di trasporto esistenti, oppure possiamo anche utilizzare un metodo di trasporto personalizzato.

Costruzioni

La configurazione di Mule ha i seguenti elementi costitutivi:

Fagioli primaverili

L'utilizzo principale dei bean Spring è la creazione di componenti di servizio. Dopo aver costruito il componente del servizio primaverile, possiamo definirlo tramite un file di configurazione o manualmente, nel caso non abbiate un file di configurazione.

Agenti

È fondamentalmente un servizio creato in Anypoint Studio prima di Mule Studio. Un agente viene creato una volta avviato un server e verrà distrutto una volta arrestato il server.

Connettore

È un componente software configurato con i parametri specifici dei protocolli. Viene utilizzato principalmente per controllare l'utilizzo di un protocollo. Ad esempio, un connettore JMS è configurato con un fileConnection e questo connettore sarà condiviso tra i vari soggetti incaricati della comunicazione effettiva.

Configurazione globale

Come suggerisce il nome, questo blocco predefinito viene utilizzato per impostare le proprietà e le impostazioni globali.

Endpoint globali

Può essere utilizzato nella scheda Elementi globali che può essere utilizzata tante volte in un flusso -

Elaboratore di messaggi globale

Come suggerisce il nome, osserva o modifica un messaggio o un flusso di messaggi. Transformers e filtri sono gli esempi di Global Message Processor.

Transformers- Il compito principale di un trasformatore è convertire i dati da un formato all'altro. Può essere definito globalmente e può essere utilizzato in più flussi.

Filters- È il filtro che deciderà quale messaggio Mule deve essere elaborato. Il filtro specifica fondamentalmente le condizioni che devono essere soddisfatte affinché un messaggio venga elaborato e instradato a un servizio.

Modelli

A differenza degli agenti, è un raggruppamento logico di servizi che vengono creati in studio. Abbiamo la libertà di avviare e interrompere tutti i servizi all'interno di un modello specifico.

Services- I servizi sono quelli che avvolgono la nostra logica o i nostri componenti aziendali. Inoltre configura router, endpoint, trasformatori e filtri specificamente per quel servizio.

Endpoints- Può essere definito come un oggetto su cui i servizi invieranno messaggi in entrata (riceveranno) e in uscita (invieranno). I servizi sono connessi tramite endpoint.

Flusso

L'elaboratore di messaggi utilizza i flussi per definire un flusso di messaggi tra un'origine e una destinazione.

Struttura del messaggio del mulo

Un messaggio Mule, completamente racchiuso in Mule Message Object, è il dato che passa attraverso le applicazioni tramite i flussi Mule. Il messaggio della struttura Mule è mostrato nello schema seguente:

Come si vede nel diagramma sopra, Mule Message è composto da due parti principali:

Intestazione

Non è altro che i metadati del messaggio che sono ulteriormente rappresentati dalle seguenti due proprietà:

Inbound Properties- Queste sono le proprietà che vengono impostate automaticamente dall'origine del messaggio. Non possono essere manipolati o impostati dall'utente. In natura, le proprietà in entrata sono immutabili.

Outbound Properties- Queste sono le proprietà che contengono metadati come una proprietà in entrata e possono essere impostate durante il corso del flusso. Possono essere impostati automaticamente da Mule o manualmente da un utente. In natura, le proprietà in uscita sono mutabili.

Le proprietà in uscita diventano proprietà in entrata quando il messaggio passa dall'endpoint in uscita di un flusso all'endpoint in entrata di un flusso diverso tramite un trasporto.

Le proprietà in uscita rimangono proprietà in uscita quando il messaggio viene passato a un nuovo flusso tramite un flusso di riferimento anziché un connettore.

Carico utile

Il messaggio commerciale effettivo trasportato dall'oggetto messaggio è chiamato payload.

Variabili

Può essere definito come metadati definiti dall'utente su un messaggio. Fondamentalmente, le variabili sono informazioni temporanee su un messaggio utilizzato dall'applicazione che lo sta elaborando. Non è pensato per essere passato insieme ai messaggi alla sua destinazione. Sono di tre tipi come indicato di seguito:

Flow variables - Queste variabili si applicano solo al flusso in cui esistono.

Session variables - Queste variabili si applicano a tutti i flussi all'interno della stessa applicazione.

Record variables - Queste variabili si applicano solo ai record elaborati come parte di un batch.

Allegati e carico utile extra

Questi sono alcuni metadati extra sul payload del messaggio che non sono necessariamente visualizzati ogni volta nell'oggetto messaggio.