[AIX Solaris HP-UX Linux Windows][z/OS]

Configuring EJB bindings in SCA applications (deprecated)

Use this task to learn how to use Enterprise JavaBeans (EJB) bindings in SCA applications.

Support is provided for EJB bindings in 2.x and 3.x-style beans, for service and reference.

The EJB bindings do not support interface.wsdl files.

The following is an example of an composite definition that has a service exposed over an EJB 3.x binding:
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="https://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://neworder/sca/jdbc" 
name="NewOrderComposite">

<component name="NewOrderEJB3ServiceComponent">
<implementation.java class="neworder.sca.jdbc.NewOrderServiceImpl" requires="managedTransaction.local"/>
<service name="NewOrderService" requires="suspendsTransaction">
<interface.java interface="neworder.sca.jdbc.NewOrderService"/>
<binding.ejb ejb-version="EJB3"/>
</service>
</component>
</composite>
A client that wants to invoke the resultant enterprise bean would treat it like any other enterprise bean and not like a regular SCA service. CompositeContext.getService is not supported for a non-SCA binding, therefore, a getService() on the CompositeContext would not work here. The following is the client code for the previous example:
InitialContext ctxt = new InitialContext();
  Object remoteObj = ctxt.lookup("ejb/sca/ejbbinding/NewOrderEJB3ServiceComponent/NewOrderService#neworder.sca.jdbc.NewOrderServiceRemote");
  NewOrderServiceRemote newOrderRemote = (NewOrderServiceRemote) PortableRemoteObject.narrow(remoteObj, NewOrderServiceRemote.class); 
The following is an example of an composite definition that contains references to both EJB 2.x and EJB 3.x bindings:
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="https://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://erww.workload" name="ConvertComposite">

<component name="ConvertInputOutputServiceComponent">
<implementation.java class="convert.inputoutput.sca.ConvertInputOutputServiceImpl"

<reference name="priceQuoteSessionReference">
<interface.java interface="priceQuoteSession.PriceQuoteSession"/>
<binding.ejb uri="corbaname:iiop:localhost:2809/NameServiceServerRoot#ejb/session/PriceQuoteSessionFacadeBean"/>
</reference>
</component>
</composite>

Different binding.ejb attributes can be used for service side EJB bindings or reference side EJB bindings. The following information explains how the default value is calculated for each side:

Service side

The service side EJB binding applies only to Java™ archive (JAR)-packaged SCA applications.

EJB 2.0-level beans
URI is the JNDI name for the home; it can be calculated with the default short name in the following form:
/sca/ejbbinding/component_name/service_name
Therefore, the URI can be calculated as:
corbaname:iiop:localhost:2812/NameServiceServerRoot#ejb/sca/ejbbinding/component_name/service_name
You can use it to look up home.
EJB 3.x-level beans
The URI contains the component-id, therefore, it is calculated the same as the EJB 2.0 beans as follows:
sca/ejbbinding/component_name/service_name 
The URI can be calculated as:
corbaname:iiop:localhost:2812/NameServiceServerRoot#ejb/sca/ejbbinding/component_name/service_name#package.qualified.interface of 
SCA Java interface with prefix of Remote or Local to the class name
You can use it directly to get the business interface.
The following code example displays as if it were a session bean:
<session name="ServiceNameBean" component-id="sca/ejbbinding/component_name/service_name"/>

When an SCA service is exposed through an EJB service binding, the service is exposed through an enterprise bean. During deployment, the SCA runtime generates a session bean for the service exposed through the EJB binding. The caller of the composite service can invoke this service by accessing the generated enterprise bean as if they are invoking any enterprise bean.

The generated enterprise bean for the composite service is in the profile_root/installedApps/cell_name/sca.composite.nameApp.ear/ directory. Callers need to include the client required classes, such as remote or home, of the generated bean in the classpath or bundle the classes in the JAR file. In addition, if the caller application is running on a non-WebSphere application server, a "Bare" Java Standard Edition (SE), or a version of WebSphere Application Server previous to version 7.0 without the Feature Pack for EJB 3.0, then you must run the createEJBStubs command for the generated EJB module to generate client-side stubs and include the generated stubs at the client application. The createEJBStubs command is under the profile_root/installedApps/cell_name/sca.composite.nameApp.ear/ directory. See the topic on the create stubs command.

Reference side

The reference side EJB binding applies to both JAR-packaged applications and web application archive (WAR)-packaged applications, if not otherwise stated.
  • The URI is used to lookup either the EJB 2.x home or EJB 3.x business interface. Follow the naming convention of the Java Enterprise Edition (JEE) specification if you are using an existing JEE EJB module. If you use an SCA service with the binding.ejb attribute, use the value mentioned previously. For more information about the EJB 3.x JNDI name, see the topic EJB 3.x bindings overview.
  • homeInterface: Not used
  • ejb-link-name: Only applies to WAR-packaged SCA applications. When URI is not defined, use it to look up an EJB module that is defined in the same enterprise archive (EAR) as the WAR.
  • session-type: default value "stateless"
  • ejb-version: default value "EJB2"
Attention: A lookup issue for EJB 3.x reference bindings might occur when the URI follows the corbaname:iiop:host:port/NameServiceServerRoot##ejb3_binding_longform pattern This problem exists only for EJB 3.x reference bindings. When the EJB 3.x reference binding URI follows the corbaname:iiop:host:port/NameServiceServerRoot##ejb3_binding_longform pattern, where ejb_binding_longform is ejb/<component-id#<package.qualified.interface>, and if more than one enterprise bean that is implementing the same interface is deployed on that server, lookup may not be directed to the correct EJB with corresponding component ID.
An example of a URI where this problem can occur is as follows:
uri="corbaname:iiop:host:port/NameServiceServerRoot#ejb/EJB3CounterSample/EJB3Beans.jar
/StatelessCounterBean#com.ibm.websphere.ejb3sample.counter.RemoteCounter
There are two enterprise beans implementing the com.ibm.websphere.ejb3sample.counter.RemoteCounter interface. To avoid this issue:
  • Use a URI that does not start with "corbaname:"
  • Use a binding name in the URI that is an EJB binding short form, for example, corbaname:iiop:host:port/NameServiceServerRoot#<package.qualified.interface>.
  • Use a binding name in the URI that is a unique user-defined binding name.
  • Ensure that the two enterprise beans that are deployed on the server do not implement the same interface.
  • Ensure that the EJB binding URI is pointing to an EJB 2.0 bean.
To resolve this problem, follow these guidelines:
  • If the EJB reference binding is accessing an enterprise bean that is located in the same cell, the URI should not start with "corbaname:."
  • For same cell lookup, the URI pattern should be one of the following.
    uri="ejb/EJB3CounterSample/EJB3Beans.jar/StatelessCounterBean#com.ibm.websphere.ejb3sample.counter.RemoteCounter" 
    
    or
    uri="cell/clusters/cluster_name/ejb/EJB3CounterSample/EJB3Beans.jar
    /StatelessCounterBean#com.ibm.websphere.ejb3sample.counter.RemoteCounter" 
    or
    uri="cell/nodes/node_name/servers/server_name//ejb/EJB3CounterSample/EJB3Beans.jar
    /StatelessCounterBean#com.ibm.websphere.ejb3sample.counter.RemoteCounter"
  • Even in cross cell access, the recommended method is to create a namespace binding for the enterprise bean that is accessed by the EJB reference binding. After the namespace binding is created, use the namespace binding in the URI of the EJB reference binding as uri="cell/persistent/name_in_namespace_binding".

Different patterns of the SCA EJB reference binding URI are based on the user setup and configurations. If the SCA EJB reference binding is accessing a stateless session bean on the same server, the EJB reference binding URI can be designated as the JNDI name, uri="ejb/com/app/resumebank/ResumeBankHome". If the SCA EJB reference binding is referencing another SCA service with an EJB binding in the same server, the URI can be designated as the JNDI name, uri="ejb/com/app/resumebank/ResumeBankHome".

If the EJB reference binding is accessing a stateless session bean that is deployed in the same cell, the URI can be based on cluster/node/server setup, for example:
uri="cell/clusters/cluster2/ejb/com/app/resumebank/ResumeBankHome" 
uri="cell/nodes/node_name/servers/server_name/ejb/com/app/resumebank/ResumeBankHome"

If the EJB reference binding is accessing a stateless session bean on a different cell (cross cell) or a mixed cell, you need to create a namespace binding, either an enterprise bean or Corba type, in the administrative console and use the name in namespace binding in EJB reference binding URI such as, uri="cell/persistent/name_in_namespace_binding". For example, uri="cell/persistent/neworder" where neworder is name in the namespace binding.