Implementere en tilpassbar ESB med Java

Tenk på et foretak der du har heterogene applikasjoner, muligens levert av forskjellige team, som trenger å samhandle med hverandre, men som har følgende begrensninger:

• Hver applikasjon er ikke nødvendigvis bygget med den samme teknologien og snakker kanskje ikke med de andre ved hjelp av den opprinnelige anropsmekanismen, f.eks. Et J2EE-program og .Net-program.
• Fortrinnsvis bør ikke hver applikasjon transformere forespørslene til formatet som forstås av målapplikasjonen. I tillegg har bedriften mange applikasjoner som bruker målapplikasjonen.
• Servicekomponenter bør bruke en påkallings- eller forespørselsmekanisme som er naturlig for dem. For eksempel kan et eksisterende J2EE-program bare ta imot forespørsler via Java Message Service (JMS).
• Virksomheten beveger seg mot en arkitektur der en applikasjon bare handler om, en, hva den vet, og to, hva den skal passere som parametere når den ønsker å få tjenestene til en annen applikasjon i bedriften.

Andre begrensninger kan kreve at du har en infrastruktur som gjør at heterogene applikasjoner kan integreres sømløst uten å endre design. En enterprise service bus (ESB) er en måte å realisere en slik arkitektur for arkitektonisk virksomhet.

Selv om hver bedrift sannsynligvis vil lage sin ESB på sin egen unike måte, er det viktig å huske fleksibilitet når man vurderer definisjonen av en ESB. Det er ingen fast tilnærming til å bygge en. Tanken er å ha et tilkoblingslag som optimaliserer samspillet mellom tjenesteforbrukere og tjenesteleverandører, et som kan svare på hendelses-, meldings- eller tjenestemessige sammenhenger.

Denne artikkelen diskuterer en tilnærming for å bygge en utvidbar Java-basert ESB som støtter de vanligste ESB-funksjonskravene.

Vanlige ESB-krav

En ESBs vanlige krav er også de mest brukte funksjonene:

1. Rute: ESB bør gi en effektiv og fleksibel rutemekanisme.
2. Transformasjon: En tjenestekomponent trenger ikke å vite forespørselsformatet for måltjenesten som den kan påberope. Basert på rekvirenten og målet, skal ESB kunne bruke passende transformasjon på forespørselen slik at målet kan forstå det.
3. Multiprotokol transport: En ESB-implementering som bare snakker JMS eller bare webtjenester er ikke av stor verdi. Det bør være utvidbart nok til å støtte flere meldingsprotokoller, avhengig av bedriftens behov.
4. Sikkerhet: Om nødvendig bør ESB håndheve godkjenning og autorisasjon for tilgang til forskjellige tjenestekomponenter.

Figur 1 viser en ESBs viktigste arkitektoniske komponenter. Den har tre brede rom:

1. Mottaker: En ESB avslører forskjellige grensesnitt for å la klientapplikasjonene sende meldinger til ESB. For eksempel kan en servlet motta HTTP-forespørsler for ESB. Samtidig kan du ha en MDB (meldingsdrevet bønne) som lytter på en JMS-destinasjon der klientapplikasjoner kan sende meldinger.
2. Kjerne: Dette er hoveddelen av implementeringen av ESB. Den håndterer ruting og transformasjon, og bruker sikkerhet. Vanligvis er den sammensatt av en MDB som mottar innkommende forespørsler, og deretter, basert på meldingskonteksten, bruker passende transformasjon, ruting og sikkerhet. Detaljer om ruting, transport, transformasjon og sikkerhetsinformasjon kan spesifiseres i et XML-dokument (diskuteres kort tid).
3. Avsender: Alle utgående transporthåndterere kommer under denne delen av ESB. Du kan koble hvilken som helst vilkårlig transportbehandler (e-post, faks, FTP, etc.) til ESB.

Alle disse ESB-delene limes sammen av et XML-dokument som viser alle rutene som ESB opererer på. De forskjellige transporthåndterings-, transformator- og forsøkspolicyene og deres tilknytning til forskjellige ruter er koblet via dette XML-dokumentet.

ESBConfiguration.xml

XML-oppføringen -ESBConfiguration.xml, som vises nedenfor — gir oss en ide om en ESBs funksjon. Hovedelementene av interesse for ESBConfiguration.xml er følgende:

1. Bønner: Dette elementet inneholder null eller mer Bønne elementer.
2. Bønne: Dette elementet definerer i utgangspunktet måten vi oppretter og konfigurerer en Bønne klasse. Den har følgende attributter:
   • Navn: Unikt navn som kan brukes til å referere til denne bønnen.
   • klassenavn: Fullt kvalifisert navn på bønneklassen.
   Hver bønne kan ha null eller mer Eiendom elementer som barn. Hver Eiendom element har et attributt Navn som identifiserer det og et underordnet element av typen Verdi som holder eiendomsverdien. Disse egenskapene er faktisk medlemmer av klassen JavaBeans-stil som kan konfigurere bønneklassen.
3. Prøv på nytt: Dette elementet inneholder null eller mer Prøv på nytt barn.
4. Prøv på nytt: Dette elementet definerer policyen for forsøk på nytt for en gitt rute. Den har en attributt Navn som kan brukes til å referere til det. Den har to barneelementer navngitt MaxRetries og RetryInterval.
5. Rute: The EsbConfiguration rotelement kan inneholde null eller flere underordnede elementer av denne typen. Det representerer i utgangspunktet en rute for ESB. Den har følgende attributter:
   • Navn: Unikt navn som kan brukes til å referere til denne ruten.
   • prøv på nyttPolicyRef: Henvisning til retry policy. Det skal samsvare med Prøv på nytt elementets Navn Egenskap.
   • transformatorRef: Henvisning til en bønne som representerer transformatoren. Det skal matche Bønne elementets Navn Egenskap.
   De Rute element kan ha ett eller flere underordnede elementer av typen TransportHandlerRef. Dette barnet peker i utgangspunktet på en bønne som representerer en passende transportbehandler som skal brukes til denne ruten, og det offentlige metodenavnet på den bønnen som skal påkalles for å sende meldingen. Eventuelt kan Rute element kan ha en DeadLetterDestination barn som peker på en annen rute som representerer en destinasjon med død bokstav.

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

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

ESB oppførsel

De ESBConfiguration.xml dokumentet dikterer ESBs oppførsel. De EsbRouter MDB laster denne XML-en fra et sted spesifisert i distribusjonsbeskrivelsen. Informasjonen den inneholder blir deretter organisert i en datastruktur vist i figur 2 nedenfor.

De EsbRouter bruker denne informasjonen (via EsbConfigManager) for å dechiffrere den aktuelle ruten, transformasjonen som eventuelt skal brukes, sikkerhetstillatelseskontrollen osv. Det viktige poenget å merke seg er måten avhengighetsinjeksjonsteknikken sammen med arv har blitt brukt til å koble fra forskjellige funksjoner (slik som multiprotokolmeldingstransport og meldingstransformasjon) av ESB, slik at den kan være svært utvidbar og tilpassbar.

Som klassediagrammet viser, er to viktige grensesnitt i ESB-designet: TransformHandler og TransportHandler. De lar deg skrive en spesifikk transformasjon og transportimplementering for rutede meldinger. Disse implementeringsklassene kan deretter kobles til rutene via Bønne elementer i EsbConfiguration. For eksempel i utvalget EsbConfiguration.xml dokumentet, definerer følgende bønnedefinisjon transportbehandleren:

   myQCF myCreditQueue 

Denne transportføreren kan da refereres til i a Rute node ved å sette inn en TransportHandler barn til det slik: