streamalism.org

1. Oversikt

Enterprise Java Beans (EJB) er kjernen i Java EE-spesifikasjonen, som tar sikte på å forenkle utviklingen av distribuerte applikasjoner på bedriftsnivå. Livssyklusen til EJB-er håndteres av en applikasjonsserver, som JBoss WildFly eller Oracle GlassFish.

EJB-er tilbyr en robust programmeringsmodell som letter implementeringen av programvaremoduler på bedriftsnivå, da det er opp til applikasjonsserveren å håndtere ikke-forretningslogiske relaterte problemer som transaksjonshåndtering, ledelse av komponentens livssyklus eller injeksjon av avhengighet.

Videre har vi allerede publisert to artikler som dekker EJBs grunnleggende konsepter, så sjekk dem gjerne her og her.

I denne opplæringen viser vi hvordan du implementerer en grunnleggende EJB-modul på WildFly og kaller en EJB fra en ekstern klient via en JNDI.

2. Implementering av EJB-modulen

Virksomhetslogikk implementeres av enten ett eller flere lokale / eksterne forretningsgrensesnitt (også kjent som lokale / eksterne visninger) eller direkte gjennom klasser som ikke implementerer noe grensesnitt (ikke-visningsgrensesnitt).

Det er verdt å merke seg at lokale forretningsgrensesnitt brukes når bønnen skal nås fra klienter som befinner seg i samme miljø, dvs. den samme EAR- eller WAR-filen, mens eksterne forretningsgrensesnitt er påkrevd når bønnen blir tilgjengelig fra et annet miljø , dvs. en annen JVM- eller applikasjonsserver.

La oss lage en grunnleggende EJB-modul, som vil bestå av bare en bønne. Bønnens forretningslogikk vil være grei, begrenset til å konvertere en gitt String til sin store versjon.

2.1. Definere et eksternt forretningsgrensesnitt

La oss først definere ett enkelt eksternt forretningsgrensesnitt, dekorert med @Remote kommentar. Dette er obligatorisk, i henhold til EJB 3.x-spesifikasjonen, da bønnen skal nås fra en ekstern klient:

@Remote offentlig grensesnitt TextProcessorRemote {String processText (strengtekst); }

2.2. Definere en statsløs bønne

Deretter skal vi realisere forretningslogikken ved å implementere det nevnte eksterne grensesnittet:

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

De TextProcessorBean klasse er en enkel Java-klasse, dekorert med @Stateless kommentar.

Statsløse bønner opprettholder per definisjon ikke noen samtalestatus med sine klienter, selv når de kan opprettholde forekomststilstand på tvers av forskjellige forespørsler. Deres motstykke, stateful beans, bevarer deres samtalestatus, og de er dyrere å lage for applikasjonsserveren.

Som i dette tilfellet har ikke ovennevnte klasse noen forekomsttilstand, den kan gjøres statsløs. Hvis det har en tilstand, ville det ikke være fornuftig å bruke det på tvers av forskjellige klientforespørsler.

Bønnens oppførsel er deterministisk, det vil si at den ikke har noen bivirkninger, som en godt designet bønne burde være: den tar bare en innspill String og returnerer den store versjonen av den.

2.3. Maven avhengigheter

Deretter må vi legge til javaee-api Maven artefakt til modulen, som gir alle Java EE 7 spesifikasjon APIer, inkludert de som kreves for EJB:

 javax javaee-api 7.0 gitt 

På dette tidspunktet har vi klart å lage en grunnleggende, men funksjonell EJB-modul. For å gjøre den tilgjengelig for alle potensielle kunder, må vi legge til gjenstanden i vårt lokale Maven-arkiv som en JAR-fil.

2.4. Installere EJB-modulen i Local Repository

Det er flere metoder for å oppnå dette. Den enkleste består i å utføre Maven-livssyklusen rengjør - installer bygge faser:

mvn ren installasjon

Denne kommandoen installerer EJB-modulen som ejbmodule-1.0.jar (eller noe vilkårlig artefakt-ID spesifisert i pom.xml fil), i vårt lokale depot. For mer informasjon om hvordan du installerer en lokal JAR med Maven, sjekk ut denne artikkelen.

Forutsatt at EJB-modulen er riktig installert i vårt lokale depot, er neste trinn å utvikle en ekstern klientapplikasjon som bruker vår TextProcessorBean API.

3. Ekstern EJB-klient

Vi vil holde den eksterne EJB-klientens forretningslogikk ekstremt enkel: først utfører den et JNDI-oppslag for å få en TextProcessorBean fullmektig. Etter det påkaller den fullmakten processText () metode.

3.1. Maven avhengigheter

Vi må ta med følgende Maven-gjenstander for at EJB-klienten skal fungere som forventet:

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

Selv om det er ganske åpenbart hvorfor vi inkluderer javaee-api gjenstand, inkludering av wildfly-ejb-client-bom er ikke. Artefakten er nødvendig for å utføre eksterne EJB-påkallinger på WildFly.

Sist, men ikke minst, må vi gjøre den forrige EJB-modulen tilgjengelig for klienten, så det er derfor vi la til ejbmodule avhengighet også.

3.2. EJB klientklasse

Tatt i betraktning at EJB-klienten kaller en fullmakt til TextProcessorBean, vi vil være veldig pragmatiske og gi klientklassen navn TextApplication:

public class TextApplication {public static void main (String [] args) kaster 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", sant); returner ny InitialContext (jndiProperties); }}}

Enkelt sagt, alt det TextApplicationklasse gjør er å hente bønneproxyen og ringe den processText () metode med en prøvestreng.

Selve oppslaget utføres av den nestede klassen EJBFactory, som først lager en JNDI InitialContext for eksempel, sender deretter de nødvendige JNDI-parametrene til konstruktøren, og bruker den til slutt for å slå opp bønne-proxyen.

Legg merke til at oppslaget utføres ved å bruke WildFlys proprietære "ejb:" - navneområde. Dette optimaliserer oppslagsprosessen, da klienten definerer tilkoblingen til serveren til proxyen eksplisitt påkalles.

Det er også verdt å merke seg at det er mulig å slå opp bønneproxyen uten å bruke navneområdet "ejb" i det hele tatt. Derimot, vi vil savne alle de ekstra fordelene med late nettverkstilkoblinger, og dermed gjøre klienten mye mindre performant.

3.3. Sette opp EJB-konteksten

Klienten bør vite hvilken vert og port for å opprette en forbindelse med for å utføre bønnesøk. I denne grad klienten krever å sette opp den proprietære WildFly EJB-konteksten, som er definert med jboss-ejb-client.properties fil plassert i klassestien, vanligvis under src / main / resources mappe:

endpoint.name = client-endpoint remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED = false remote.connections = standard remote.connection.default.host = 127.0.0.1 remote.connection.default.port = 8080 ekstern .connection.default.connect.options.org.xnio.Options .SASL_POLICY_NOANONYMOUS = falsk remote.connection.default.username = mitt brukernavn remote.connection.default.password = mitt passord

Filen er ganske selvforklarende, da den inneholder alle parametere som kreves for å opprette en forbindelse til WildFly, inkludert standard antall eksterne tilkoblinger, standardverten og porten og brukerlegitimasjonen. I dette tilfellet er ikke tilkoblingen kryptert, men det kan være når SSL er aktivert.

Den siste tingen å ta i betraktning er at Hvis forbindelsen krever godkjenning, er det nødvendig å legge til en bruker i WildFly via add-user.sh/add-user.bat nytte.

4. Konklusjon

Å utføre EJB-oppslag på WildFly er grei, så lenge vi følger den skisserte prosessen.

Som vanlig er alle eksemplene i denne artikkelen tilgjengelig på GitHub her og her.