Session EJB and Servlet on Different JBoss Instances: Difference between revisions
Line 17: | Line 17: | ||
=EJB Lookup= | =EJB Lookup= | ||
The consuming component, the servlet in this case, needs a way to look up the EJB reference that has been deployed on a remote JBoss instance. This is done internally by JBoss instance using a JBoss-specific mechanism named [[EJB_Concepts#EJB_Client_Context|EJB client context]]. In order to use the EJB client context that knows how to invoke into the remote JBoss instance, and not the default | The consuming component, the servlet in this case, needs a way to look up the EJB reference that has been deployed on a remote JBoss instance. This is done internally by JBoss instance using a JBoss-specific mechanism named [[EJB_Concepts#EJB_Client_Context|EJB client context]]. In order to use the EJB client context that knows how to invoke into the remote JBoss instance, and not the default EJB client context, the WAR must contain a JBoss-specific deployment descriptor named jboss-ejb-client.xml in its /WEB-INF directory. | ||
<pre> | <pre> |
Revision as of 20:16, 24 March 2017
Internal
Overview
This example describes how a client component (servlet) deployed on a different JBoss instance looks up an EJB and makes a remote invocation.
GitHub Example
Business Interface Type Access
The calling servlet needs to business interface type to make the call, so the classes related to the business interface will have to be packaged within the WAR. Since those classes are also needed in the EJB deployment unit, the best strategy is to develop those as part of shared "common-types" Maven module, and pull its artifact both in the WAR and the EJB JAR. The example linked above showcases this approach.
EJB Lookup
The consuming component, the servlet in this case, needs a way to look up the EJB reference that has been deployed on a remote JBoss instance. This is done internally by JBoss instance using a JBoss-specific mechanism named EJB client context. In order to use the EJB client context that knows how to invoke into the remote JBoss instance, and not the default EJB client context, the WAR must contain a JBoss-specific deployment descriptor named jboss-ejb-client.xml in its /WEB-INF directory.
<jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> <client-context> <ejb-receivers> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-container-1"/> </ejb-receivers> </client-context> </jboss-ejb-client>
More details about jboss are available here:
<outbound-connections> <remote-outbound-connection name="remote-ejb-container-1" outbound-socket-binding-ref="remote-ejb-container-socket-1" protocol="http-remoting"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> </outbound-connections>
JNDI
The EJB reference is looked up in JNDI using the portable JNDI EJB naming scheme.
In this case, the EJB is named SimpleStatelessBean, it is deployed as part of the stateless-ejb-example.jar deployment unit (JEE module). Considering the fact there is no JEE application (EAR), the simplest possible portable JNDI name the servlet can use to look up the EJB is "java:global/stateless-ejb-example/SimpleStatelessBean".
For more details on the JNDI EJB naming scheme, see:
The code that does the JNDI lookup is similar to:
SimpleStateless bean = null; ... try { InitialContext ic = new InitialContext(); SimpleStateless bean = (SimpleStateless)ic.lookup("java:global/stateless-ejb-example/SimpleStatelessBean"); } catch(Exception e) { ... }
@EJB
The equivalent @EJB injection would be:
@EJB(mappedName = "java:global/stateless-ejb-example/SimpleStatelessBean") private SimpleStateless bean;
For more details, see
EJB Invocation
Once the EJB reference is obtained from JNDI, business interface methods can be called on its reference:
... bean.methodOne("something from servlet");