EJB Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 21: Line 21:
===<tt>java:app</tt>===
===<tt>java:app</tt>===


EJB JNDI names are registered in this scope. For more details, see [[EJB_Concepts#EJB_and_JNDI|EJB and JNDI]].
The "java:module" namespace is used to look up local EJBs within the same module. JNDI addresses using the java:module namespace are of the following form:
 
<pre>
java:module/enterprise bean name/[interface name]
</pre>


===<tt>java:module</tt>===
===<tt>java:module</tt>===

Revision as of 17:03, 24 March 2017

Internal

EJB and JNDI

Session beans are bound to JNDI according to the following portable naming scheme:

ejb:[/<application-name>]/<module-name>/<distinct-name>/<bean-name>[!<view-class-name>]?stateful

Namespaces

Upon deployment, the JNDI names will be registered in the following contexts: java:global, java:app and java:module, which are accessible only to the current JVM, and also in java:jboss/exported, which is accessible remotely.

java:global

The "java:global" JNDI namespace is the portable way of finding remote EJBs using JNDI lookups.

java:app

The "java:module" namespace is used to look up local EJBs within the same module. JNDI addresses using the java:module namespace are of the following form:

java:module/enterprise bean name/[interface name]

java:module

EJB JNDI names are registered in this scope. For more details, see EJB and JNDI.

java:jboss/exported

Only components that are registered within the java:jboss/exported/ namespace are remote accessible via the naming service. EJB JNDI names are registered in this scope to be made available remotely.

JNDI Path Components

application-name

application-name is the name of the EAR application the session bean is deployed as part of. It is an optional component. If the session bean is not deployed as part of an EAR, that part is left blank, and the JNDI name starts with ejb:/<module-name>.... If the session bean deployed as part of an EAR, the part is by default the name of the EAR file, without the .ear suffix. The name can be overridden in the application.xml deployment descriptor by specifying the <application-name> element.

module-name

module-name is the name of the JAR (or WAR) file the session bean is deployed in. It is a mandatory component. By default, is the file name of the JAR without the ".jar" suffix. The module name can be override in ejb-jar.xml by specifying the <module-name> element.

distinct-name

Each deployment may specify an optional distinct name. It is an optional component. If the deployment does not have a distinct name, the corresponding JNDI path element should be left blank.

The JNDI bindings for session bean named 'SimpleStatelessBean' in deployment unit 'deployment "stateless-ejb-example.jar"' are as follows:

bean-name

The simple name of the class implementing the session bean. It is a mandatory component.

view-class-name

The fully qualified class name of the remote interface. It is an optional component.

?stateful

This suffix is required when the JNDI name refers to a stateful session bean.

JNDI Name Examples

EJB deployed in JAR

The following bean has been deployed as part of stateless-ejb-example.jar, it is implemented by io.novaordis.playground.jee.ejb.stateless.SimpleStatelessBean and exposes the io.novaordis.playground.jee.ejb.stateless.SimpleStateless remote interface.

java:global/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:app/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:module/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:jboss/exported/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:global/stateless-ejb-example/SimpleStatelessBean
java:app/stateless-ejb-example/SimpleStatelessBean
java:module/SimpleStatelessBean

The last three names are short forms, and they are registered if the EJB component only exposed one interface.

EJB deployed in EAR

The following bean has been deployed as part of a stateless-ejb-example.jar, which was embedded in stateless-ejb-and-servlet.ear.

java:global/stateless-ejb-and-servlet/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:app/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:module/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:jboss/exported/stateless-ejb-and-servlet/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
java:global/stateless-ejb-and-servlet/stateless-ejb-example/SimpleStatelessBean
java:app/stateless-ejb-example/SimpleStatelessBean
java:module/SimpleStatelessBean

The last three names are short forms, and they are registered if the EJB component only exposed one interface.

Remote EJB Applications

An EJB remote application can be one of the following:

  • a standalone Java application
  • another component that runs within a application server instance, and makes invocations into remote EJBs. In this case, each deployed application will have its own EJB client context, and the application's components will share the EJB client context.

Invoking into EJBs

The invocation mechanics is different depending on where the caller and the target EJBs reside. There are several cases:

  • The caller is a component collocated with the target EJB in the same deployment unit (JAR, WAR or EAR).
  • The caller is a component deployed as part of a different deployment unit than the target EJB, but both components are deployed on the same Application Server (JBoss) instance.
  • The caller is a component deployed on an Application Server (JBoss) instance, while the target EJB is deployed on a different Application Server (JBoss) instance. This case qualifies as a [[#deployed_application|remote EJB application. Remote invocations are necessary.
  • The caller is a standalone application. Remote invocations are necessary.
  • Clustering.

TODO https://blog.akquinet.de/2014/09/26/jboss-eap-wildfly-three-ways-to-invoke-remote-ejbs/

EJB Client API

JBoss EAP 6 introduced the EJB client API for managing remote EJB invocations. The EJB client API uses the EJB Client Context.

EJB Client Context

The EJB client context may be associated with, and used by more than one thread concurrently.

There can potentially be more than one EJB client contexts into a JVM. For deployed applications, each application will have its own EJB client context. Whenever that application invokes another EJB, the corresponding EJB client context is used to find the correct EJB receiver, which then handles the invocation.

For standalone applications, a remote standalone client typically has just one EJB client context backed by any number of EJB receivers

An EJB client context may contain any number of EJB receivers.

The EJB client context is configured with jboss-ejb-client.properties for standalone applications and with jboss-ejb-client.xml for applications deployed within the EAP.

EJB Receiver

An EJB receiver is a component that knows how to communicate with a server that is capable of handling EJB invocations.