Anleitung zur EJB-Einrichtung
1. Überblick
In diesem Artikel wird erläutert, wie Sie mit der Entwicklung von Enterprise JavaBean (EJB) beginnen.
Enterprise JavaBeans are used for developing scalable, distributed, server-side components und kapselt normalerweise die Geschäftslogik der Anwendung.
Wir verwendenWildFly 10.1.0 als unsere bevorzugte Serverlösung. Sie können jedoch jeden Java Enterprise-Anwendungsserver Ihrer Wahl verwenden.
2. Konfiguration
Lassen Sie uns zunächst die für die Entwicklung von EJB 3.2 erforderlichen Maven-Abhängigkeiten und die Konfiguration des WildFly-Anwendungsservers mithilfe des Maven Cargo-Plugins oder manuell erläutern.
2.1. Maven-Abhängigkeit
Um EJB 3.2, zu verwenden, stellen Sie sicher, dass Sie die neueste Version zum Abschnittdependencies Ihrerpom.xml-Datei hinzufügen:
javax
javaee-api
7.0
provided
Die neueste Abhängigkeit finden Sie inMaven Repository. Diese Abhängigkeit stellt sicher, dass alle Java EE 7-APIs während der Kompilierungszeit verfügbar sind. Der Bereich vonprovidedtellt sicher, dass die Abhängigkeit nach der Bereitstellung von dem Container bereitgestellt wird, in dem sie bereitgestellt wurde.
2.2. WildFly-Setup mit Maven Cargo
Lassen Sie uns darüber sprechen, wie Sie das Maven Cargo-Plugin zum Einrichten des Servers verwenden.
Hier ist der Code für das Maven-Profil, das den WildFly-Server bereitstellt:
wildfly-standalone
org.codehaus.cargo
cargo-maven2-plugin
${cargo-maven2-plugin.version
wildfly10x
http://download.jboss.org/
wildfly/10.1.0.Final/
wildfly-10.1.0.Final.zip
127.0.0.0
9990
testUser:admin1234!
Wir verwenden das Plugin, um dieWildFly 10.1-Zip direkt von der WildFly-Website herunterzuladen. Dies wird dann konfiguriert, indem sichergestellt wird, dasshostname127.0.0.1 ist, und der Port auf 9990 gesetzt wird.
Anschließend erstellen wir einen Testbenutzer unter Verwendung der Eigenschaftcargo.servlet.users mit der Benutzer-IDtestUser und dem Kennwortadmin1234!.
Nachdem die Konfiguration des Plugins abgeschlossen ist, sollten wir in der Lage sein, ein Maven-Ziel aufzurufen und den Server herunterzuladen, zu installieren, zu starten und die Anwendung bereitzustellen.
Navigieren Sie dazu zum Verzeichnisejb-remote und führen Sie den folgenden Befehl aus:
mvn clean package cargo:runWenn Sie diesen Befehl zum ersten Mal ausführen, wird die Zip-Datei von WildFly 10.1 heruntergeladen, extrahiert, die Installation ausgeführt und anschließend gestartet. Es wird auch der oben diskutierte Testbenutzer hinzugefügt. Bei weiteren Ausführungen wird die ZIP-Datei nicht erneut heruntergeladen.
2.3. Manuelle Einrichtung von WildFly
Um WildFly manuell einzurichten, müssen Sie die Installations-Zip-Datei selbst von derwildfly.org-Website herunterladen. Bei den folgenden Schritten handelt es sich um eine allgemeine Ansicht des WildFly-Serverkonfigurationsprozesses:
Konfigurieren Sie nach dem Herunterladen und Entpacken des Dateiinhalts an den Speicherort, an dem Sie den Server installieren möchten, die folgenden Umgebungsvariablen:
JBOSS_HOME=/Users/$USER/../wildfly.x.x.Final
JAVA_HOME=`/usr/libexec/java_home -v 1.8`Führen Sie dann im Verzeichnisbin./standalone.sh für Linux-basierte Betriebssysteme oder./standalone.bat für Windows aus.
Danach müssen Sie einen Benutzer hinzufügen. Dieser Benutzer wird verwendet, um eine Verbindung mit der Remote-EJB-Bean herzustellen. Um herauszufinden, wie Sie einen Benutzer hinzufügen können, sollten Sie sich die‘add a user' documentation ansehen.
Ausführliche Anweisungen zur Einrichtung finden Sie unterGetting Started documentationvon WildFly.
Das Projekt POM wurde so konfiguriert, dass es mit dem Cargo-Plugin und der manuellen Serverkonfiguration zusammenarbeitet, indem zwei Profile festgelegt werden. Standardmäßig ist das Cargo-Plugin ausgewählt. Um die Anwendung jedoch auf einem bereits installierten, konfigurierten und ausgeführten Wildfly-Server bereitzustellen, führen Sie den folgenden Befehl im Verzeichnisejb-remoteaus:
mvn clean install wildfly:deploy -Pwildfly-runtime3. Remote vsLocal
Eine Geschäftsschnittstelle für eine Bean kann entwederlocal oderremote. sein
Auf die mit Anmerkungen versehene Bean von@Localkann nur zugegriffen werden, wenn sie sich in derselben Anwendung befindet wie die Bean, die den Aufruf ausführt, d. H. wenn sie sich in denselben.ear oder.war befinden.
Auf eine mit@Remoteannotierte Bean kann von einer anderen Anwendung aus zugegriffen werden, d. H. Eine Anwendung, die sich auf einem anderenJVM oder Anwendungsserver befindet.
Beim Entwerfen einer Lösung mit EJBs sind einige wichtige Punkte zu beachten:
-
Diejava.io.Serializable,java.io.Externalizable und Schnittstellen, die durch dasjavax.ejb-Paket definiert sind, werden immer ausgeschlossen, wenn eine Bean mit@Local oder@Remote deklariert wird
-
Wenn eine Bean-Klasse remote ist, müssen alle implementierten Schnittstellen remote sein
-
Wenn eine Bean-Klasse keine Annotation enthält oder wenn die Annotation@Localangegeben ist, werden alle implementierten Schnittstellen als lokal angenommen
-
Jede Schnittstelle, die explizit für eine Bean definiert ist, die keine Schnittstelle enthält, muss als@Local deklariert werden
-
Die Version EJB 3.2 neigt dazu, in Situationen, in denen lokale und entfernte Schnittstellen explizit definiert werden müssen, eine genauere Granularität zu bieten
4. Erstellen desRemote EJB
Erstellen wir zunächst die Schnittstelle der Bean und nennen sieHelloWorld:
@Remote
public interface HelloWorld {
String getHelloWorld();
}Jetzt werden wir die obige Schnittstelle implementieren und die konkrete ImplementierungHelloWorldBean: benennen
@Stateless(name = "HelloWorld")
public class HelloWorldBean implements HelloWorld {
@Resource
private SessionContext context;
@Override
public String getHelloWorld() {
return "Welcome to EJB Tutorial!";
}
}Beachten Sie die Annotation@Statelessin der Klassendeklaration. Dies bedeutet, dass es sich bei dieser Bean um eine zustandslose Session-Bean handelt. This kind of bean does not have any associated client state, behält jedoch möglicherweise seinen Instanzstatus bei und wird normalerweise für unabhängige Operationen verwendet.
Die Annotation@Resourcefügt den Sitzungskontext in die Remote-Bean ein.
The SessionContext interface provides access to the runtime session context that the container provides for a session bean instance. Der Container übergibt dann dieSessionContext-Schnittstelle an eine Instanz, nachdem die Instanz erstellt wurde. Der Sitzungskontext bleibt dieser Instanz für die gesamte Lebensdauer zugeordnet.
Der EJB-Container erstellt normalerweise einen Pool von Objekten der zustandslosen Bean und verwendet diese Objekte zur Verarbeitung von Clientanforderungen. Aufgrund dieses Pooling-Mechanismus kann nicht garantiert werden, dass Instanzvariablenwerte über Lookup-Methodenaufrufe hinweg beibehalten werden.
5. Remote-Setup
In diesem Abschnitt wird erläutert, wie Sie Maven so einrichten, dass die Anwendung auf dem Server erstellt und ausgeführt wird.
Schauen wir uns die Plugins einzeln an.
5.1. Das EJB Plugin
Das unten angegebene EJB-Plugin wird zum Packen eines EJB-Moduls verwendet. Wir haben die EJB-Version als 3.2 angegeben.
Die folgende Plugin-Konfiguration wird verwendet, um die Ziel-JAR für die Bean einzurichten:
maven-ejb-plugin
2.4
3.2
5.2. Stellen Sie das Remote-EJB bereit
Um die Bean auf einem WildFly-Server bereitzustellen, müssen Sie sicherstellen, dass der Server betriebsbereit ist.
Um das Remote-Setup auszuführen, müssen Sie die folgenden Maven-Befehle für die POM-Datei im Projektejb-remoteausführen:
mvn clean installDann sollten wir laufen:
mvn wildfly:deployAlternativ können wir es manuell alsadmin-Benutzer über die Administrationskonsole des Anwendungsservers. bereitstellen
6. Client-Setup
Nach dem Erstellen der Remote-Bean sollten wir die implementierte Bean testen, indem wir einen Client erstellen.
Lassen Sie uns zunächst das Maven-Setup für das Client-Projekt diskutieren.
6.1. Client-seitiges Maven-Setup
Um den EJB3-Client zu starten, müssen die folgenden Abhängigkeiten hinzugefügt werden:
org.wildfly
wildfly-ejb-client-bom
pom
import
Wir sind auf die EJB-Remote-Business-Schnittstellen dieser Anwendung angewiesen, um den Client auszuführen. Daher müssen wir die JAR-Abhängigkeit des EJB-Clients angeben. Wir fügen im übergeordneten POM Folgendes hinzu:
com.example.ejb
ejb-remote
ejb
<type> wird alsejb angegeben.
6.2. Zugriff auf die Remote Bean
Wir müssen eine Datei untersrc/main/resources erstellen und siejboss-ejb-client.properties nennen, die alle Eigenschaften enthält, die für den Zugriff auf die bereitgestellte Bean erforderlich sind:
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options
.SASL_POLICY_NOANONYMOUS = false
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.connection.default.username=testUser
remote.connection.default.password=admin1234!7. Client erstellen
Die Klasse, die auf die Remote-BeanHelloWorld zugreift und diese verwendet, wurde inEJBClient.java erstellt, die sich im Paketcom.example.ejb.client befindet.
7.1 Remote Bean URL
Die Remote-Bean befindet sich über eine URL, die dem folgenden Format entspricht:
ejb:${appName}/${moduleName}/${distinctName}/${beanName}!${viewClassName}-
${appName} ist der Anwendungsname der Bereitstellung. Hier haben wir keine EAR-Datei verwendet, sondern eine einfache JAR- oder WAR-Bereitstellung, sodass der Anwendungsname leer ist
-
The[.crayon-pre .crayon-code] ${moduleName}## ist der Name, den wir zuvor für unsere Bereitstellung festgelegt haben, alsoejb-remote
-
${distinctName} ist ein bestimmter Name, der optional den Bereitstellungen zugewiesen werden kann, die auf dem Server bereitgestellt werden. Wenn in einer Bereitstellungdistinct-name nicht verwendet wird, können wir wie in unserem Beispiel eine leere Zeichenfolge im JNDI-Namen fürdistinct-name verwenden
-
Die Variable[.crayon-pre .crayon-code]${beanName}## ist der einfache Name der Implementierungsklasse des EJB, in unserem Beispiel alsoHelloWorld
-
[.crayon-pre .crayon-code]${viewClassName}## bezeichnet den vollständig qualifizierten Schnittstellennamen der Remote-Schnittstelle
7.2 Look-up Logic
Schauen wir uns als nächstes unsere einfache Nachschlagelogik an:
public HelloWorld lookup() throws 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);
}Um eine Verbindung zu den gerade erstelltenbeanherzustellen, benötigen wir eine URL, die wir in den Kontext einspeisen können.
7.3 The Initial Context
Wir erstellen / initialisieren jetzt den Sitzungskontext:
public void createInitialContext() throws 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);
}Für die Verbindung zur Remote-Bean benötigen wir einen JNDI-Kontext. Die Kontextfactory wird vom Maven-Artefaktorg.jboss:jboss-remote-naming bereitgestellt. Dadurch wird ein JNDI-Kontext erstellt, der die in der Methodelookuperstellte URL in Proxys für den Remote-Anwendungsserverprozess auflöst.
7.4 Define Lookup Parameters
Wir definieren die Factory-Klasse mit dem ParameterContext.INITIAL_CONTEXT_FACTORY.
MitContext.URL_PKG_PREFIXES wird ein Paket definiert, das nach zusätzlichem Namenskontext durchsucht werden soll.
Der Parameterorg.jboss.ejb.client.scoped.context = false weist den Kontext an, die Verbindungsparameter (z. B. den Verbindungshost und den Port) aus der bereitgestellten Zuordnung anstatt aus einer Klassenpfad-Konfigurationsdatei zu lesen. Dies ist besonders hilfreich, wenn wir ein JAR-Bundle erstellen möchten, das eine Verbindung zu verschiedenen Hosts herstellen kann.
Der ParameterContext.PROVIDER_URL definiert das Verbindungsschema und sollte mithttp-remoting:// beginnen.
8. Testen
Um die Bereitstellung zu testen und das Setup zu überprüfen, können wir den folgenden Test ausführen, um sicherzustellen, dass alles ordnungsgemäß funktioniert:
@Test
public void testEJBClient() {
EJBClient ejbClient = new EJBClient();
HelloWorldBean bean = new HelloWorldBean();
assertEquals(bean.getHelloWorld(), ejbClient.getEJBRemoteMessage());
}Mit dem Bestehen des Tests können wir jetzt sicher sein, dass alles wie erwartet funktioniert.
9. Fazit
Deshalb haben wir einen EJB-Server und einen Client erstellt, der eine Methode auf einem entfernten EJB aufruft. Das Projekt kann auf jedem Anwendungsserver ausgeführt werden, indem die Abhängigkeiten für diesen Server ordnungsgemäß hinzugefügt werden.
Das gesamte Projekt kann inover on GitHub gefunden werden.