streamalism.org

1. Overzicht

In dit artikel gaan we bespreken hoe u aan de slag kunt gaan met de ontwikkeling van Enterprise JavaBean (EJB).

Enterprise JavaBeans worden gebruikt voor het ontwikkelen van schaalbare, gedistribueerde server-side componenten en bevatten typisch de bedrijfslogica van de applicatie.

We zullen gebruiken WildFly 10.1.0 Als onze voorkeursserveroplossing bent u echter vrij om elke Java Enterprise-applicatieserver van uw keuze te gebruiken.

2. Installatie

Laten we beginnen met het bespreken van de Maven-afhankelijkheden die vereist zijn voor de ontwikkeling van EJB 3.2 en hoe de WildFly-applicatieserver moet worden geconfigureerd met behulp van de Maven Cargo-plug-in of handmatig.

2.1. Afhankelijkheid van Maven

Om EJB 3.2 te gebruiken, zorg ervoor dat u de nieuwste versie toevoegt aan het afhankelijkheden sectie van uw pom.xml het dossier:

 javax javaee-api 7.0 voorzien 

U vindt de laatste afhankelijkheid in de Maven Repository. Deze afhankelijkheid zorgt ervoor dat alle Java EE 7 API's beschikbaar zijn tijdens het compileren. De voorzien scope zorgt ervoor dat eenmaal geïmplementeerd, de afhankelijkheid wordt geleverd door de container waarin deze is geïmplementeerd.

2.2. WildFly-installatie met Maven Cargo

Laten we het hebben over het gebruik van de Maven Cargo-plug-in om de server in te stellen.

Hier is de code voor het Maven-profiel dat de WildFly-server voorziet:

 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 testUser: admin1234! 

We gebruiken de plug-in om het WildFly 10.1 zip rechtstreeks vanaf de website van WildFly. Die wordt vervolgens geconfigureerd door ervoor te zorgen dat de hostnaam is 127.0.0.1 en het instellen van de poort op 9990.

Vervolgens maken we een testgebruiker aan met behulp van de cargo.servlet.users property, met het gebruikers-ID testUser en het wachtwoord admin1234 !.

Nu de configuratie van de plug-in is voltooid, zouden we een Maven-doel moeten kunnen bellen en de server kunnen downloaden, installeren, starten en de applicatie kunnen implementeren.

Om dit te doen, navigeert u naar het ejb-afstandsbediening directory en voer de volgende opdracht uit:

mvn schone pakketlading: run

Wanneer u deze opdracht voor de eerste keer uitvoert, wordt het WildFly 10.1 zip-bestand gedownload, uitgepakt en de installatie uitgevoerd en vervolgens gestart. Het zal ook de hierboven besproken testgebruiker toevoegen. Bij verdere uitvoeringen wordt het zip-bestand niet opnieuw gedownload.

2.3. Handmatige installatie van WildFly

Om WildFly handmatig in te stellen, moet u het zip-bestand voor de installatie zelf downloaden van de website wildfly.org. De volgende stappen zijn een overzicht op hoog niveau van het installatieproces van de WildFly-server:

Na het downloaden en uitpakken van de inhoud van het bestand naar de locatie waar u de server wilt installeren, configureert u de volgende omgevingsvariabelen:

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

Vervolgens in de bak directory, voer het ./standalone.sh voor op Linux gebaseerde besturingssystemen of ./standalone.bat voor ramen.

Hierna moet u een gebruiker toevoegen. Deze gebruiker wordt gebruikt om verbinding te maken met de externe EJB-bean. Om erachter te komen hoe u een gebruiker toevoegt, moet u de documentatie ‘een gebruiker toevoegen 'raadplegen.

Ga voor gedetailleerde installatie-instructies naar de Aan de slag-documentatie van WildFly.

De project-POM is geconfigureerd om te werken met de Cargo-plug-in en handmatige serverconfiguratie door twee profielen in te stellen. Standaard is de Cargo-plug-in geselecteerd. Om de applicatie echter te implementeren op een reeds geïnstalleerde, geconfigureerde en actieve Wildfly-server, voert u de volgende opdracht uit in het ejb-afstandsbediening directory:

mvn clean install wildfly: deploy -Pwildfly-runtime

3. Afgelegen vs Lokaal

Een zakelijke interface voor een boon kan het beide zijn lokaal of afgelegen.

EEN @Lokaal geannoteerde bean is alleen toegankelijk als deze zich in dezelfde applicatie bevindt als de bean die de aanroep maakt, d.w.z. als ze zich in dezelfde .oor of .oorlog.

EEN @Remote geannoteerde bean is toegankelijk vanuit een andere applicatie, d.w.z. een applicatie die zich in een andere JVM of applicatieserver.

Er zijn enkele belangrijke punten waarmee u rekening moet houden bij het ontwerpen van een oplossing die EJB's omvat:

• De java.io.Serializable, java.io.Externalizable en interfaces gedefinieerd door de javax.ejb pakket is altijd uitgesloten wanneer een boon wordt gedeclareerd met @Lokaal of @Remote
• Als een bean-klasse op afstand is, moeten alle geïmplementeerde interfaces op afstand zijn
• Als een bean-klasse geen annotatie bevat of als de @Lokaal annotatie is gespecificeerd, dan wordt aangenomen dat alle geïmplementeerde interfaces lokaal zijn
• Elke interface die expliciet is gedefinieerd voor een bean die geen interface bevat, moet worden gedeclareerd als @Lokaal
• De EJB 3.2-release heeft de neiging om meer granulariteit te bieden voor situaties waarin lokale en externe interfaces expliciet moeten worden gedefinieerd

4. Het creëren van het Afgelegen EJB

Laten we eerst de interface van de boon maken en deze noemen Hallo Wereld:

@Remote openbare interface HelloWorld {String getHelloWorld (); }

Nu zullen we de bovenstaande interface implementeren en de concrete implementatie een naam geven HelloWorldBean:

@Stateless (name = "HelloWorld") openbare klasse HelloWorldBean implementeert HelloWorld {@Resource private SessionContext-context; @Override public String getHelloWorld () {return "Welkom bij EJB Tutorial!"; }}

Merk op @Stateless annotatie op de klasseverklaring. Het geeft aan dat deze boon een staatloze sessieboon is. Dit soort boon heeft geen bijbehorende clientstatus, maar het kan zijn instantiestatus behouden en wordt normaal gesproken gebruikt om onafhankelijke bewerkingen uit te voeren.

De @Resource annotatie injecteert de sessiecontext in de remote bean.

De SessionContext interface biedt toegang tot de runtime-sessiecontext die de container biedt voor een sessiebean-instantie. De container passeert vervolgens het SessionContext interface naar een instantie nadat de instantie is gemaakt. De sessiecontext blijft gedurende de hele levensduur verbonden met die instantie.

De EJB-container maakt normaal gesproken een pool van stateless bean-objecten en gebruikt deze objecten om clientverzoeken te verwerken. Als gevolg van dit poolingmechanisme is het niet gegarandeerd dat de waarden van instantievariabelen behouden blijven bij aanroepen van opzoekmethoden.

5. Installatie op afstand

In dit gedeelte bespreken we hoe u Maven instelt om de applicatie op de server te bouwen en uit te voeren.

Laten we de plug-ins een voor een bekijken.

5.1. De EJB-plug-in

De EJB-plug-in die hieronder wordt gegeven, wordt gebruikt om een ​​EJB-module te verpakken. We hebben de EJB-versie gespecificeerd als 3.2.

De volgende plugin-configuratie wordt gebruikt om de doel-JAR voor de bean in te stellen:

 maven-ejb-plugin 2.4 3.2 

5.2. Implementeer de externe EJB

Om de bean in een WildFly-server te implementeren, moet u ervoor zorgen dat de server actief is.

Om de installatie op afstand uit te voeren, moeten we de volgende Maven-opdrachten uitvoeren tegen het pom-bestand in het ejb-afstandsbediening project:

mvn schone installatie 

Dan moeten we rennen:

mvn wildfly: deploy

Als alternatief kunnen we het handmatig inzetten als een beheerder gebruiker vanaf de beheerconsole van de applicatieserver.

6. Clientconfiguratie

Nadat we de remote bean hebben gemaakt, moeten we de geïmplementeerde bean testen door een client te maken.

Laten we eerst de Maven-setup voor het klantproject bespreken.

6.1. Maven-installatie aan de clientzijde

Om de EJB3-client te starten, moeten we de volgende afhankelijkheden toevoegen:

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

We zijn afhankelijk van de externe zakelijke interfaces van EJB van deze applicatie om de client uit te voeren. We moeten dus de JAR-afhankelijkheid van de EJB-client specificeren. We voegen het volgende toe aan de bovenliggende pom:

 com.baeldung.ejb ejb-remote ejb 

De is gespecificeerd als ejb.

6.2. Toegang tot de Remote Bean

We moeten een bestand maken onder src / main / resources en noem maar op jboss-ejb-client.properties dat alle eigenschappen bevat die nodig zijn om toegang te krijgen tot de geïmplementeerde bean:

remote.connections = standaard remote.connection.default.host = 127.0.0.1 remote.connection.default.port = 8080 remote.connection.default.connect.options.org.xnio.Options .SASL_POLICY_NOANONYMOUS = vals remote.connection.default. connect.options.org.xnio.Options .SASL_POLICY_NOPLAINTEXT = false remote.connection.default.connect.options.org.xnio.Options .SASL_DISALLOWED_MECHANISMS = $ {host.auth: JBOSS-LOCAL-USER} remote.usconnection.default. = testUser remote.connection.default.password = admin1234! 

7. Creëren van de klant

De klas die de afstandsbediening zal openen en gebruiken Hallo Wereld bean is gemaakt in EJBClient.java die in de com.baeldung.ejb.client pakket.

7.1 URL van Remote Bean

De remote bean wordt gelokaliseerd via een URL die voldoet aan het volgende formaat:

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

• De $ {appName} is de toepassingsnaam van de implementatie. Hier hebben we geen enkel EAR-bestand gebruikt, maar een eenvoudige JAR- of WAR-implementatie, dus de naam van de applicatie zal leeg zijn
• De $ {moduleName} is de naam die we eerder voor onze implementatie hebben ingesteld, dus dat is het ook ejb-afstandsbediening
• De $ {distinctName} is een specifieke naam die optioneel kan worden toegewezen aan de implementaties die op de server worden geïmplementeerd. Als een implementatie geen gebruik maakt van onderscheidende naam dan kunnen we een lege String gebruiken in de JNDI-naam, voor de onderscheidende naam, zoals we deden in ons voorbeeld
• De $ {beanName} variabele is de eenvoudige naam van de implementatieklasse van de EJB, dus in ons voorbeeld is dat zo Hallo Wereld
• $ {viewClassName} geeft de volledig gekwalificeerde interfacenaam van de externe interface aan

7.2 Opzoeklogica

Laten we vervolgens eens kijken naar onze eenvoudige opzoeklogica:

openbare HelloWorld lookup () gooit NamingException {String appName = ""; String moduleName = "remote"; 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); return (HelloWorld) context.lookup (toLookup); }

Om verbinding te maken met het Boon die we zojuist hebben gemaakt, hebben we een URL nodig die we in de context kunnen invoeren.

7.3 Het Initiële context

We gaan nu de sessiecontext maken / initialiseren:

public void createInitialContext () gooit 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 = nieuwe InitialContext (prop); }

Om verbinding te maken met de remote bean hebben we een JNDI-context nodig. De contextfabriek wordt geleverd door het Maven-artefact org.jboss: jboss-remote-naamgeving en dit creëert een JNDI-context, die de URL die in het opzoeken methode, in proxy's naar het externe toepassingsserverproces.

7.4 Definieer opzoekparameters

We definiëren de fabrieksklasse met de parameter Context.INITIAL_CONTEXT_FACTORY.

De Context.URL_PKG_PREFIXES wordt gebruikt om een ​​pakket te definiëren dat moet worden gescand op aanvullende naamgevingscontext.

De parameter org.jboss.ejb.client.scoped.context = false vertelt de context om de verbindingsparameters (zoals de verbindingshost en poort) te lezen vanaf de verstrekte kaart in plaats van uit een klassenpadconfiguratiebestand. Dit is vooral handig als we een JAR-bundel willen maken die verbinding moet kunnen maken met verschillende hosts.

De parameter Context.PROVIDER_URL definieert het verbindingsschema en moet beginnen met http-remoting: //.

8. Testen

Om de implementatie te testen en de installatie te controleren, kunnen we de volgende test uitvoeren om te controleren of alles naar behoren werkt:

@Test openbare ongeldige testEJBClient () {EJBClient ejbClient = nieuwe EJBClient (); HelloWorldBean bean = nieuwe HelloWorldBean (); assertEquals (bean.getHelloWorld (), ejbClient.getEJBRemoteMessage ()); }

Nu de test is geslaagd, kunnen we er nu zeker van zijn dat alles werkt zoals verwacht.

9. Conclusie

We hebben dus een EJB-server en een client gemaakt die een methode op een externe EJB aanroept. Het project kan op elke applicatieserver worden uitgevoerd door de afhankelijkheden voor die server correct toe te voegen.

Het hele project is te vinden op GitHub.