EJB FAQ

 

Here are answers to some frequently asked questions about how to use Enterprise Java Beans within SUN's Application Server implementations.   Additional resources can be found here.  Please send any follow-up questions or comments to ejb@glassfish.dev.java.net.

---

EJB Clients

• How do I access a Remote EJB from a stand-alone java client?

• Is a stand-alone Java client portable?  What's the difference between a stand-alone Java client and an Application Client component?

• How do I access a Remote EJB (3.0 or 2.x) from a non-Java EE web container like Tomcat or Resin?

• What if I have multiple instances of the Appserver running and I want to access a Remote EJB between them?

• Do I need RMI stubs to access EJBs from my java client?

• What if I have an existing stand-alone java client that accesses EJBs through the CosNaming JNDI provider ?  How do I get static RMI-IIOP stubs for it?

• What is the relationship between @EJB and ejb-ref/ejb-local-ref?

• I have a Remote ejb dependency (@EJB or ejb-ref) in my Java EE component.  How do I control which actual target ejb it refers to?

  
  

Local EJB Access

       

• How do I access a Local EJB from a POJO or utility class?

• I have an EJB with a Local interface. Can I access it from an Application Client or a stand-alone java client ?

• I have an EJB with a Local interface.  Can I access it from a web component in a different application?

Global JNDI names

• How are Global JNDI names assigned to Session / Entity beans?  

• How do I specify the Queue or Topic that a Message Driven Bean should consume from?

• I have a 3.0 Session bean with multiple Remote Business interfaces.  How do I look up a specific Remote Business Interface from a stand-alone java client?  
  

---

How do I access a Remote EJB from a stand-alone java client?

Step 1.  Use the no-arg InitialContext() constructor in your code.

The most common problem developers run into is passing specific JNDI bootstrapping properties to InitialContext(args).  Stand-alone java clients that access Java EE services are by definition non-portable, so every Java EE implementation has different requirements for how to bootstrap the naming provider.  (See here for more information on writing portable clients).  Instead of requiring the developer to hard-code specific JNDI bootstrapping properties, we have put a jndi.properties file within appserv-rt.jar.   The JNDI machinery in Java SE automatically detects this file when used in conjunction with no-arg InitialContext() and bootstraps the correct naming provider.  

Step 2.  Pass the global JNDI name of the Remote EJB to InitialContext.lookup()

Stand-alone java clients do not have access to a component naming environment (java:comp/env) or to the @EJB annotation, so they must explicitly use the global JNDI name to lookup the Remote EJB.   (See here for more information on how global JNDI names are assigned to EJBs) Assuming the global JNDI name of the Remote EJB is "FooEJB" :

For EJB 3.0 Beans with a Remote Business interface  :

  InitialContext ic = new InitialContext();
  Foo foo = (Foo) ic.lookup("FooEJB");

Note that in the EJB 3.0 case the result of the lookup can be directly cast to the remote business interface type without using PortableRemoteObject.narrow().  

For EJB 2.1 and earlier session/entity beans :

  InitialContext ic = new InitialContext();
  Object homeObj = ic.lookup("FooEJB");
  FooHome fooHome = (FooHome) PortableRemoteObject.narrow(homeObj, FooHome.class);  
  Foo foo = fooHome.create(...)
  ...

Step 3.  Include appserv-rt.jar and javaee.jar in the java client's classpath.

As mentioned in Step 1, appserv-rt.jar is needed to correclty bootstrap the naming provider within our appserver implementation. javaee.jar contains the API classes for Java EE 5. E.g., assuming the application classes are in /home/user1/myclasses and the main client class is acme.MyClient :

  java -classpath $APS_HOME/lib/appserv-rt.jar:$APS_HOME/lib/javaee.jar:/home/user1/myclasses acme.MyClient

Note : appserv-rt.jar uses the JAR MANIFEST-CLASSPATH attribute to include other dependent .jars within the lib directory.  When setting your client classpath, it is best to directly refer to the appserv-rt.jar within the app server lib directory rather  than copying it to another location.  If you do copy appserv-rt.jar, you'll need to copy additional .jars such as  appserv-deployment-client.jar and appserv-ext.jar.  The full set of .jars that might be needed by appserv-rt.jar is located in its META-INF/MANIFEST.MF file.  

If your stand-alone client makes use of JMS, you'll also need to add $APS_HOME/lib/install/applications/jmsra/imqjmsra.jar, $APS_HOME/lib/appserv-admin.jar and $APS_HOME/lib/appserv-ws.jar

If your stand-alone client makes use of the Java Persistence API (e.g. it calls a Remote EJB that returns a Java Persistence  API entity ), you'll also need to add $APS_HOME/lib/toplink-essentials.jar

Step 4.  Set the server host property, if necessary.

If the stand-alone java client is running on a different host than the server, set the -Dorg.omg.CORBA.ORBInitialHost property when starting the client JVM.  E.g., assuming the server is running on host com.acme.Host1 :

  java -Dorg.omg.CORBA.ORBInitialHost=com.acme.Host1
         -classpath $APS_HOME/lib/appserv-rt.jar:$APS_HOME/lib/javaee.jar:/home/user1/myclasses acme.MyClient


This property defaults to localhost, so it is not necessary to set it if the java client is running on the same machine as the server.

Step 5.  Set the naming service port property, if necessary.

The default naming service port in the app server is 3700.   If the naming service is running on a different port, you'll need to set it via the -Dorg.omg.CORBA.ORBInitialPort property when starting the client JVM.   You can double-check the actual naming service port for a given server instance by looking in the server instace's domain.xml for "orb-listener-1". Alternatively, check the Applications..Configuration..ORB..IIOP Listeners section of the admin GUI for orb-listener-1.  

Assuming the server's naming service port is 9876 and the client is on the same host as the server :

java -Dorg.omg.CORBA.ORBInitialPort=9876
         -classpath $APS_HOME/lib/appserv-rt.jar:$APS_HOME/lib/javaee.jar:/home/user1/myclasses acme.MyClient

---

Is a stand-alone Java client portable?  What's the difference between a stand-alone Java client and an Application Client component?

The Java EE platform defines a component that is specially designed to portably access Java EE services from a JVM running outside of the Application Server.   It is called a Java EE Application Client and has been part of the platform since the first release (J2EE 1.2).   Like all Java EE components it runs within a container provided by the vendor's implementation.  The main advantages of the Application Client are that it's portable and that it allows the developer to use the same programming model for defining and accessing resources as is used within web components and EJBs.  It follows the overall philosophy of the Java EE platform that as much of the "plumbing" or system-level work as possible should be performed by a container instead of being part of the Application code.   That means a guarantee that the no-arg InitialContext constructor will work, that a private component naming context (java:comp/env) is available, and in Java EE 5 that platform annotations and injection are available.  

One of the most common issues faced by developers is how to initialize the naming context within a client that accesses EJBs.   When such a client is *not* written as an Application Client it is referred to as a "stand-alone" java client.  By definition, such stand-alone java clients are not portable, so each vendor defines its own way to bootstrap the naming service. This not only makes it more difficult to code the client but causes problems when moving between Java EE implementations.

Like all Java EE components, there are some additional steps required to achieve the portability offerered by the Application Client.   E.g.,  definining a deployment descriptor, packaging the application client .jar and learning how to run the Application Client container.  However, these steps have been simplified as part of the ease-of-use effort in Java EE 5 and SUN's Java EE 5 implementations.  

See the following for more details on using Application Clients :

Chapter 22 (Getting Started with EJBs) of the Java EE 5 tutorial

Simple EJB 3.0 session / message-driven bean code examples

Client chapter of our Developer's Guide

---

How do I access a Remote EJB (3.0 or 2.x) from a non-Java EE web container like Tomcat or Resin?

Accessing a Remote EJB from a non-Java EE web container is similar to the stand-alone java client case.    However, the complication is that most Java web servers set the default JNDI name provider for the JVM, which prevents our appserver naming provider from being instantiated when the application uses the no-arg InitialContext() constructor.   The solution is to explicitly instantiate an InitialContext(Hashtable) with the properties for our naming provider, as contained in appserv-rt.jar's jndi.properties file.  

Step 1.  Instantiate the InitialContext 

    Properties props = new Properties();
    props.setProperty("java.naming.factory.initial",
                             "com.sun.enterprise.naming.SerialInitContextFactory");
    props.setProperty("java.naming.factory.url.pkgs",
                             "com.sun.enterprise.naming");
    props.setProperty("java.naming.factory.state",
                             "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

    // optional.  Defaults to localhost.  Only needed if web server is running
    // on a different host than the appserver   
    props.setProperty(" org.omg.CORBA.ORBInitialHost", "localhost ");

    // optional.  Defaults to 3700.  Only needed if target orb port is not 3700.
    props.setProperty(" org.omg.CORBA.ORBInitialPort", "3700");

    InitialContext ic = new InitialContext(props);

Step 2.  Use the global JNDI name of the target Remote EJB in the lookup.

    EJB 3.0 :  

    E.g., assuming a Remote 3.0 EJB with a global JNDI name of com.acme.FooRemoteBusiness

    FooRemoteBusiness foo = (FooRemoteBusiness) ic.lookup("com.acme.FooRemoteBusiness");



    EJB 2.x :

    E.g., assuming a Remote 2.x EJB with a global JNDI name of com.acme.FooHome

    Object obj = ic.lookup("com.acme.FooHome");
    FooHome fooHome = (FooHome) PortableRemoteObject.narrow(obj, FooHome.class);

Step 3.  Add the necessary appserver code to the web server's classpath.

See step 3 of stand-alone client access for the list of required .jars.  

Step 4.  For EJB 3.0 Remote access, use at least Glassfish V2 or Java EE 5 SDK(SJS AS 9) Update 1. 

Builds from this point on will contain a required bug fix.  
See https://glassfish.dev.java.net/issues/show_bug.cgi?id=920  for more details.

---

What if I have multiple instances of the Appserver running and I want to access a Remote EJB between them?

If the two server instances are part of the same cluster, there is no special mapping needed.   By definition, a cluster is homogeneous, meaning the exact same set of applications is deployed to all instances.   Each server instance has the same entries in its global JNDI namespace, so the target Remote EJB can always be resolved intra-server.  Therefore, it would never be a good idea to explicitly refer to a Remote EJB in one server instance in the cluster from a different server instance in the same cluster.

However, if the server instances are either both stand-alone instances or this a cross-cluster access, the only difference is the syntax of the global JNDI name used to resolve the ejb-ref or @EJB.   Since the calling code is running within a Java EE component (web or ejb), it should use the standard Java EE programming model for accessing remote EJBs -- @EJB or ejb-ref + java:comp/env lookup.   The application code and any ejb-ref .xml should remain location transparent so that the mapping to physical EJB can be changed without affecting any portable code or descriptors.

Follow the steps outlined here , but instead of using an unqualified global JNDI name, use the CORBA interoperable naming syntax :   corbaname:iiop:<host>:<port>#<global_jndi_name>

E.g., assume we have a web application running in a non-clustered app server instance on host1 that wants to access a Remote Stateless Session bean in an app server instance on host2.  The target Remote EJB has a global JNDI name of Foo.

Within servlet :

@EJB(name="fooejbref")
private FooRemote fooRemote;

Within sun-web.xml :

  <ejb-ref>
    <ejb-ref-name>fooejbref</ejb-ref-name>
    <jndi-name>corbaname:iiop:host2:3700#Foo</jndi-name>
  </ejb-ref>

---

Do I need RMI stubs to access EJBs from my java client?

No, not in our J2EE 1.4 SDK and Java EE 5 SDK implementations. (Glassfish, Sun Java System Application Server 8.x, 9.x) Our implementation uses a feature called "Dynamic RMI-IIOP" that creates any necessary RMI-IIOP stubs at runtime in a way that is completely hidden from the application.   This makes deployment much faster and avoids many of the configuration problems that result from having to add static stubs to your client.   However, the dynamic RMI-IIOP feature is only enabled when the client is using the naming provider from our server implementation.  If the client is a stand-alone java client, that means following the instructions here or here , or using an Application Client component.   Any explicit use of the CosNaming provider in the client will not be able to use the Dynamic RMI-IIOP feature, which is why we don't recommend that approach.  If you must use CosNaming, see here.  

---

What if I have an existing stand-alone java client that accesses EJBs through the CosNaming JNDI provider ?  How do I get static RMI-IIOP stubs for it?

First, read about Portable Java EE clients and "How To Write a Stand-alone Client".  The best option would be to change the client to an Application Client or to follow our stand-alone java client recommendations.  If that's not possible, you can request that static RMI-IIOP stubs be generated during deployment by using the  --generatermistubs option on the asadmin deploy command.    In this case, the static RMI-IIOP stubs will be placed within the client.jar file.   E.g.

  asadmin deploy --generatermistubs --retrieve /home/user1/clientstubdir  fooapp.ear

After the command executes, the client.jar containing the static RMI-IIOP stubs will be in /home/user1/clientstubdir/fooappClient.jar.

The reason static RMI-IIOP stubs are still needed in this case is that if the CosNaming provider is instantiated, it is not using the client naming provider from our appserver implementation.  It instead uses an ORB from Java SE which does not support dynamic RMI-IIOP.

---

What is the relationship between @EJB and ejb-ref/ejb-local-ref?

The @EJB annotation and the ejb-ref/ejb-local-ref .xml elements are used to specify the same semantic information.  Specifically, that a Java EE component has a dependency on a local or remote EJB.  Every @EJB can be translated into an equivalent ejb-ref/ejb-local-ref.  @EJB is easier to use but it serves the same purpose as ejb-ref/ejb-local-ref.   Here's a table with more details :

@EJB attribute	description	default value	ejb-ref equivalent	ejb-local-ref equivalent
name()	Unique location within the private component namespace(java:comp/env).	field-level : <fully-qualified name of declaring class>/<field-name> method-level : <fully-qualified name of declaring class>/<property name> class level : name() is required.	ejb-ref-name	ejb-ref-name
beanInterface()	For EJB 3.0 business interfaces, the Local or Remote business interface of the session bean. For EJB 2.x, the Home/LocalHome interface of the session/entity bean.	field-level : the type of the declared field. method-level : the type of the single setter parameter class level : beanInterface() is required.	For EJB 3.0 : <remote> For EJB 2.x : <home>	For EJB 3.0 : <local> For EJB 2.x : <local-home>
beanName()	ejb-name (*not* global JNDI name) of the target ejb within the application.   This can be used whenever the target ejb is defined within the same application as the referencing component, regardless of local vs. remote.   The only time it can't be used is if the @EJB refers to a Remote interface (3.0 or 2.x) that is defined outside the application.	Automatically resolved if there is only one ejb within the application that exposes  the value of beanInterface()	ejb-link	ejb-link
mappedName()	Specifies the product-specific name of the target Remote EJB.  In SUN's case, this refers to the global JNDI name of the target Remote EJB.   Not applicable for local interfaces because beanName() can always be used.	If the target ejb is defined within the same application and the beanName() default applies, no additional mapping is required. Otherwise, the target global JNDI name will be set to the value of beanInterface()	mapped-name	n/a

---

I have a Remote ejb dependency (@EJB or ejb-ref) in my Java EE component.  How do I control which actual target ejb it refers to?

If the target ejb is defined within the same application as your referencing component AND there is only one target ejb within the application that exposes the remote interface associated with your ejb dependency, the mapping will be done automatically.   In this case, there is no need to specify any additional mapping information.

Otherwise, there are 3 ways to map the remote ejb dependency to the target Remote EJB.  From highest to lowest precedence, they are :

1. Use the sun-specific deployment descriptor

Map the remote ejb dependency to the global JNDI name of the target ejb within the sun-*.xml {sun-web.xml, sun-application-client.xml, sun-ejb-jar.xml} file corresponding to the module in which the ejb dependency is defined.  

E.g. given a remote ejb dependency defined within a servlet (com.acme.MyServlet) :

@EJB(name="fooejbref")
private FooRemote fooRemote;

To map this remote ejb dependency to an ejb with global JNDI name "Foo" :

Within sun-web.xml :

  <ejb-ref>
    <ejb-ref-name>fooejbref</ejb-ref-name>
    <jndi-name>Foo</jndi-name>
  </ejb-ref>

If the @EJB did not use the name() attribute, you would need to refer to the default name() of the ejb dependency when specifying the sun-*.xml mapping. E.g. :

@EJB
private FooRemote fooRemote;

To map this remote ejb dependency to an ejb with global JNDI name "Foo" :

Within sun-web.xml :

  <ejb-ref>
    <ejb-ref-name>com.acme.MyServlet/fooRemote</ejb-ref-name>
    <jndi-name>Foo</jndi-name>
  </ejb-ref>
  

2. Use @EJB mappedName() or the ejb-ref mapped-name element.

For @EJB, specify the global JNDI name of the target ejb using the mappedName() attribute.  E.g.

@EJB(name="fooejbref", mappedName="Foo")
private FooRemote fooRemote;

Note that mappedName() is completely different than name().  name() refers to a location within the private component environment namespace (java:comp/env) that represents this ejb dependency.   mappedName() refers to a location within a product-specific *global* namespace that holds the ejb Home / Remote business object.

For ejb-ref, specify the global JNDI name of the target ejb using the mapped-name element.  E.g.

<ejb-ref>
   <ejb-ref-name>fooejbref</ejb-ref-name>
   <remote>com.acme.FooRemote</remote>
   <mapped-name>Foo</mapped-name>
</ejb-ref>

If an ejb-ref and an @EJB are defined for the same ejb dependency(meaning name() equals ejb-ref-name) in the same component environment, the values in ejb-ref take precedence.  

3. Use @EJB beanName() or ejb-ref ejb-link element.

beanName() and ejb-link only apply if the target remote ejb is defined within the same application as the referencing component.    In this case, the value is the ejb-name of the target bean, *not* the global JNDI name.  If the target ejb is defined using ejb-jar.xml, the ejb-name is the value of the <session> or <entity> ejb-name element.  If the target ejb is defined using annotations, the ejb-name is either the value the @Stateless/@Stateful name() attribute or if name() was not specified, the *unqualified* bean class name.  

E.g. , assuming our target ejb (com.acme.FooBean) is defined as follows :

@Stateless
public class FooBean implements FooRemote { ... }

To map the servlet ejb dependency using beanName() :

@EJB(name="fooejbref", beanName="FooBean")
private FooRemote fooRemote;

To map the servlet ejb dependency using ejb-link :

<ejb-ref>
   <ejb-ref-name>fooejbref</ejb-ref-name>
   <remote>com.acme.FooRemote</remote>
   <ejb-link>FooBean</ejb-link>
</ejb-ref>


Note that ejb-name is only guaranteed to be unique within an ejb-jar module.   If there are multiple ejb-jars within the .ear that define an ejb with the same ejb-name, the following beanName()/ejb-link syntax can be used to explicitly refer to the target ejb :  <relative ejb-jar module uri>#<ejb-name>.

E.g., given an application containing ejb1.jar, ejb2.jar, and web1.war, where ejb1.jar and ejb2.jar both define an ejb with ejb-name FooBean :

To map the servlet ejb dependency to the ejb in ejb1.jar using beanName() :

@EJB(name="fooejbref", beanName="ejb1.jar#FooBean")
private FooRemote fooRemote;

To map the servlet ejb dependency to the ejb in ejb1.jar using ejb-link :

<ejb-ref>
   <ejb-ref-name>fooejbref</ejb-ref-name>
   <remote>com.acme.FooRemote</remote>
   <ejb-link>ejb1.jar#FooBean</ejb-link>
</ejb-ref>

If an ejb-ref and an @EJB are defined for the same ejb dependency(meaning name() equals ejb-ref-name) in the same component environment, the values in ejb-ref take precedence.  

---

I have an EJB with a Local interface. Can I access it from an Application Client or a stand-alone java client ?

No.  The EJB Local view is an optimized EJB invocation path that uses call-by-reference semantics.   It is only available to web components and ejb components that are part of the *same application* as the target EJB.   That's why ejb-local-ref is not even part of the schema for application-client.xml.   To access EJBs from an Application Client or stand-alone java client,  you'll need to use either a Remote 3.0 Business interface, a 2.x Home interface, or web services.

---

I have an EJB with a Local interface.  Can I access it from a web component in a different application?

No, not in our implementation.  The EJB spec only requires local ejb access from within the same application in the same JVM.    

---

How do I access a Local EJB from a POJO?

Local EJB access is only portable from within the same application, so the POJO class must be called from a component running within the same application as the target Local EJB.  Injection is not supported for POJO classes, so the POJO needs to look up the local EJB reference within the private namespace (java:comp/env) of the component within whose scope it is executing.    

Step 1.  Define the local ejb dependency for the component within whose scope the POJO will execute.

Assume the POJO wants to access a local EJB 3.0 business interface FooLocal from the following EJB defined within the same application :

@Stateless
public class FooBean implements FooLocal { ... }

If the POJO is called from a web application, the java:comp/env namespace is shared by the entire .war.  So, the local EJB dependency can be defined by using an @EJB annotation on any managed class within the .war.    

E.g.

@EJB(name="fooejbref", beanInterface=FooLocal.class)
public class MyServlet extends HttpServlet { ...

Likewise, if the POJO is itself called from an EJB, the local EJB dependency must be defined within that EJB component.  Unlike the .war case, the component environment (java:comp/env) is scoped at the bean level for EJBs.

@EJB(name="fooejbref", beanInterface=FooLocal.class)
@Stateless
public class BarBean implements BarLocal { ...


Alternatively, the local EJB dependency can be declared within the standard deployment descriptor corresponding to the component within whose scope the POJO is executing (web.xml / ejb-jar.xml)

   <ejb>
      <ejb-name>BarBean</ejb-name>
      <ejb-class>com.acme.BarBean</ejb-class>
 
       ...

        <ejb-local-ref>
          <ejb-ref-name>fooejbref</ejb-ref-name>
          <local>com.acme.FooLocal</local>
          <ejb-link>FooBean</ejb-link>
        </ejb-local-ref>

    </ejb>

Step 2.  In the POJO code, lookup the local EJB dependency within java:comp/env

    InitialContext ic = new InitialContext();
    FooLocal foo = (FooLocal) ic.lookup("java:comp/env/fooejbref");


Note that if the POJO is called from multiple components, e.g. from both the web application and BarBean, you'll need to define the same local EJB dependency for both calling components so that it is always defined in the currently active component environment when the POJO does its lookup.

---

How are Global JNDI names assigned to Session / Entity beans?  

First, global JNDI names only apply to Session/Entity beans that have some kind of Remote interface.   If the Session/Entity bean only has some combination of Local interfaces and Web Service interfaces, global JNDI names do not apply.  In that case, any specified global JNDI name will be ignored.

In our J2EE 1.4 implementation (Application Server 8.x) , there is only one way to assign a global JNDI name to a session/entity bean's Remote view :

Map the bean's <ejb-name> to a <jndi-name> within the <ejb> element in sun-ejb-jar.xml.  E.g.

<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>FooBean</ejb-name>
      <jndi-name>FooEJB</jndi-name>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

In our Java EE 5 implementation (Application Server 9.x) , there are four ways to specify JNDI name for a session/entity bean.  In decreasing order of precedence, they are :

1. Use sun-ejb-jar.xml (Same as above)

2. Specify the bean's global JNDI name using the mapped-name element in ejb-jar.xml

<enterprise-beans>
  <session>
    <ejb-name>FooBean</ejb-name>
    <mapped-name>FooEJB</mapped-name>
    ...
  </session>
</enterprise-beans>

3. Specify the bean's global JNDI name within the @Stateless/@Stateful mappedName() attribute.  E.g.,

@Stateless(mappedName="FooEJB")
public class FooBean implements Foo { ... }

4. If no global JNDI name has been specified, a default global JNDI name will be generated according to the following table :

Bean has 2.x Home/Remote interfaces	Total # of 3.0 Remote Business interfaces	default JNDI name	example
No	0	n/a	n/a
Yes	0	fully-qualified name of Home interface	com.acme.FooHome
No	1	fully-qualified name Remote Business interface	com.acme.FooBusiness
No	2 or more	No default -- JNDI name must be specified	n/a
Yes	1 or more	No default -- JNDI name must be specified	n/a

---

How do I specify the Queue or Topic that a Message Driven Bean should consume from?

In our J2EE 1.4 implementation (Application Server 8.x) :

Map the bean's <ejb-name> to the Global JNDI name of the Queue/Topic's JMS resource in sun-ejb-jar.xml :

<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>FooMessageBean</ejb-name>
      <jndi-name>jms/NotificationQueue</jndi-name>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

In our Java EE 5 implementation (Application Server 9.x) , there are three ways to do it.  In decreasing order of precedence, they are :

1. Use sun-ejb-jar.xml (Same as above)

2. Specify the global JNDI of the Queue/Topic JMS Resource using the mapped-name element in ejb-jar.xml

<enterprise-beans>
  <message-driven>
    <ejb-name>FooMessageBean</ejb-name>
    <mapped-name>jms/NotificationQueue</mapped-name>
    ...
  </message-driven>
</enterprise-beans>

3. Specify the global JNDI name of the Queue/Topic JMS Resource using the @MessageDriven mappedName() attribute.  E.g.,

@MessageDriven(mappedName="jms/NotificationQueue")
public class FooMessageBean implements javax.jms.MessageListener { ... }

---

I have a 3.0 Session bean with multiple Remote Business interfaces.  How do I look them up from a stand-alone java client?  

Each Remote Business Interface can be looked up using a name derived from the combination of the target ejb's global JNDI name and the specific Remote Business Interface, separated by a "#".  For example, if the Session Bean's sun-ejb-jar.xml is :

<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>FooBean</ejb-name>
      <jndi-name>FooEJB</jndi-name>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

and it has 2 Remote Business interfaces { com.acme.FooBusiness1, com.acme.FooBusiness2 } the stand-alone client would look up each as follows :

   InitialContext ic = new InitialContext();
   FooBusiness1 bean1 = (FooBusiness1) ic.lookup("FooEJB#com.acme.FooBusiness1");
   FooBusiness2 bean2 = (FooBusiness2) ic.lookup("FooEJB#com.acme.FooBusiness2");

Note that in the typical case of a bean only having one Remote Business Interface, this fully-qualified form is not needed. In that case, the bean's JNDI name can be used directly :

   FooBusiness bean = (FooBusiness) ic.lookup("FooEJB");


注：以上内容来自网络，本人不承担连带责任
文章转自：http://blog.csdn.net/DL88250/archive/2007/12/07/1923742.aspx