streamalism.org

1. Overzicht

Mule ESB is een lichtgewicht op Java gebaseerde Enterprise Service Bus. Het stelt ontwikkelaars in staat om meerdere applicaties met elkaar te verbinden door gegevens in verschillende formaten uit te wisselen. Het bevat gegevens in de vorm van een bericht.

ESB's bieden krachtige mogelijkheden door een aantal diensten aan te bieden, zoals:

• Service creatie en hosting
• Servicebemiddeling
• Berichtroutering
• Datatransformatie

We zullen ESB's nuttig vinden als we meerdere applicaties samen moeten integreren, of als we het idee hebben om in de toekomst meer applicaties toe te voegen.

ESB wordt ook gebruikt voor het omgaan met meer dan één type communicatieprotocol en wanneer berichtrouteringsmogelijkheden vereist zijn.

Laten we een voorbeeldproject maken in sectie 5 met AnyPoint Studio die u hier kunt downloaden.

2. Mule berichtstructuur

Simpel gezegd, het primaire doel van een ESB is om te bemiddelen tussen services en routeberichten naar verschillende eindpunten. Het moet dus omgaan met verschillende soorten inhoud of payload.

De berichtstructuur is opgedeeld in twee delen:

• De koptekst, diebevat metagegevens van berichten
• De payload, die bedrijfsspecifieke gegevens bevat

Het bericht is ingebed in een berichtobject. We kunnen het berichtobject uit de context halen. We kunnen de eigenschappen en payload wijzigen met behulp van aangepaste Java-componenten en transformatoren in een Mule-stroom.

Elke applicatie bestaat uit een of meer stromen.

In een stroom kunnen we componenten gebruiken om een ​​bericht en zijn verschillende eigenschappen te openen, te filteren of te wijzigen.

We kunnen bijvoorbeeld een exemplaar van een bericht verkrijgen met behulp van een Java-component. Deze componentklasse implementeert een Oproepbaar interface van org.mule.api.lifecycle pakket:

public Object onCall (MuleEventContext eventContext) genereert uitzondering {MuleMessage message = eventContext.getMessage (); message.setPayload ("De payload van het bericht wordt hier gewijzigd."); terug bericht; }

3. Eigenschappen en variabelen

Metagegevens van berichten bestaan ​​uit eigenschappen. Variabelen vertegenwoordigen gegevens over een bericht. Hoe eigenschappen en variabelen worden toegepast gedurende de levenscyclus van het bericht, wordt bepaald door hun bereik. Eigenschappen kunnen van twee typen zijn, op basis van hun bereik: inkomend en uitgaand.

Inkomende eigenschappen bevatten metagegevens die voorkomen dat berichten vervormd raken tijdens het doorlopen van stromen. Inkomende eigenschappen zijn onveranderlijk en kunnen niet door de gebruiker worden gewijzigd. Ze zijn alleen aanwezig voor de duur van de stroom - zodra het bericht de stroom verlaat, zijn inkomende eigenschappen er niet meer.

Uitgaande eigenschappen kunnen automatisch worden ingesteld door Mule, of een gebruiker kan ze instellen via stroomconfiguratie. Deze eigenschappen zijn veranderlijk. Ze worden inkomende eigenschappen wanneer een bericht een andere stroom binnenkomt na het passeren van transportbarrières.

We kunnen respectievelijk uitgaande en inkomende eigenschappen instellen en ophalen door de bijbehorende setter- en getter-methoden in hun respectieve bereiken aan te roepen:

message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); String inboundProp = (String) message.getInboundProperty ("outboundKey");

Er zijn twee soorten variabelen beschikbaar om in applicaties te declareren.

De ene is een stroomvariabele die lokaal is voor een Mule-stroom en beschikbaar is voor de stroom, deelstromen en privéstromen.

Eenmaal gedeclareerde sessievariabelen komen beschikbaar in de hele applicatie.

4. Transportbelemmeringen en flow-ref

Transportbelemmeringen zijn HTTP-connectoren, VM's, JMS of vergelijkbare connectoren waarvoor paden of eindpunten nodig zijn om berichten te kunnen routeren. Stroomvariabelen zijn niet beschikbaar over transportbelemmeringen heen, maar sessievariabelen zijn beschikbaar in het hele project in alle stromen.

Wanneer we een substroom of privéstroom moeten maken, kunnen we verwijzen naar de stroom van een bovenliggende of een andere stroom met flow-ref component. Zowel stroomvariabelen als sessievariabelen zijn beschikbaar in deelstromen en privéstromen waarnaar wordt verwezen met flow-ref.

5. Voorbeeldproject

Laten we een applicatie maken in Anypoint Studio die meerdere stromen bevat, die onderling communiceren via inkomende en uitgaande connectoren.

Laten we naar de eerste stroom kijken:

We kunnen een HTTP-luisteraar configureren als:

Stroomcomponenten moeten zich binnen een label. Een voorbeeldstroom met meerdere componenten is dus:

Binnen de stroom bieden we een verwijzing naar een geconfigureerde HTTP-luisteraar. Vervolgens houden we een logger bij om de payload te registreren die de HTTP-luisteraar ontvangt via de POST-methode.

Daarna wordt een aangepaste Java-transformatorklasse geplaatst, die de payload transformeert na ontvangst van het bericht:

openbaar Object transformMessage (MuleMessage-bericht, String outputEncoding) genereert TransformerException {message.setPayload ("Payload wordt hier overgedragen."); message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); terug bericht; }

De transformatorklasse moet worden uitgebreid AbstractMessageTransformer. We plaatsen ook een uitgaande eigenschap binnen de klas.

Nu hebben we de payload al geconverteerd in het berichtobject en hebben we dat in de console vastgelegd met behulp van logger. We stellen een stroomvariabele en een sessievariabele in.

Ten slotte sturen we onze payload via een uitgaande VM-connector. Het pad in de VM-connector bepaalt het ontvangende eindpunt:

De boodschap gedragen en getransformeerd door de eerste stroom bereikt Stroom1 via een inkomend VM-eindpunt.

De Java-component haalt uitgaande eigenschappen op die zijn ingesteld door de eerste stroom en retourneert het object dat de berichtpayload wordt.

De transformMessage () methode voor deze taak:

openbaar object transformMessage (MuleMessage-bericht, String outputEncoding) genereert TransformerException {return (String) message.getInboundProperty ("outboundKey"); }

Vervolgens worden stroom- en sessievariabelen ingesteld op de tweede stroom. Daarna hebben we een verwijzing naar Stroom2 gebruik makend van flow-ref component.

In Stroom2, we hebben het bericht getransformeerd met behulp van de Java-componentklasse en het in de console vastgelegd. We hebben ook een stroomvariabele ingesteld F3.

Na het bellen Stroom2 gebruik makend van flow-ref, Flow1 wacht tot het bericht is verwerkt in Stroom2.

Elke stroomvariabele ingesteld Stroom1 en Stroom2 zal beschikbaar zijn in beide stromen, aangezien deze stromen niet gescheiden zijn door transportbarrières.

Ten slotte wordt het bericht via VM's teruggestuurd naar de HTTP-aanvrager. We hebben alle VM's geconfigureerd als verzoek-antwoord.

We kunnen deze applicatie vanuit elke REST-client aanroepen door alle JSON-gegevens in de body te plaatsen. De URL zal zijn localhost: 8081 zoals geconfigureerd in HTTP-luisteraar.

6. Maven-archetype

We kunnen een Mule ESB-project bouwen met behulp van Mulesoft's Maven-archetype.

In Maven's settings.xml bestand, moeten we eerst het org.mule.tools plugin groep:

 org.mule.tools 

Vervolgens moeten we een profiel tag die zegt waar Maven moet zoeken naar Mulesoft-artefacten:

 Mule Org true mulesoft-releases MuleSoft Repository //repository-master.mulesoft.org/releases/ default 

Ten slotte kunnen we het project maken met mule-project-archetype: create:

mvn mule-project-archetype: create -DartifactId = muleesb -DmuleVersion = 3.9.0

Nadat we ons project hebben geconfigureerd, kunnen we een inzetbaar archief maken met mvn-pakket.

Daarna zouden we het archief in het apps map van een zelfstandige Mule-server.

7. Een zelfstandige Mule Server via MuleSoft's Maven Repository

Zoals zojuist opgemerkt, vereist het project dat we zojuist hebben gemaakt een zelfstandige Mule-server.

Als we er nog geen hebben, kunnen we onze pom.xml om er een uit MuleSoft's Maven-repository te halen:

 org.mule.tools.maven mule-maven-plugin 2.2.1 standalone 3.9.0 implementeren implementeren implementeren 

8. Conclusie

In dit artikel hebben we verschillende noodzakelijke concepten van bouwen als ESB-applicatie in Mule doorgenomen. We hebben een voorbeeldproject gemaakt waarin alle beschreven concepten worden geïllustreerd.

We kunnen nu beginnen met het maken van een ESB-applicatie met Anypoint Studio om aan onze verschillende behoeften te voldoen.

Zoals gewoonlijk is het volledige project te vinden op GitHub.

1. Overzicht

Mule ESB is een lichtgewicht op Java gebaseerde Enterprise Service Bus. Het stelt ontwikkelaars in staat om meerdere applicaties met elkaar te verbinden door gegevens in verschillende formaten uit te wisselen. Het bevat gegevens in de vorm van een bericht.

ESB's bieden krachtige mogelijkheden door een aantal diensten aan te bieden, zoals:

• Service creatie en hosting
• Servicebemiddeling
• Berichtroutering
• Datatransformatie

We zullen ESB's nuttig vinden als we meerdere applicaties samen moeten integreren, of als we het idee hebben om in de toekomst meer applicaties toe te voegen.

ESB wordt ook gebruikt voor het omgaan met meer dan één type communicatieprotocol en wanneer berichtrouteringsmogelijkheden vereist zijn.

Laten we een voorbeeldproject maken in sectie 5 met AnyPoint Studio die u hier kunt downloaden.

2. Mule berichtstructuur

Simpel gezegd, het primaire doel van een ESB is om te bemiddelen tussen services en routeberichten naar verschillende eindpunten. Het moet dus omgaan met verschillende soorten inhoud of payload.

De berichtstructuur is opgedeeld in twee delen:

• De koptekst, diebevat metagegevens van berichten
• De payload, die bedrijfsspecifieke gegevens bevat

Het bericht is ingebed in een berichtobject. We kunnen het berichtobject uit de context halen. We kunnen de eigenschappen en payload ervan wijzigen met behulp van aangepaste Java-componenten en transformatoren in een Mule-stroom.

Elke applicatie bestaat uit een of meer stromen.

In een stroom kunnen we componenten gebruiken om een ​​bericht en zijn verschillende eigenschappen te openen, te filteren of te wijzigen.

We kunnen bijvoorbeeld een exemplaar van een bericht verkrijgen met behulp van een Java-component. Deze componentklasse implementeert een Oproepbaar interface van org.mule.api.lifecycle pakket:

public Object onCall (MuleEventContext eventContext) genereert uitzondering {MuleMessage message = eventContext.getMessage (); message.setPayload ("Bericht payload wordt hier gewijzigd."); terug bericht; }

3. Eigenschappen en variabelen

Metagegevens van berichten bestaan ​​uit eigenschappen. Variabelen vertegenwoordigen gegevens over een bericht. Hoe eigenschappen en variabelen worden toegepast gedurende de levenscyclus van het bericht, wordt bepaald door hun bereik. Eigenschappen kunnen van twee typen zijn, op basis van hun bereik: inkomend en uitgaand.

Inkomende eigenschappen bevatten metagegevens die voorkomen dat berichten vervormd raken tijdens het doorlopen van stromen. Inkomende eigenschappen zijn onveranderlijk en kunnen niet door de gebruiker worden gewijzigd. Ze zijn alleen aanwezig voor de duur van de stroom - zodra het bericht de stroom verlaat, zijn inkomende eigenschappen er niet meer.

Uitgaande eigenschappen kunnen automatisch worden ingesteld door Mule, of een gebruiker kan ze instellen via stroomconfiguratie. Deze eigenschappen zijn veranderlijk. Ze worden inkomende eigenschappen wanneer een bericht een andere stroom binnenkomt na het passeren van transportbarrières.

We kunnen respectievelijk uitgaande en inkomende eigenschappen instellen en ophalen door de bijbehorende setter- en getter-methoden in hun respectieve bereiken aan te roepen:

message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); String inboundProp = (String) message.getInboundProperty ("outboundKey");

Er zijn twee soorten variabelen beschikbaar om in applicaties te declareren.

De ene is een stroomvariabele die lokaal is voor een Mule-stroom en beschikbaar is voor de stroom, deelstromen en privéstromen.

Eenmaal gedeclareerde sessievariabelen komen beschikbaar in de hele applicatie.

4. Transportbelemmeringen en flow-ref

Transportbelemmeringen zijn HTTP-connectoren, VM's, JMS of vergelijkbare connectoren waarvoor paden of eindpunten nodig zijn om berichten te kunnen routeren. Stroomvariabelen zijn niet beschikbaar over transportbelemmeringen heen, maar sessievariabelen zijn beschikbaar in het hele project in alle stromen.

Wanneer we een substroom of privéstroom moeten maken, kunnen we verwijzen naar de stroom van een bovenliggende of een andere stroom met flow-ref component. Zowel stroomvariabelen als sessievariabelen zijn beschikbaar in deelstromen en privéstromen waarnaar wordt verwezen met flow-ref.

5. Voorbeeldproject

Laten we een applicatie maken in Anypoint Studio die meerdere stromen bevat, die onderling communiceren via inkomende en uitgaande connectoren.

Laten we naar de eerste stroom kijken:

We kunnen een HTTP-luisteraar configureren als:

Stroomcomponenten moeten zich binnen een label. Een voorbeeldstroom met meerdere componenten is dus:

Binnen de stroom bieden we een verwijzing naar een geconfigureerde HTTP-luisteraar. Vervolgens houden we een logger bij om de payload te registreren die de HTTP-luisteraar ontvangt via de POST-methode.

Daarna wordt een aangepaste Java-transformatorklasse geplaatst, die de payload transformeert na ontvangst van het bericht:

openbaar Object transformMessage (MuleMessage-bericht, String outputEncoding) genereert TransformerException {message.setPayload ("Payload wordt hier overgedragen."); message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); terug bericht; }

De transformatorklasse moet worden uitgebreid AbstractMessageTransformer. We plaatsen ook een uitgaande eigenschap binnen de klas.

Nu hebben we de payload al geconverteerd in het berichtobject en hebben we dat in de console vastgelegd met behulp van logger. We stellen een stroomvariabele en een sessievariabele in.

Ten slotte sturen we onze payload via een uitgaande VM-connector. Het pad in de VM-connector bepaalt het ontvangende eindpunt:

De boodschap gedragen en getransformeerd door de eerste stroom bereikt Stroom1 via een inkomend VM-eindpunt.

De Java-component haalt uitgaande eigenschappen op die zijn ingesteld door de eerste stroom en retourneert het object dat de berichtpayload wordt.

De transformMessage () methode voor deze taak:

openbaar object transformMessage (MuleMessage-bericht, String outputEncoding) genereert TransformerException {return (String) message.getInboundProperty ("outboundKey"); }

Vervolgens worden stroom- en sessievariabelen ingesteld op de tweede stroom. Daarna hebben we een verwijzing naar Stroom2 gebruik makend van flow-ref component.

In Stroom2, we hebben het bericht getransformeerd met behulp van de Java-componentklasse en het in de console vastgelegd. We hebben ook een stroomvariabele ingesteld F3.

Na het bellen Stroom2 gebruik makend van flow-ref, Flow1 wacht tot het bericht is verwerkt in Stroom2.

Elke stroomvariabele ingesteld Stroom1 en Stroom2 zal beschikbaar zijn in beide stromen aangezien deze stromen niet gescheiden zijn door transportbarrières.

Ten slotte wordt het bericht via VM's teruggestuurd naar de HTTP-aanvrager. We hebben alle VM's geconfigureerd als verzoek-antwoord.

We kunnen deze applicatie aanroepen vanaf elke REST-client door alle JSON-gegevens in de body te plaatsen. De URL zal zijn localhost: 8081 zoals geconfigureerd in HTTP-luisteraar.

6. Maven-archetype

We kunnen een Mule ESB-project bouwen met behulp van Mulesoft's Maven-archetype.

In Maven's settings.xml bestand, moeten we eerst het org.mule.tools plugin groep:

 org.mule.tools 

Vervolgens moeten we een profiel tag die zegt waar Maven moet zoeken naar Mulesoft-artefacten:

 Mule Org true mulesoft-releases MuleSoft Repository //repository-master.mulesoft.org/releases/ default 

Ten slotte kunnen we het project maken met mule-project-archetype: create:

mvn mule-project-archetype: create -DartifactId = muleesb -DmuleVersion = 3.9.0

Nadat we ons project hebben geconfigureerd, kunnen we een inzetbaar archief maken met mvn-pakket.

Daarna zouden we het archief in het apps map van een zelfstandige Mule-server.

7. Een zelfstandige Mule Server via MuleSoft's Maven Repository

Zoals zojuist opgemerkt, vereist het project dat we zojuist hebben gemaakt een zelfstandige Mule-server.

Als we er nog geen hebben, kunnen we onze pom.xml om er een uit MuleSoft's Maven-repository te halen:

 org.mule.tools.maven mule-maven-plugin 2.2.1 standalone 3.9.0 implementeren implementeren implementeren 

8. Conclusie

In dit artikel hebben we verschillende noodzakelijke concepten van bouwen als ESB-applicatie in Mule doorgenomen. We hebben een voorbeeldproject gemaakt waarin alle beschreven concepten worden geïllustreerd.

We kunnen nu beginnen met het maken van een ESB-applicatie met Anypoint Studio om aan onze verschillende behoeften te voldoen.

Zoals gewoonlijk is het volledige project te vinden op GitHub.