streamalism.org

1. Oversigt

Enterprise Java Beans (EJB) er kernedelen af ​​Java EE-specifikationen, der har til formål at forenkle udviklingen af ​​distribuerede applikationer på virksomhedsniveau. EJB'ers livscyklus håndteres af en applikationsserver, såsom JBoss WildFly eller Oracle GlassFish.

EJB'er giver en robust programmeringsmodel, der letter implementeringen af ​​softwaremoduler på virksomhedsniveau, da det er op til applikationsserveren at håndtere ikke-forretningslogikrelaterede problemer såsom transaktionshåndtering, komponentens livscyklusstyring eller afhængighedsinjektion.

Desuden har vi allerede offentliggjort to artikler, der dækker EJB's grundlæggende koncepter, så du er velkommen til at tjekke dem her og her.

I denne vejledning viser vi, hvordan du implementerer et grundlæggende EJB-modul på WildFly og kalder en EJB fra en fjernklient via en JNDI.

2. Implementering af EJB-modulet

Virksomhedslogik implementeres af enten en eller flere lokale / eksterne forretningsgrænseflader (også kendt som lokale / fjernvisninger) eller direkte gennem klasser, der ikke implementerer nogen grænseflade (ikke-visningsgrænseflader).

Det er værd at bemærke, at lokale forretningsgrænseflader bruges, når bønnen skal tilgås fra klienter, der befinder sig i det samme miljø, dvs. den samme EAR- eller WAR-fil, hvorimod eksterne forretningsgrænseflader er påkrævet, når bønnen skal tilgås fra et andet miljø , dvs. en anden JVM- eller applikationsserver.

Lad os oprette et grundlæggende EJB-modul, der består af kun en bønne. Bønnens forretningslogik vil være ligetil og begrænset til at konvertere en given Snor til dens store bogstaver.

2.1. Definition af en ekstern forretningsgrænseflade

Lad os først definere en enkelt ekstern forretningsgrænseflade, dekoreret med @Fjern kommentar. Dette er obligatorisk ifølge EJB 3.x-specifikationen, da bønnen skal tilgås fra en fjernklient:

@Remote offentlig grænseflade TextProcessorRemote {String processText (String text); }

2.2. Definition af en statsløs bønne

Lad os derefter realisere forretningslogikken ved at implementere den førnævnte fjerngrænseflade:

@Stateless public class TextProcessorBean implementerer TextProcessorRemote {public String processText (String text) {return text.toUpperCase (); }}

Det TextProcessorBean klasse er en simpel Java-klasse, dekoreret med @Stateless kommentar.

Statsløse bønner opretholder pr. Definition ikke nogen samtalestatus med deres klienter, selv når de kan opretholde instansstatus på tværs af forskellige anmodninger. Deres modstykke, stateful beans, bevarer deres samtaletilstand, og de er dyrere at oprette til applikationsserveren.

Som i dette tilfælde har ovenstående klasse ikke nogen instanstilstand, den kan gøres statsløs. Hvis det har en tilstand, ville det overhovedet ikke give mening at bruge det på tværs af forskellige klientanmodninger.

Bønnens adfærd er deterministisk, dvs. den har ingen bivirkninger, som en veldesignet bønne skal være: den tager bare et input Snor og returnerer den store bogstavversion af den.

2.3. Maven afhængigheder

Dernæst skal vi tilføje javaee-api Maven-artefakt til modulet, som indeholder alle Java EE 7-specifikations-API'erne, inklusive dem, der kræves til EJB'er:

 javax javaee-api 7.0 leveret 

På dette tidspunkt er det lykkedes os at oprette et grundlæggende, men alligevel funktionelt EJB-modul. For at gøre det tilgængeligt for alle potentielle kunder er vi nødt til at tilføje artefakten i vores lokale Maven-arkiv som en JAR-fil.

2.4. Installation af EJB-modulet i det lokale lager

Der er flere metoder til at opnå dette. Den mest ligefremme består i at udføre Maven-livscyklussen ren - installer bygge faser:

mvn ren installation

Denne kommando installerer EJB-modulet som ejbmodule-1.0.jar (eller ethvert vilkårligt artefakt-id, der er specificeret i pom.xml fil), i vores lokale arkiv. For yderligere oplysninger om, hvordan du installerer en lokal JAR med Maven, se denne artikel.

Forudsat at EJB-modulet er installeret korrekt i vores lokale arkiv, er det næste trin at udvikle en fjernklientapplikation, der gør brug af vores TextProcessorBean API.

3. Fjern EJB-klient

Vi holder den eksterne EJB-klients forretningslogik ekstremt enkel: først udfører den et JNDI-opslag for at få en TextProcessorBean fuldmagt. Derefter påkalder det proxyerne processText () metode.

3.1. Maven afhængigheder

Vi skal medtage følgende Maven-artefakter, så EJB-klienten fungerer som forventet:

 javax javaee-api 7.0 forudsat org.wildfly wildfly-ejb-client-bom 10.1.0.Final com.beldung.ejbmodule ejbmodule 1.0 

Selvom det er ret indlysende, hvorfor vi inkluderer javaee-api artefakt, inddragelse af wildfly-ejb-klient-bom er ikke. Artefakten er påkrævet for at udføre eksterne EJB-invokationer på WildFly.

Sidst men ikke mindst er vi nødt til at gøre det forrige EJB-modul tilgængeligt for klienten, så det er derfor, vi tilføjede ejbmodul afhængighed også.

3.2. EJB-klientklasse

I betragtning af at EJB-klienten kalder en proxy for TextProcessorBean, vi er meget pragmatiske og navngiver klientklassen Tekstapplikation:

offentlig klasse TextApplication {public static void main (String [] args) throw NamingException {TextProcessorRemote textProcessor = EJBFactory .createTextProcessorBeanFromJNDI ("ejb:"); System.out.print (textProcessor.processText ("eksempeltekst")); } privat statisk klasse EJBFactory {privat statisk TextProcessorRemote createTextProcessorBeanFromJNDI (String namespace) kaster NamingException {return lookupTextProcessorBean (namespace); } privat statisk TextProcessorRemote lookupTextProcessorBean (String navneområde) kaster NamingException {Context ctx = createInitialContext (); String appName = ""; String moduleName = "EJBModule"; String distinctName = ""; String beanName = TextProcessorBean.class.getSimpleName (); Streng viewClassName = TextProcessorRemote.class.getName (); returner (TextProcessorRemote) ctx.lookup (namespace + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName); } privat statisk kontekst createInitialContext () kaster NamingException {Properties jndiProperties = new Properties (); jndiProperties.put (Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); jndiProperties.put (Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); jndiProperties.put (Context.PROVIDER_URL, "http-remoting: // localhost: 8080"); jndiProperties.put ("jboss.naming.client.ejb.context", sandt); returner nyt InitialContext (jndiProperties); }}}

Kort sagt, alt det der Tekstapplikationklasse gør er at hente bønneproxyen og kalde dens processText () metode med en prøve streng.

Den aktuelle opslag udføres af den indlejrede klasse EJBFabrik, som først opretter en JNDI InitialContext eksempel, sender derefter de krævede JNDI-parametre til konstruktøren og bruger den til sidst til at slå bønneproxyen op.

Bemærk, at opslaget udføres ved hjælp af WildFlys proprietære "ejb:" navneområde. Dette optimerer opslagsprocessen, da klienten afviser forbindelsen til serveren, indtil proxyen udtrykkeligt påberåbes.

Det er også værd at bemærke, at det er muligt at slå op i bønneproxyen uden at bruge "ejb" -navnet overhovedet. Imidlertid, vi ville gå glip af alle de ekstra fordele ved dovne netværksforbindelser, hvilket gør klienten meget mindre performant.

3.3. Opsætning af EJB-kontekst

Klienten skal vide, hvilken vært og port, der skal oprette forbindelse til for at udføre bønneopslag. I dette omfang klienten kræver opsætning af den proprietære WildFly EJB-kontekst, som er defineret med jboss-ejb-client.properties fil placeres i sin klassesti, normalt under src / main / ressourcer folder:

endpoint.name = klient-slutpunkt remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED = falske remote.connections = standard remote.connection.default.host = 127.0.0.1 remote.connection.default.port = 8080 fjernbetjening .connection.default.connect.options.org.xnio.Options .SASL_POLICY_NOANONYMOUS = falsk remote.connection.default.username = mit brugernavn remote.connection.default.password = mypassword

Filen er ret selvforklarende, da den indeholder alle de parametre, der kræves for at oprette en forbindelse til WildFly, inklusive standardantal fjernforbindelser, standardværten og porten og brugeroplysningerne. I dette tilfælde er forbindelsen ikke krypteret, men det kan være, når SSL er aktiveret.

Den sidste ting at tage i betragtning er, at hvis forbindelsen kræver godkendelse, er det nødvendigt at tilføje en bruger til WildFly via add-user.sh/add-user.bat hjælpeprogram.

4. Konklusion

At udføre EJB-opslag på WildFly er ligetil, så længe vi strengt overholder den skitserede proces.

Som sædvanligt er alle eksemplerne i denne artikel tilgængelige på GitHub her og her.