streamalism.org

1. Oversigt

I denne artikel skal vi diskutere, hvordan du kommer i gang med Enterprise JavaBean (EJB) udvikling.

Enterprise JavaBeans bruges til at udvikle skalerbare, distribuerede komponenter på serversiden og indkapsler typisk applikationens forretningslogik.

Vi bruger WildFly 10.1.0 som vores foretrukne serverløsning er du dog fri til at bruge enhver Java Enterprise-applikationsserver efter eget valg.

2. Opsætning

Lad os starte med at diskutere de Maven-afhængigheder, der kræves til EJB 3.2-udvikling, og hvordan vi konfigurerer WildFly-applikationsserveren ved hjælp af enten Maven Cargo-pluginet eller manuelt.

2.1. Maven afhængighed

For at bruge EJB 3.2, sørg for at tilføje den nyeste version til afhængigheder sektion af din pom.xml fil:

 javax javaee-api 7.0 leveret 

Du finder den seneste afhængighed i Maven Repository. Denne afhængighed sikrer, at alle Java EE 7 API'er er tilgængelige i løbet af kompileringstiden. Det stillet til rådighed omfang sikrer, at afhængigheden leveres af containeren, hvor den er blevet implementeret, når den er implementeret.

2.2. WildFly-opsætning med Maven Cargo

Lad os tale om, hvordan man bruger Maven Cargo plugin til at opsætte serveren.

Her er koden til Maven-profilen, der leverer WildFly-serveren:

 wildfly-standalone 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 Bruger: admin1234! 

Vi bruger pluginet til at downloade WildFly 10.1 zip direkte fra WildFly's hjemmeside. Som derefter konfigureres ved at sikre, at værtsnavn er 127.0.0.1 og indstille porten til 9990.

Derefter opretter vi en testbruger ved hjælp af cargo.servlet.users ejendom med bruger-id'et testbruger og adgangskoden admin1234 !.

Nu hvor konfigurationen af ​​pluginet er afsluttet, skal vi kunne kalde et Maven-mål og få serveren downloadet, installeret, startet og applikationen implementeret.

For at gøre dette skal du navigere til ejb-fjernbetjening bibliotek og kør følgende kommando:

mvn ren pakkefragt: kør

Når du kører denne kommando for første gang, downloader den WildFly 10.1 zip-filen, udpakker den og udfører installationen og starter den derefter. Det tilføjer også testbrugeren, der er diskuteret ovenfor. Eventuelle yderligere henrettelser downloader ikke zip-filen igen.

2.3. Manuel opsætning af WildFly

For at opsætte WildFly manuelt skal du downloade installations-zip-filen selv fra wildfly.org-webstedet. Følgende trin viser et højt niveau af installationsprocessen for WildFly-serveren:

Efter download og udpakning af filens indhold til det sted, hvor du vil installere serveren, skal du konfigurere følgende miljøvariabler:

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

Derefter i beholder bibliotek, kør ./standalone.sh til Linux-baserede operativsystemer eller ./standalone.bat Til Windows.

Herefter skal du tilføje en bruger. Denne bruger vil blive brugt til at oprette forbindelse til den eksterne EJB-bønne. For at finde ud af, hvordan du tilføjer en bruger, skal du se på dokumentationen til 'tilføj en bruger'.

For detaljerede installationsinstruktioner, se venligst WildFlys Kom godt i gang-dokumentation.

Projektet POM er konfigureret til at arbejde med Cargo plugin og manuel serverkonfiguration ved at indstille to profiler. Som standard er Cargo plugin valgt. For at distribuere applikationen til en allerede installeret, konfigureret og kørende Wildfly-server, skal du imidlertid udføre følgende kommando i ejb-fjernbetjening vejviser:

mvn ren installation wildfly: deploy -Pwildfly-runtime

3. Fjern vs. Lokal

En forretningsgrænseflade til en bønne kan være enten lokal eller fjern.

EN @Lokal annoteret bønne kan kun fås, hvis den er i samme applikation som bønnen, der foretager påkaldelsen, dvs. hvis de bor i den samme .øre eller .krig.

EN @Fjern annoteret bønne kan fås fra en anden applikation, dvs. en applikation, der er bosat i en anden JVM eller applikationsserver.

Der er nogle vigtige punkter, du skal huske på, når du designer en løsning, der inkluderer EJB'er:

• Det java.io.Serialiserbar, java.io. kan udvides og grænseflader defineret af javax.ejb pakke er altid ekskluderet, når en bønne er deklareret med @Lokal eller @Fjern
• Hvis en bønneklasse er fjern, skal alle implementerede grænseflader være fjerntliggende
• Hvis en bønneklasse ikke indeholder nogen kommentar, eller hvis @Lokal kommentar er angivet, så antages alle implementerede grænseflader at være lokale
• Enhver grænseflade, der er udtrykkeligt defineret for en bønne, der ikke indeholder nogen grænseflade, skal erklæres som @Lokal
• EJB 3.2-udgivelsen har tendens til at give mere granularitet til situationer, hvor lokale og eksterne grænseflader skal defineres eksplicit

4. Oprettelse af Fjern EJB

Lad os først oprette bønnens interface og kalde det Hej Verden:

@Remote offentlig grænseflade HelloWorld {String getHelloWorld (); }

Nu implementerer vi ovenstående interface og navngiver den konkrete implementering HelloWorldBean:

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

Bemærk @Stateless kommentar på klassedeklarationen. Det angiver, at denne bønne er en statsløs session bønne. Denne slags bønner har ingen tilknyttet klienttilstand, men det kan bevare sin instanstilstand og bruges normalt til at udføre uafhængige operationer.

Det @Ressource annotation injicerer sessionskonteksten i den eksterne bønne.

Det SessionContext interface giver adgang til den runtime-sessionskontekst, som containeren giver til en session bean-instans. Containeren passerer derefter SessionContext interface til en forekomst, efter at forekomsten er oprettet. Sessionskonteksten forbliver forbundet med denne forekomst i hele sin levetid.

EJB-containeren opretter normalt en pulje af statsløse bønnerobjekter og bruger disse objekter til at behandle klientanmodninger. Som et resultat af denne puljemekanisme garanteres forekomster af variable værdier ikke at blive opretholdt på tværs af opslagsmetodeopkald.

5. Fjernopsætning

I dette afsnit vil vi diskutere, hvordan du konfigurerer Maven til at opbygge og køre applikationen på serveren.

Lad os se på plugins en efter en.

5.1. EJB-pluginet

EJB-pluginet, der er angivet nedenfor, bruges til at pakke et EJB-modul. Vi har specificeret EJB-versionen som 3.2.

Følgende plugin-konfiguration bruges til at opsætte mål-JAR til bønnen:

 maven-ejb-plugin 2.4 3.2 

5.2. Implementér fjern-EJB

At implementere bønnen i en WildFly-server skal du sikre dig, at serveren er i gang.

Derefter for at udføre fjernopsætningen skal vi køre følgende Maven-kommandoer mod pom-filen i ejb-fjernbetjening projekt:

mvn ren installation 

Så skal vi løbe:

mvn wildfly: deploy

Alternativt kan vi implementere det manuelt som en admin bruger fra administrationskonsollen på applikationsserveren.

6. Klientopsætning

Efter oprettelse af fjernbønnen skal vi teste den implementerede bønne ved at oprette en klient.

Lad os først diskutere Maven-opsætningen til klientprojektet.

6.1. Opsætning af Maven på klientsiden

For at starte EJB3-klienten skal vi tilføje følgende afhængigheder:

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

Vi er afhængige af EJB's eksterne forretningsgrænseflader til denne applikation for at køre klienten. Så vi er nødt til at specificere EJB-klientens JAR-afhængighed. Vi tilføjer følgende i den overordnede pom:

 com.baeldung.ejb ejb-remote ejb 

Det er angivet som ejb.

6.2. Adgang til fjernbønnen

Vi er nødt til at oprette en fil under src / main / ressourcer og navngiv det jboss-ejb-client.properties der indeholder alle de egenskaber, der kræves for at få adgang til den implementerede bønne:

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. = testUser remote.connection.default.password = admin1234! 

7. Oprettelse af klienten

Den klasse, der får adgang til og bruger fjernbetjeningen Hej Verden bønne er oprettet i EJBClient.java der er i com.baeldung.ejb.client pakke.

7.1 Remote Bean URL

Fjernbønnen findes via en URL, der svarer til følgende format:

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

• Det $ {appName} er applikationsnavnet på implementeringen. Her har vi ikke brugt nogen EAR-fil, men en simpel JAR- eller WAR-implementering, så applikationsnavnet vil være tomt
• Det $ {moduleName} er det navn, vi har sat til vores implementering tidligere, så det er det ejb-fjernbetjening
• Det $ {distinctName} er et specifikt navn, der valgfrit kan tildeles de implementeringer, der er implementeret på serveren. Hvis en implementering ikke bruger særskilt navn så kan vi bruge en tom streng i JNDI-navnet til særskilt navn, som vi gjorde i vores eksempel
• Det $ {beanName} variabel er det enkle navn på implementeringsklassen for EJB, så i vores eksempel er det Hej Verden
• $ {viewClassName} angiver det fuldt kvalificerede interface navn på den eksterne interface

7.2 Opslagslogik

Lad os derefter se på vores enkle opslagslogik:

offentlig HelloWorld-opslag () kaster NamingException {String appName = ""; String moduleName = "fjernbetjening"; String distinctName = ""; String beanName = "HelloWorld"; String 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 at oprette forbindelse til bønne vi lige har oprettet, har vi brug for en URL, som vi kan føje ind i konteksten.

7.3 Indledende kontekst

Vi opretter / initialiserer nu sessionskonteksten:

public void 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 at oprette forbindelse til fjernbønnen har vi brug for en JNDI-kontekst. Kontekstfabrikken leveres af Maven-artefakten org.jboss: jboss-remote-navngivning og dette skaber en JNDI-kontekst, som løser den URL, der er konstrueret i kig op metode til proxyer til den eksterne applikationsserverproces.

7.4 Definer opslagsparametre

Vi definerer fabriksklassen med parameteren Kontekst.INITIAL_CONTEXT_FACTORY.

Det Kontekst.URL_PKG_PREFIXES bruges til at definere en pakke til at scanne efter yderligere navngivningskontekst.

Parameteren org.jboss.ejb.client.scoped.context = falsk fortæller konteksten at læse forbindelsesparametrene (såsom forbindelsesværten og porten) fra det medfølgende kort i stedet for fra en klassesti-konfigurationsfil. Dette er især nyttigt, hvis vi vil oprette et JAR-bundt, der skal kunne oprette forbindelse til forskellige værter.

Parameteren Kontekst.PROVIDER_URL definerer forbindelsesskemaet og skal starte med http-fjernbetjening: //.

8. Testning

For at teste implementeringen og kontrollere opsætningen kan vi køre følgende test for at sikre, at alt fungerer korrekt:

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

Når testen er bestået, kan vi nu være sikre på, at alt fungerer som forventet.

9. Konklusion

Så vi har oprettet en EJB-server og en klient, der påberåber en metode på en ekstern EJB. Projektet kan køres på enhver applikationsserver ved korrekt at tilføje afhængighederne for den pågældende server.

Hele projektet kan findes på GitHub.