J2EE Without the Application Server

Step 7: Coding the Application

Since we don't use a container, we merely provide a Java application to bootstrap the entire banking system. Our Java application is very simple: it suffices to retrieve the configured objects (wired together by Spring during the read-in of the XML file). This application can run on any compliant JDK (Java Development Kit), and does not need an application server to run.

package jms;



import java.io.FileInputStream;

import java.io.InputStream;

import org.springframework.beans.factory.xml.XmlBeanFactory;

import com.atomikos.jms.QueueReceiverSessionPool;

import jdbc.Bank;



public class StartBank

{

  public static void main ( String[] args )

  throws Exception

  {

    //open bean XML file

    InputStream is = 

    new FileInputStream(args[0]);

    

    //the factory is Spring's entry point

    //for retrieving the configured 

    //objects from the XML file

    XmlBeanFactory factory = 

        new XmlBeanFactory(is);

    

    //retrieve the bank to initialize

    //alternatively, this could be done

    //in the XML configuration too

    Bank bank = 

        ( Bank ) factory.getBean ( "bank" );

    

    //initialize the bank if needed

    bank.checkTables();



    //retrieve the pool; 

    //this will also start the pool 

    //as specified in the beans XML file

    //by the init-method attribute!



    QueueReceiverSessionPool pool  = 

        ( QueueReceiverSessionPool ) 

        factory.getBean ( 

        "queueReceiverSessionPool" );



    //Alternatively, start pool here 

    //(if not done in XML)

    //pool.start();



    System.out.println ( 

        "Bank is listening for messages..." );

        

  }

}

That's it! Isn't J2EE easy these days?

Reflections on Generalization

In this section we look at some additional concepts that are important in many J2EE applications. We will see that an application server is not really necessary for these, either.

Clustering and Scalability

Robust enterprise applications typically need cluster capabilities in order to scale up and down. In the case of message-driven applications, this is easy: we automatically get the inherent scalability of JMS applications. If we need more processing power, then we just need to add more processes that connect to the same JMS server. A useful measurement of server performance is the number of outstanding messages in the queues. In other situations like web-based architectures (see below) we can easily use the clustering ability of the web environment.

Method-Level Security

One of the classical arguments in favor of EJB is the ability to add method-level security. Although not shown in this article, it is possible to configure method-level security in Spring, in a manner similar to how we added method-level transaction demarcation.

Generalization to Non-Message-Driven Applications

The platform we have used can easily be integrated into any J2EE web application server, without needing to change the source code (except the main application class). Alternatively, the back-end processing can be invoked via JMS; this keeps the web server responsive and independent of the latency caused by back-end processing. In any case, an EJB container is not needed in order to do container-managed transactions or to have container-managed security.

What about Container-Managed Persistence?

Existing and proven technologies such as JDO or Hibernate don't necessarily need an application server, either. In addition, these tools already dominate the managed persistence market.

Conclusion

J2EE is easy without an application server, and possible today. That being said, there are certainly applications that can't be implemented without an application server (yet): for instance, if you need general JCA (Java Connectivity API) functionality, then the platform we propose is not enough. However, this is likely to change since the benefits of not having to use an application server to develop, test, and deploy are simply too great. More and more, people are convinced that the future of J2EE is in a modularized "pick-what-you-need" architecture, as opposed to the monolithic application-server-based approach of today. In such a scenario, J2EE developers will finally be freed from the restrictive harness that the application server and EJB impose.

Resources

• The complete source code for this article
• Guy Pardon's presentation on Transactions in Spring published at TheServerSide
• More information on Atomikos Transactions and message-driven functionality without EJB
• The home page of Spring
• More information on JUnit
• FirstSQL is an easy-to-install, XA-compliant DBMS
• More information on HSQLDB
• More information on ActiveMQ

Guy Pardon is the chief architect at Atomikos, where he leads the development of both traditional and modern (web-service oriented) transaction technology.

Return to ONJava.com.