streamalism.org

1. Oversikt

I denne artikkelen skal vi diskutere hvordan du kommer i gang med Enterprise JavaBean (EJB) utvikling.

Enterprise JavaBeans brukes til å utvikle skalerbare, distribuerte komponenter på serversiden og innkapsler vanligvis forretningslogikken til applikasjonen.

Vi bruker WildFly 10.1.0 som vår foretrukne serverløsning, er du imidlertid fri til å bruke hvilken som helst Java Enterprise-applikasjonsserver du velger.

2. Oppsett

La oss starte med å diskutere de Maven-avhengighetene som kreves for EJB 3.2-utvikling, og hvordan du konfigurerer WildFly-applikasjonsserveren ved hjelp av enten Maven Cargo-plugin eller manuelt.

2.1. Maven avhengighet

For å bruke EJB 3.2, sørg for at du legger til den nyeste versjonen i avhengigheter delen av din pom.xml fil:

 javax javaee-api 7.0 gitt 

Du finner den siste avhengigheten i Maven Repository. Denne avhengigheten sørger for at alle Java EE 7 APIer er tilgjengelige i løpet av kompileringstiden. De sørget for omfanget sørger for at avhengigheten blir levert av containeren der den har blitt distribuert når den er distribuert.

2.2. WildFly-oppsett med Maven Cargo

La oss snakke om hvordan du bruker Maven Cargo-plugin for å konfigurere serveren.

Her er koden for Maven-profilen som gir WildFly-serveren:

 wildfly-frittstående org.codehaus.cargo cargo-maven2-plugin $ {cargo-maven2-plugin.version wildfly10x //download.jboss.org/ wildfly / 10.1.0.Final / wildfly-10.1.0.Final.zip 127.0. 0,0 9990 test Bruker: admin1234! 

Vi bruker plugin for å laste ned WildFly 10.1 zip direkte fra WildFlys nettsted. Som deretter konfigureres, ved å sørge for at vertsnavn er 127.0.0.1 og sette porten til 9990.

Deretter oppretter vi en testbruker ved å bruke last.servlet.brukere eiendom, med bruker-ID testbruker og passordet admin1234 !.

Nå som konfigurasjonen av pluginet er fullført, bør vi kunne ringe et Maven-mål og få serveren lastet ned, installert, lansert og applikasjonen distribuert.

For å gjøre dette, naviger til ejb-fjernkontroll katalog og kjør følgende kommando:

mvn ren pakkelast: kjør

Når du kjører denne kommandoen for første gang, vil den laste ned WildFly 10.1 zip-filen, pakke den ut og utføre installasjonen og deretter starte den. Det vil også legge til testbrukeren som er diskutert ovenfor. Eventuelle ytterligere henrettelser vil ikke laste ned zip-filen igjen.

2.3. Manuell oppsett av WildFly

For å konfigurere WildFly manuelt, må du laste ned zip-filen for installasjonen selv fra wildfly.org-nettstedet. Følgende trinn er en oversikt over WildFly-serveroppsettprosessen på høyt nivå:

Når du har lastet ned og pakket ut innholdet på filen til stedet der du vil installere serveren, konfigurerer du følgende miljøvariabler:

JBOSS_HOME = / Brukere / $ BRUKER /../ wildfly.x.x.Final JAVA_HOME = `/ usr / libexec / java_home -v 1.8`

Så i søppel katalog, kjør ./standalone.sh for Linux-baserte operativsystemer eller ./standalone.bat for Windows.

Etter dette må du legge til en bruker. Denne brukeren vil bli brukt til å koble til den eksterne EJB-bønnen. For å finne ut hvordan du legger til en bruker, bør du ta en titt på dokumentasjonen ‘legg til en bruker’.

For detaljerte installasjonsinstruksjoner kan du gå til WildFlys Kom i gang-dokumentasjon.

Prosjektet POM er konfigurert til å fungere med Cargo plugin og manuell serverkonfigurasjon ved å angi to profiler. Som standard er lastetillegget valgt. For å distribuere applikasjonen til en allerede installert, konfigurert og kjørende Wildfly-server, utfører du imidlertid følgende kommando i ejb-fjernkontroll katalog:

mvn clean install wildfly: deploy -Pwildfly-runtime

3. Fjernkontroll vs. Lokalt

Et forretningsgrensesnitt for en bønne kan være enten lokal eller fjernkontroll.

EN @Lokal merket bønne kan bare nås hvis den er i samme applikasjon som bønnen som gjør påkallelsen, dvs. hvis de bor i samme .øre eller .krig.

EN @Remote merket bønne kan nås fra en annen applikasjon, dvs. en applikasjon som er bosatt i en annen JVM eller applikasjonsserver.

Det er noen viktige punkter du må huske på når du designer en løsning som inkluderer EJB:

• De java.io Serialiserbar, java.io. kan utvides og grensesnitt definert av javax.ejb pakken er alltid ekskludert når en bønne er deklarert med @Lokal eller @Remote
• Hvis en bønneklasse er ekstern, skal alle implementerte grensesnitt være eksterne
• Hvis en bønneklasse ikke inneholder noen kommentar, eller hvis @Lokal kommentar er spesifisert, så antas alle implementerte grensesnitt å være lokale
• Ethvert grensesnitt som er eksplisitt definert for en bønne som ikke inneholder noe grensesnitt, må erklæres som @Lokal
• EJB 3.2-utgivelsen har en tendens til å gi mer detaljering for situasjoner der lokale og eksterne grensesnitt må defineres eksplisitt

4. Opprette Fjernkontroll EJB

La oss først lage bønnens grensesnitt og kalle det Hei Verden:

@Remote offentlig grensesnitt HelloWorld {String getHelloWorld (); }

Nå skal vi implementere grensesnittet ovenfor og navngi den konkrete implementeringen HelloWorldBean:

@Stateless (name = "HelloWorld") offentlig klasse HelloWorldBean implementerer HelloWorld {@Resource private SessionContext context; @ Override public String getHelloWorld () {return "Velkommen til EJB Tutorial!"; }}

Legg merke til @Stateless kommentar på klassedeklarasjonen. Det betegner at denne bønnen er en statsløs øktbønne. Denne typen bønner har ingen tilknyttet klienttilstand, men det kan bevare sin forekomsttilstand og brukes vanligvis til å utføre uavhengige operasjoner.

De @Ressurs kommentar injiserer øktkonteksten i den eksterne bønnen.

De SessionContext grensesnitt gir tilgang til den kjøretidsøktekonteksten som beholderen gir for en øktbønnsforekomst. Containeren passerer deretter SessionContext grensesnitt til en forekomst etter at forekomsten er opprettet. Øktekonteksten forblir tilknyttet den forekomsten i hele sin levetid.

EJB-containeren oppretter normalt et basseng med statsløse bønneobjekter og bruker disse objektene til å behandle klientforespørsler. Som et resultat av denne sammenkoblingsmekanismen garanteres ikke forekomstvariabler på tvers av oppslagsmetodeanrop.

5. Fjernoppsett

I denne delen vil vi diskutere hvordan du konfigurerer Maven for å bygge og kjøre applikasjonen på serveren.

La oss se på pluginene en etter en.

5.1. EJB-plugin

EJB-pluginet som er gitt nedenfor brukes til å pakke en EJB-modul. Vi har spesifisert EJB-versjonen som 3.2.

Følgende plugin-konfigurasjon brukes til å sette opp JAR-målet for bønnen:

 maven-ejb-plugin 2.4 3.2 

5.2. Distribuere ekstern EJB

Å distribuere bønnen i en WildFly-server, sørg for at serveren er oppe og går.

For å utføre fjernoppsettet må vi kjøre følgende Maven-kommandoer mot pom-filen i ejb-fjernkontroll prosjekt:

mvn ren installasjon 

Så bør vi løpe:

mvn wildfly: distribuere

Alternativt kan vi distribuere den manuelt som en admin bruker fra administrasjonskonsollen til applikasjonsserveren.

6. Klientoppsett

Etter å ha opprettet den eksterne bønnen, bør vi teste den distribuerte bønnen ved å opprette en klient.

La oss først diskutere Maven-oppsettet for klientprosjektet.

6.1. Client Maven Setup

For å starte EJB3-klienten må vi legge til følgende avhengigheter:

 org.wildfly wildfly-ejb-client-bom pom import 

Vi er avhengige av EJBs eksterne forretningsgrensesnitt for dette programmet for å kjøre klienten. Så vi må spesifisere EJB-klientens JAR-avhengighet. Vi legger til følgende i foreldrepompen:

 com.baeldung.ejb ejb-ekstern ejb 

De er spesifisert som ejb.

6.2. Få tilgang til Remote Bean

Vi må lage en fil under src / main / resources og heter det jboss-ejb-client.properties som inneholder alle egenskapene som kreves for å få tilgang til den distribuerte bønnen:

remote.connections = standard remote.connection.default.host = 127.0.0.1 remote.connection.default.port = 8080 remote.connection.default.connect.options.org.xnio.Options .SASL_POLICY_NOANONYMOUS = falsk remote.connection.default. connect.options.org.xnio.Options .SASL_POLICY_NOPLAINTEXT = falsk remote.connection.default.connect.options.org.xnio.Options .SASL_DISALLOWED_MECHANISMS = $ {host.auth: JBOSS-LOCAL-USER} remote.connection.def. = testbrukeren remote.connection.default.password = admin1234! 

7. Opprette klienten

Klassen som får tilgang til og bruker fjernkontrollen Hei Verden bønne er opprettet i EJBClient.java som er i com.baeldung.ejb.client pakke.

7.1 Remote Bean URL

Fjernbønnen ligger via en URL som samsvarer med følgende format:

ejb: $ {appName} / $ {moduleName} / $ {distinctName} / $ {beanName}! $ {viewClassName}

• De $ {appName} er applikasjonsnavnet for distribusjonen. Her har vi ikke brukt noen EAR-fil, men en enkel JAR- eller WAR-distribusjon, så applikasjonsnavnet vil være tomt
• De $ {moduleName} er navnet vi satte for distribusjonen vår tidligere, så det er det ejb-fjernkontroll
• De $ {distinctName} er et spesifikt navn som valgfritt kan tildeles distribusjonene som distribueres på serveren. Hvis en distribusjon ikke bruker distinkt-navn så kan vi bruke en tom streng i JNDI-navnet, for distinkt-navn, som vi gjorde i vårt eksempel
• De $ {beanName} variabel er det enkle navnet på implementeringsklassen til EJB, så i vårt eksempel er det Hei Verden
• $ {viewClassName} angir det fullt kvalifiserte grensesnittnavnet til det eksterne grensesnittet

7.2 Oppslagslogikk

La oss så se på vår enkle oppslagslogikk:

offentlig HelloWorld-oppslag () kaster NamingException {String appName = ""; String moduleName = "ekstern"; String distinctName = ""; String beanName = "HelloWorld"; Streng viewClassName = HelloWorld.class.getName (); String toLookup = String.format ("ejb:% s /% s /% s /% s!% S", appName, moduleName, distinctName, beanName, viewClassName); returner (HelloWorld) context.lookup (toLookup); }

For å koble til bønne vi nettopp opprettet, trenger vi en URL som vi kan mate inn i konteksten.

7.3 Innledende kontekst

Vi oppretter / initialiserer øktkonteksten:

offentlig tomrom createInitialContext () kaster NamingException {Properties prop = new Properties (); prop.put (Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); prop.put (Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFacto [ERROR] prop.put (Context.PROVIDER_URL," http-remoting: //127.0.0.1: 8080 "); prop.put ( Context.SECURITY_PRINCIPAL, "testUser"); prop.put (Context.SECURITY_CREDENTIALS, "admin1234!"); Prop.put ("jboss.naming.client.ejb.context", false); context = new InitialContext (prop); }

For å koble til den eksterne bønnen trenger vi en JNDI-kontekst. Kontekstfabrikken er levert av Maven-gjenstanden org.jboss: jboss-remote-navngivning og dette skaper en JNDI-kontekst, som løser URL-en konstruert i se opp metoden, i fullmakter til den eksterne applikasjonsserverprosessen.

7.4 Definer oppslagsparametere

Vi definerer fabrikklassen med parameteren Kontekst.INITIAL_CONTEXT_FACTORY.

De Kontekst.URL_PKG_PREFIXES brukes til å definere en pakke for å skanne etter ytterligere navngivningskontekst.

Parameteren org.jboss.ejb.client.scoped.context = false forteller konteksten om å lese tilkoblingsparametrene (for eksempel tilkoblingsverten og porten) fra det medfølgende kartet i stedet for fra en klassesti-konfigurasjonsfil. Dette er spesielt nyttig hvis vi ønsker å lage en JAR-pakke som skal kunne kobles til forskjellige verter.

Parameteren Kontekst.PROVIDER_URL definerer tilkoblingsskjemaet og skal begynne med http-fjernkontroll: //.

8. Testing

For å teste distribusjonen og sjekke oppsettet, kan vi kjøre følgende test for å sikre at alt fungerer som det skal:

@Test offentlig ugyldig testEJBClient () {EJBClient ejbClient = ny EJBClient (); HelloWorldBean bønne = ny HelloWorldBean (); assertEquals (bean.getHelloWorld (), ejbClient.getEJBRemoteMessage ()); }

Når testen går, kan vi nå være sikre på at alt fungerer som forventet.

9. Konklusjon

Så vi har opprettet en EJB-server og en klient som påkaller en metode på en ekstern EJB. Prosjektet kan kjøres på en hvilken som helst applikasjonsserver ved å legge til avhengighetene for den serveren riktig.

Hele prosjektet finner du på GitHub.