streamalism.org

1. Oversikt

Mule ESB er en lett Java-basert Enterprise Service Bus. Det lar utviklere koble flere applikasjoner sammen ved å utveksle data i forskjellige formater. Den bærer data i form av en melding.

ESB tilbyr kraftige funksjoner ved å tilby en rekke tjenester, for eksempel:

• Oppretting og hosting av tjenester
• Tjenestemegling
• Melding ruting
• Datatransformasjon

Vi vil finne ESBs nyttige hvis vi trenger å integrere flere applikasjoner sammen, eller hvis vi har tanken om å legge til flere applikasjoner i fremtiden.

ESB brukes også til å håndtere mer enn en type kommunikasjonsprotokoll, og når det er nødvendig med funksjoner for ruting av meldinger.

La oss lage et prøveprosjekt i avsnitt 5 ved hjelp av AnyPoint Studio som er tilgjengelig for nedlasting her.

2. Mule Meldingsstruktur

Enkelt sagt, det primære formålet med en ESB er å formidle mellom tjenester og dirigere meldinger til forskjellige sluttpunkter. Så det må håndtere forskjellige typer innhold eller nyttelast.

Meldingsstrukturen er delt inn i to deler:

• Overskriften, sominneholder meldingsmetadata
• Nyttelasten, som inneholder forretningsspesifikke data

Meldingen er innebygd i et meldingsobjekt. Vi kan hente meldingsobjektet fra konteksten. Vi kan endre egenskapene og nyttelasten ved hjelp av egendefinerte Java-komponenter og transformatorer inne i en Mule-strøm.

Hver applikasjon består av en eller flere strømmer.

I en flyt kan vi bruke komponenter for å få tilgang til, filtrere eller endre en melding og dens forskjellige egenskaper.

For eksempel kan vi få en forekomst av en melding ved hjelp av Java-komponenten. Denne komponentklassen implementerer a Kan kalles grensesnitt fra org.mule.api.lifecycle pakke:

public Object onCall (MuleEventContext eventContext) kaster Unntak {MuleMessage melding = eventContext.getMessage (); message.setPayload ("Meldingens nyttelast endres her."); returmelding; }

3. Egenskaper og variabler

Meldingsmetadata består av egenskaper. Variabler representerer data om en melding. Hvordan egenskaper og variabler brukes på tvers av meldingens livssyklus, defineres av omfanget av dem. Eiendommer kan være av to typer, basert på omfanget: inngående og utgående.

Innkommende eiendommer inneholder metadata som forhindrer at meldinger blir kryptert mens de krysser over strømmer. Innkommende egenskaper er uforanderlige og kan ikke endres av brukeren. De er bare til stede i løpet av flyten - når meldingen går ut av strømmen, er innkommende egenskaper ikke lenger der.

Utgående eiendommer kan settes automatisk av Mule, eller en bruker kan stille dem gjennom strømningskonfigurasjon. Disse egenskapene er mutable. De blir inngående egenskaper når en melding kommer inn i en annen flyt etter å ha krysset transportbarrierer.

Vi kan angi og få henholdsvis utgående og inngående egenskaper ved å ringe tilknyttede setter- og gettermetoder i deres respektive omfang:

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

Det er to typer variabler tilgjengelig for å deklarere i applikasjoner.

Den ene er flytvariabel som er lokal i forhold til en muldyrstrøm og tilgjengelig over strømmen, delstrømmen og den private strømmen.

Sessionsvariabler som en gang er erklært blir tilgjengelige i hele applikasjonen.

4. Transportbarrierer og flyt-ref

Transportbarrierer er HTTP-kontakter, virtuelle maskiner, JMS eller lignende kontakter som krever stier eller sluttpunkter for at meldinger skal rutes. Flytvariabler er ikke tilgjengelige på tvers av transportbarrierer, men sesjonsvariabler er tilgjengelige over hele prosjektet i alle flyter.

Når vi trenger å lage delstrøm eller privatflyt, kan vi referere til strømmen fra en overordnet eller en annen strømning ved hjelp av flyt-ref komponent. Både flytvariabler og sesjonsvariabler er tilgjengelige i delstrømmer og private flyter som det refereres til med flyt-ref.

5. Eksempel på prosjekt

La oss lage et program i Anypoint Studio som inneholder flere flyter, som kommuniserer seg imellom via inngående og utgående kontakter.

La oss se på den første flyten:

Vi kan konfigurere en HTTP-lytter som:

Strømningskomponenter må være inne i stikkord. Så et eksempel på flyt med flere komponenter er:

Inne i strømmen gir vi en referanse til en konfigurert HTTP-lytter. Så holder vi en logger for å logge nyttelasten som HTTP-lytteren mottar gjennom POST-metoden.

Etter det plasseres en tilpasset Java-transformatorklasse som forvandler nyttelasten etter å ha mottatt meldingen:

public Object transformMessage (MuleMessage message, String outputEncoding) kaster TransformerException {message.setPayload ("Nyttelast overføres her."); message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); returmelding; }

Transformatorklassen må utvides AbstractMessageTransformer. Vi setter også en utgående eiendom i klassen.

Nå har vi allerede konvertert nyttelast inne i meldingsobjektet, og har logget det i konsollen ved hjelp av logger. Vi setter en flytvariabel og en sesjonsvariabel.

Til slutt sender vi nyttelasten vår gjennom utgående VM-kontakt. Banen i VM-koblingen bestemmer det mottakende endepunktet:

Meldingen som bæres og transformeres av den innledende strømmen når Flyt1 gjennom et inngående VM-sluttpunkt.

Java-komponenten henter utgående egenskaper satt av den første flyten og returnerer objektet som blir meldingsnyttelasten.

De transformMessage () metode for denne oppgaven:

public Object transformMessage (MuleMessage message, String outputEncoding) kaster TransformerException {return (String) message.getInboundProperty ("outboundKey"); }

Deretter settes flyte- og øktvariabler til den andre flyten. Etter det har vi en referanse til Flyt2 ved hjelp av flyt-ref komponent.

I Flow2, Vi har forvandlet meldingen ved hjelp av Java-komponentklasse og logget den i konsollen. Vi har også satt en flytvariabel F3.

Etter å ha ringt Flyt2 ved hjelp av flow-ref, Flow1 vil vente på at meldingen skal behandles i Flyt2.

Enhver strømvariabel som er satt inn Flyt1 og Flyt2 vil være tilgjengelig i begge strømmer siden disse strømningene ikke er skilt av transportbarrierer.

Til slutt sendes meldingen tilbake til HTTP-forespørselen gjennom virtuelle maskiner. Vi konfigurerte alle virtuelle maskiner som forespørselssvar.

Vi kan påkalle denne applikasjonen fra en hvilken som helst REST-klient ved å legge ut JSON-data i kroppen. URLen blir lokal vert: 8081 som konfigurert i HTTP-lytter.

6. Maven Archetype

Vi kan bygge et Mule ESB-prosjekt ved hjelp av Mulesofts Maven-arketype.

I Maven settings.xml filen, må vi først legge til org.mule.tools plugin-gruppe:

 org.mule.tools 

Deretter må vi legge til en profil tag som sier hvor Maven skal se etter Mulesoft-gjenstander:

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

Til slutt kan vi lage prosjektet ved hjelp av muldyr-prosjekt-arketype: lage:

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

Etter å ha konfigurert prosjektet vårt, kan vi opprette et distribuerbart arkiv ved hjelp av mvn-pakke.

Etter det vil vi distribuere arkivet i apper mappen til hvilken som helst frittstående Mule-server.

7. En frittstående Mule-server via MuleSofts Maven Repository

Som nettopp nevnt krever prosjektet vi nettopp opprettet en frittstående Mule-server.

Hvis vi ikke allerede har en, kan vi redigere pom.xml å trekke en fra MuleSofts Maven-arkiv:

 org.mule.tools.maven mule-maven-plugin 2.2.1 frittstående 3.9.0 distribuere distribuere distribuere 

8. Konklusjon

I denne artikkelen har vi gått gjennom forskjellige nødvendige konsepter for å bygge som ESB-applikasjon i Mule. Vi har laget et eksempelprosjekt som illustrerer alle de beskrevne konseptene.

Vi kan nå begynne å lage ESB-applikasjoner ved hjelp av Anypoint Studio for å dekke våre ulike behov.

Som vanlig kan du finne hele prosjektet på GitHub.

1. Oversikt

Mule ESB er en lett Java-basert Enterprise Service Bus. Det lar utviklere koble flere applikasjoner sammen ved å utveksle data i forskjellige formater. Den bærer data i form av en melding.

ESB tilbyr kraftige funksjoner ved å tilby en rekke tjenester, for eksempel:

• Oppretting og hosting av tjenester
• Tjenestemegling
• Melding ruting
• Datatransformasjon

Vi vil finne ESBs nyttige hvis vi trenger å integrere flere applikasjoner sammen, eller hvis vi har tanken om å legge til flere applikasjoner i fremtiden.

ESB brukes også til å håndtere mer enn en type kommunikasjonsprotokoll, og når det er nødvendig med funksjoner for ruting av meldinger.

La oss lage et eksempelprosjekt i avsnitt 5 ved hjelp av AnyPoint Studio som er tilgjengelig for nedlasting her.

2. Mule Meldingsstruktur

Enkelt sagt, det primære formålet med en ESB er å formidle mellom tjenester og dirigere meldinger til forskjellige sluttpunkter. Så det må håndtere forskjellige typer innhold eller nyttelast.

Meldingsstrukturen er delt inn i to deler:

• Overskriften, sominneholder meldingsmetadata
• Nyttelasten, som inneholder forretningsspesifikke data

Meldingen er innebygd i et meldingsobjekt. Vi kan hente meldingsobjektet fra konteksten. Vi kan endre egenskapene og nyttelasten ved hjelp av egendefinerte Java-komponenter og transformatorer inne i en Mule-strøm.

Hver applikasjon består av en eller flere strømmer.

I en flyt kan vi bruke komponenter for å få tilgang til, filtrere eller endre en melding og dens forskjellige egenskaper.

For eksempel kan vi få en forekomst av en melding ved hjelp av Java-komponenten. Denne komponentklassen implementerer a Kan kalles grensesnitt fra org.mule.api.lifecycle pakke:

public Object onCall (MuleEventContext eventContext) kaster Unntak {MuleMessage melding = eventContext.getMessage (); message.setPayload ("Meldingens nyttelast endres her."); returmelding; }

3. Egenskaper og variabler

Meldingsmetadata består av egenskaper. Variabler representerer data om en melding. Hvordan egenskaper og variabler brukes over meldingens livssyklus, defineres av omfanget av dem. Eiendommer kan være av to typer, basert på omfanget: inngående og utgående.

Innkommende eiendommer inneholder metadata som forhindrer at meldinger blir kryptert mens de krysser over strømmer. Innkommende egenskaper er uforanderlige og kan ikke endres av brukeren. De er tilstede bare for varigheten av flyten - når meldingen går ut av strømmen, er ikke innkommende egenskaper lenger.

Utgående eiendommer kan settes automatisk av Mule, eller en bruker kan stille dem gjennom strømningskonfigurasjon. Disse egenskapene er mutable. De blir inngående egenskaper når en melding kommer inn i en annen flyt etter å ha krysset transportbarrierer.

Vi kan angi og få henholdsvis utgående og innkommende egenskaper ved å ringe tilknyttede setter- og gettermetoder i deres respektive omfang:

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

Det er to typer variabler tilgjengelig for å deklarere i applikasjoner.

Den ene er flytvariabel som er lokal i forhold til en muldyrstrøm og tilgjengelig over strømmen, delstrømmen og den private strømmen.

Sessionsvariabler som en gang er erklært blir tilgjengelige i hele applikasjonen.

4. Transportbarrierer og flyt-ref

Transportbarrierer er HTTP-kontakter, virtuelle maskiner, JMS eller lignende kontakter som krever stier eller sluttpunkter for at meldinger skal rutes. Flytvariabler er ikke tilgjengelige på tvers av transportbarrierer, men sesjonsvariabler er tilgjengelige over hele prosjektet i alle flyter.

Når vi trenger å lage delstrøm eller privatflyt, kan vi referere til strømmen fra en overordnet eller en annen strømning ved hjelp av flyt-ref komponent. Både flytvariabler og sesjonsvariabler er tilgjengelige i delstrømmer og private flyter som det refereres til med flyt-ref.

5. Eksempel på prosjekt

La oss lage et program i Anypoint Studio som inneholder flere flyter, som kommuniserer seg imellom via inngående og utgående kontakter.

La oss se på den første flyten:

Vi kan konfigurere en HTTP-lytter som:

Strømningskomponenter må være inne i stikkord. Så et eksempel på flyt med flere komponenter er:

Inne i strømmen gir vi en referanse til en konfigurert HTTP-lytter. Så holder vi en logger for å logge nyttelasten som HTTP-lytter mottar gjennom POST-metoden.

Etter det plasseres en tilpasset Java-transformatorklasse som transformerer nyttelasten etter å ha mottatt meldingen:

public Object transformMessage (MuleMessage message, String outputEncoding) kaster TransformerException {message.setPayload ("Nyttelast overføres her."); message.setProperty ("outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); returmelding; }

Transformatorklassen må utvides AbstractMessageTransformer. Vi setter også en utgående eiendom i klassen.

Nå har vi allerede konvertert nyttelast inne i meldingsobjektet, og har logget det i konsollen ved hjelp av logger. Vi setter en flytvariabel og en sesjonsvariabel.

Til slutt sender vi nyttelasten vår gjennom utgående VM-kontakt. Banen i VM-koblingen bestemmer det mottakende endepunktet:

Meldingen som bæres og transformeres av den innledende strømmen når Flyt1 gjennom et inngående VM-sluttpunkt.

Java-komponenten henter utgående egenskaper satt av den første flyten og returnerer objektet som blir meldingsnyttelasten.

De transformMessage () metode for denne oppgaven:

public Object transformMessage (MuleMessage message, String outputEncoding) kaster TransformerException {return (String) message.getInboundProperty ("outboundKey"); }

Deretter settes flyt- og øktvariabler til den andre flyten. Etter det har vi en referanse til Flyt2 ved hjelp av flyt-ref komponent.

I Flow2, Vi har forvandlet meldingen ved hjelp av Java-komponentklasse og logget den i konsollen. Vi har også satt en flytvariabel F3.

Etter å ha ringt Flyt2 ved hjelp av flow-ref, Flow1 vil vente på at meldingen skal behandles i Flyt2.

Enhver strømvariabel som er satt inn Flyt1 og Flyt2 vil være tilgjengelig i begge strømmer siden disse strømningene ikke er skilt av transportbarrierer.

Til slutt sendes meldingen tilbake til HTTP-forespørselen gjennom virtuelle maskiner. Vi konfigurerte alle virtuelle maskiner som forespørselssvar.

Vi kan påkalle denne applikasjonen fra en hvilken som helst REST-klient ved å legge ut JSON-data i kroppen. URLen vil være lokal vert: 8081 som konfigurert i HTTP-lytter.

6. Maven Archetype

Vi kan bygge et Mule ESB-prosjekt ved hjelp av Mulesofts Maven-arketype.

I Maven's settings.xml filen, må vi først legge til org.mule.tools plugin-gruppe:

 org.mule.tools 

Deretter må vi legge til en profil tag som sier hvor Maven skal se etter Mulesoft-gjenstander:

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

Til slutt kan vi lage prosjektet ved hjelp av muldyr-prosjekt-arketype: lage:

mvn muldyr-prosjekt-arketype: opprett -DartifactId = muleesb -DmuleVersion = 3.9.0

Etter å ha konfigurert prosjektet vårt, kan vi opprette et distribuerbart arkiv ved hjelp av mvn-pakke.

Etter det vil vi distribuere arkivet i apper mappen til hvilken som helst frittstående Mule-server.

7. En frittstående Mule-server via MuleSofts Maven Repository

Som nettopp nevnt krever prosjektet vi nettopp opprettet en frittstående Mule-server.

Hvis vi ikke allerede har en, kan vi redigere pom.xml å trekke en fra MuleSofts Maven-arkiv:

 org.mule.tools.maven mule-maven-plugin 2.2.1 frittstående 3.9.0 distribuere distribuere distribuere 

8. Konklusjon

I denne artikkelen har vi gått gjennom forskjellige nødvendige konsepter for å bygge som ESB-applikasjon i Mule. Vi har laget et eksempelprosjekt som illustrerer alle de beskrevne konseptene.

Vi kan nå begynne å lage ESB-applikasjoner ved hjelp av Anypoint Studio for å dekke våre forskjellige behov.

Som vanlig kan du finne hele prosjektet på GitHub.