Programmering

Implementere en brugerdefineret ESB med Java

Overvej en virksomhed, hvor du har heterogene applikationer, muligvis leveret af forskellige teams, der har brug for at interagere med hinanden, men som har følgende begrænsninger:

  • Hver applikation er ikke nødvendigvis bygget ved hjælp af den samme teknologi og taler muligvis ikke med de andre ved hjælp af dens oprindelige indkaldelsesmekanisme, f.eks. Et J2EE-program og .Net-program.
  • Fortrinsvis bør hver applikation ikke omdanne sine anmodninger til det format, der forstås af målapplikationen. Plus, virksomheden har mange applikationer, der bruger målapplikationen.
  • Servicekomponenter skal bruge en påkalds- eller anmodningsmekanisme, der er naturlig for dem. For eksempel kan en eksisterende J2EE-applikation kun modtage anmodninger via Java Message Service (JMS).
  • Virksomheden bevæger sig mod en arkitektur, hvor en applikation kun vedrører sig, en, hvad den ved, og to, hvad den skal videregive som parametre, når den ønsker at opnå tjenester fra en anden applikation inden for virksomheden.

Andre begrænsninger kan kræve, at du har en infrastruktur, der gør det muligt for heterogene applikationer at integrere problemfrit uden at ændre deres design. En enterprise-servicebus (ESB) er en måde at realisere en sådan arkitektur til arkitekturintegration på.

Selvom hver virksomhed sandsynligvis opretter sin ESB på sin egen unikke måde, er det vigtigt at huske fleksibilitet, når man overvejer definitionen af ​​en ESB. Der er ingen fast tilgang til at bygge en. Ideen er at have et forbindelseslag, der optimerer interaktioner mellem serviceforbrugere og tjenesteudbydere, et som kan reagere på begivenheds-, meddelelses- eller serviceorienterede sammenhænge.

Denne artikel diskuterer en tilgang til opbygning af en udvidelig Java-baseret ESB, der understøtter de mest almindelige ESB-funktionelle krav.

Almindelige ESB-krav

En ESBs fælles krav er også de mest anvendte funktioner:

  1. Routing: ESB skal tilvejebringe en effektiv og fleksibel rutemekanisme.
  2. Transformation: En servicekomponent behøver ikke at kende anmodningsformatet for den måltjeneste, som den muligvis påberåber sig. Baseret på rekvirenten og målet skal ESB være i stand til at anvende den passende transformation på anmodningen, så målet kan forstå det.
  3. Multiprotokol transport: En ESB-implementering, der kun taler om JMS eller kun webtjenester, er ikke af stor værdi. Det skal være udvideligt nok til at understøtte flere beskedprotokoller afhængigt af virksomhedens behov.
  4. Sikkerhed: Hvis det er nødvendigt, skal ESB håndhæve godkendelse og autorisation for adgang til forskellige servicekomponenter.

Figur 1 viser en ESBs vigtigste arkitektoniske komponenter. Den har tre brede rum:

  1. Modtager: En ESB udsætter forskellige grænseflader for at tillade klientapplikationerne at sende meddelelser til ESB. For eksempel kan en servlet modtage HTTP-anmodninger om ESB. På samme tid kan du have en MDB (meddelelsesdrevet bønne), der lytter på en JMS-destination, hvor klientapplikationer kan sende meddelelser.
  2. Kerne: Dette er hoveddelen af ​​implementeringen af ​​ESB. Det håndterer routing og transformation og anvender sikkerhed. Det er typisk sammensat af en MDB, der modtager de indgående anmodninger og derefter, baseret på meddelelseskonteksten, anvender den passende transformation, routing og sikkerhed. Detaljer om routing, transport, transformation og sikkerhedsoplysninger kan specificeres i et XML-dokument (diskuteres kort).
  3. Afsender: Alle udgående transporthåndterere kommer under denne del af ESB. Du kan tilslutte enhver vilkårlig transporthåndterer (e-mail, fax, FTP osv.) Til ESB.

Alle disse ESB-dele limes sammen af ​​et XML-dokument, der viser alle de ruter, som ESB opererer på. De forskellige transporthåndterings-, transformator- og forsøgspolitikker og deres forbindelse til forskellige ruter er alle forbundet via dette XML-dokument.

ESBConfiguration.xml

XML-listen -ESBConfiguration.xml, som vises nedenfor - giver os en idé om en ESBs funktion. De vigtigste elementer af interesse for ESBConfiguration.xml er følgende:

  1. Bønner: Dette element indeholder nul eller mere Bønne elementer.
  2. Bønne: Dette element definerer dybest set den måde, vi opretter og konfigurerer en Bønne klasse. Det har følgende attributter:
    • navn: Unikt navn, der kan bruges til at henvise til denne bønne.
    • className: Fuldt kvalificeret navn på bønneklassen.
    Hver bønne kan have nul eller mere Ejendom elementer som børn. Hver Ejendom element har en attribut navn der identificerer det og et underordnet element af typen Værdi der holder ejendomsværdien. Disse egenskaber er faktisk medlemmer af klassen JavaBeans-stil, der kan konfigurere bønneklassen.
  3. RetryPolicies: Dette element indeholder nul eller mere Prøv igen børn.
  4. Prøv igen: Dette element definerer retry-politikken for en given rute. Det har en attribut navn der kan bruges til at henvise til det. Den har to underordnede elementer navngivet MaxRetries og RetryInterval.
  5. Rute: Det EsbConfiguration rodelement kan indeholde nul eller flere underordnede elementer af denne type. Det repræsenterer dybest set en rute for ESB. Det har følgende attributter:
    • navn: Unikt navn, der kan bruges til at henvise til denne rute.
    • prøv igenPolicyRef: Henvisning til genforsøgspolitikken. Det skal matche Prøv igen elementets navn attribut.
    • transformerRef: Henvisning til en bønne, der repræsenterer transformeren. Det skal matche Bønne elementets navn attribut.
    Det Rute element kan have et eller flere underordnede elementer af typen TransportHåndtererRef. Dette barn peger dybest set på en bønne, der repræsenterer en passende transporthåndterer, der skal bruges til denne rute, og det offentlige metodenavn på den bønne, der skal påberåbes for at sende meddelelsen. Eventuelt kan Rute element kan have en DeadLetterDestination barn, der peger på en anden rute, der repræsenterer en dødbogstavsdestination.

Et eksempel på XML-dokument, EsbConfiguration.xmlvises nedenfor:

                              qcf-1 myCreditQueue //www.tax.com/calc file: /// C: /temp/esb/transform/xsl/credit.xsl file: /// C: / temp / esb / transform / custom / configManager. egenskaber qcf-1 Redelivery.Queue qcf-1 System.DL.Queue qcf-1 System.Error.Queue qcf-1 Redelivery.Request.Topic 10100 10 500 

ESB opførsel

Det ESBConfiguration.xml dokument dikterer vores ESBs adfærd. Det EsbRouter MDB indlæser denne XML fra et sted, der er angivet i dens installationsbeskrivelse. Oplysningerne, den indeholder, organiseres derefter i en datastruktur, der er afbildet i figur 2 nedenfor.

Det EsbRouter bruger disse oplysninger (via EsbConfigManager) for at dechifrere den passende rute, den transformation, hvis der er nogen, der skal anvendes, sikkerhedstilladelseskontrollen osv. Det vigtige punkt, der skal bemærkes, er den måde, afhængighedsinjektionsteknikken sammen med arv er blevet brugt til at afkoble forskellige funktioner (f.eks. som multiprotokol-meddelelsestransport og meddelelsestransformation) af ESB, hvilket gør det muligt at være meget udvidelig og tilpasselig.

Som klassediagrammet viser er der to vigtige grænseflader i ESB-designet: TransformHandler og Transporthåndterer. De giver dig mulighed for at skrive en specifik transformation og transportimplementering til rutede meddelelser. Disse implementeringsklasser kan derefter forbindes med ruterne via Bønne elementer i EsbConfiguration. For eksempel i prøven EsbConfiguration.xml dokument, den følgende bønnedefinition specificerer transporthåndteringen:

   myQCF myCreditQueue 

Denne transporthandler kan derefter henvises til i a Rute knude ved at indsætte en Transporthåndterer barn til det sådan:

Bemærk
Den fremgangsmåde, der er beskrevet i denne artikel, bruger Java-grænseflader til at definere transport- og transformhandlerne. Enhver ny handler bliver således nødt til at implementere den krævede grænseflade, hvilket kan virke påtrængende. Du kan nemt ændre EsbConfigManager at bruge Dependency Injection til at kalde en vilkårlig metode i en implementeringsklasse, hvilket eliminerer behovet for at implementere en interface. Men siden EsbRouter passerer altid en javax.jms.Meddelelse For eksempel skal din handlerimplementeringsklasse bruge typen javax.jms. besked alligevel.
$config[zx-auto] not found$config[zx-overlay] not found