• EJB tutorial
• GlassFish EJB FAQ 

EJB for DiNo

• Each team will implement DiNo's directory service will as an EJB, using EJB 3.0
• When it is your turn to provide the directory service, you will deploy your directory EJB in a GlassFish instance and tell the class the host and port of your GlassFish's orb-listener-1. If you haven't changed the default port (3700) then the host will be enough.
• Other teams will initialize their notebook servers to use your directory EJB.

Finding an EJB in a remote GlassFish

For another team to use your directory EJB, they have to get a reference to it. That's where your orb-listener-1 host:port information is needed. This code snippet looks up

// assumes host and port are Strings, and port will be null if
// the remote GlassFish is using the default port (3700)
try {
    Properties props = new Properties();
    if( port != null ) {
        props.setProperty("org.omg.CORBA.ORBInitialPort", port);
    }
    props.setProperty("org.omg.CORBA.ORBInitialHost", host);
    InitialContext ic = new InitialContext(props);
    lookedUp = ic.lookup(jndiName);
} catch (Exception e) {
    // take care of the exception
}

Notes

• This code works inside a GlassFish instance, where the InitialContext constructor will return a reference to a GlassFish JNDI provider. If you need to do this outside the container, for example in a unit test suite, see the GlassFish EJB FAQ on how to do that.
• This lookup requires your directory EJB's JNDI name to be "dino.api.Directory". That's the default global JNDI name assigned by GlassFish. You must not change this name, or your directory service will not integrate with other teams' notebook servers. Specifically, do NOT set the mappedName property in the @Stateless annotation on your directory implementation.
• You will not be able to deploy your directory EJB in the GlassFish on einstein, for two reasons
  • the strange networking setup on einstein breaks the JNDI lookup, even though the orb-listener-1 port has been changed to listen on a port that's open through the Franklin firewall
  • since everyone has to use the same global JNDI name, only one team could deploy on einstein at a time (we could work around that by making the directory service's global JNDI name a third lookup parameter, but I don't think it would be worth the trouble, because I don't have a workaround for the first problem)

EJB Deployment

An EJB is deployed in a jar file. The classes that define its API are typically collected into a jar file, which is made available to developers building clients of the EJB. For that reason it's usually called the "client jar". Both the EJB and the clients include the client jar in their classpaths, to ensure that they are using the same interface classes. Using the same interface classes is required for them to communicate.

In the DiNo project, the DiNo directory client jar contains the directory service interface classes. You will include this jar on the classpath for both your notebook service implementation (the client) and your directory service implementation (your directory EJB). You can see it in both the notebook service reference implementation and the directory service reference implementation (that is, you can see dino-directory-client.jar if you open these archives or download them and extract them to folders)

Getting a client jar onto an EJB's classpath is not terribly intuitive - see the DiNo implementation page for more information.

Sample code

Here is an EJB that implements the data management behind the menu service

• menu-ejb.jar

Here is a menu service implementation that uses the EJB

• menu-ejb-svc.war

Both include source code. They should be ready to deploy in GlassFish. I enhanced the RESTful client slightly to include menu-ejb on the base URL drop-down. The menu-ejb-svc is also available on einstein.

Note that the menu-ejb-svc includes menu-ejb-client.jar in its WEB-INF/lib. This jar includes the EJB's API, but not the implementation. The service needs it so that it can work with the EJB's interface and the types mentioned in the interface. 

Note also that the menu.api.Menu class has to implement the java.io.Serializable interface; if it doesn't, Java RMI will refuse to transfer it from the EJB to the client.

Exercise

The menu-ejb-svc will only work with a menu EJB deployed in the same GlassFish instance. Enhance it so that it can be re-directed at runtime to menu EJBs deployed in other GlassFish instances (unfortunately, you won't be able to test this with einstein, because of its JNDI issues)