Developing Rich EJB Clients With GlassFish

As discussed in detail in my book, developing EJB clients with Java EE 5 is very easy when the client application is managed by the EJB container, for example a servlet or a JSF managed bean. For these types of clients, all that is needed to access the EJB is to decorate the declaration of the class variable with the @EJB annotation, and an instance of a class implementing the session bean's remote (or local, as the case might be) interface will be automatically injected at runtime via dependency injection.

For example, a servlet that acts as a client for a session bean could be coded as illustrated in the following example:

public class MyServlet extends HttpServlet
{
  @EJB
  private static MySession mySession;
  
  protected void doGet()
  {
    //we can simply use our session bean since it is 
    //automatically injected at runtime.
    mySession.doSomething();
  }
}

Unfortunately, for stand-alone EJB clients, the technique demonstrated in this example does not work, since the client code needs to be executing inside the application server. Instead, we need to do a JNDI lookup to obtain a reference to the session bean's remote or local interface (at least we skip the step of having to lookup the bean's home interface, then obtaining the implementation of the bean's remote or local interface from it, as was the case with older J2EE applications).

Fortunately for those of us using GlassFish to deploy our Java EE 5 applications, when using this application server there are a couple of ways we can use EJB dependency injection when developing a stand alone EJB client.

One way we can use the above technique when we need a stand alone EJB client is to use the appclient utility included with GlassFish. This utility is essentially a "client container", it wraps an executable JAR file in a container, allowing us to use dependency injection as illustrated in the example. The appclient executable can be found in the bin subdirectory of the directory where GlassFish was installed.

In order for the appclient utility to work, our client must be packaged in an executable JAR file. As experienced Java developers know, a JAR file can be made executable by creating a file called MANIFEST.MF containing the following line:

Of course, net.ensode.App needs to be replaced with the fully qualified name of the class containing the main() method we want to execute when executing the JAR file. Most modern IDE's such as Eclipse, NetBeans, IntelliJ Idea, etc. and build tools such as ANT or Maven can automate the creation of executable JAR files.

In any case, once we have an executable JAR file, we can "wrap" it in a client container by passing it as a parameter to the appclient utility:

The above command assumes the appclient utility is in the system PATH. Once it is executed, the client JAR file will behave as if it was deployed in the Java EE 5 application server.

The above technique works great, however it has the disadvantage that we (and our users!) need to remember to use the appclient utility every time the application is executed. Also, just like most stand alone applications, and unlike web applications, distributing updated versions of our application to the users is not trivial nor automatic.

Fortunately, there is an alternate way we can have EJB dependency injection work with a stand alone, Java Swing based application. A very nice feature of GlassFish version 2 is that it allows any Java Swing application to be deployed as a Java Web Start application.

Java Webstart applications are stand alone Java applications that are distributed via the browser. The first time the user points the web browser to the URL of a Java Web Start application, the application is automatically downloaded and installed in the user's hard drive. On subsequent times, Java Web Start will check to see if a new version of the application has been deployed, and if this is the case the new version is downloaded and installed automatically, if no new version has been deployed, the current version is simply executed.

GlassFish makes it dead easy to deploy an application as a Java Web Start application, all we need to do is copy an executable JAR file to the autodeploy directory under the domain directory where we wish to deploy our application. Since Java Web Start applications are considered to be "in the container" EJB dependency injection works properly.

For more information on GlassFish and Java EE 5 development, please check out my book, Java EE 5 Development using GlassFish Application Server.