At the core of enterprise business computing are business services. The J2EE platform provides a scalable container-based model which hosts distributed, transactional, secure business code. The application developer is free from implementation details and platform dependence with these container services.

Applying the same design practice that decouples the business code from these distributed computing services, Arch4J separates business code from the container itself. The goal of this pattern is to provide the application developer with all the functionality of the J2EE environment without binding him to specific APIs.

• If you are installing as part of the full Arch4J distribution, you need to put the arch4j.jar file into your classpath.
• If you are only interested in the data access component, you need the base.jar, baseservices.jar and arch4j_ejb.jar in your classpath.
• You'll also need to install and configure an EJB compliant application server such as Jboss.

There is really very little code included for this component. It is for the most part a design pattern that we have had a good experience with in the past.

One constant truth in software development is that technology never stops changing. It is in a company's best interest to develop software in such a way as to protect it from, but still utilize, changing technology practices, patterns and APIs. A common pattern in many of the Arch4J components is to shield the application developer's implementation from the specifics of the environment his code runs in.

The pattern as defined in an EJB environment with an example Account service is as follows:

It looks like a lot of classes, right? The good news is that the application developer is really only responsible for coding the AccountService interface and the AccountServiceImpl implementation. The rest of the component specific classes, those outlines in green, can be created with a code generator. See Arch4J's Java Class Generator for more information on code generation.

SessionBean, EJBHome, and EJBObject are all defined by the EJB specification and must be implemented for each distributed component. Arch4J provides the BaseSessionBean class which has some of the code common to most EJBs. The AccountService class declares each distributed method to be supported by the EJB. The AccountServiceImpl contains the actual business logic code to define each method declared in AccountService. AccountBean and Account provide a connecting layer to the EJB classes without forcing direct dependence. AccountBean is simply a delegate class which forwards all calls to an instance of AccountServiceImpl. The AccountServiceProvider is a convenience class used by clients to get an Account remote object. It wraps the call to JNDI to get the AccountHome and the instantiation of the remote.

Take a look at the Arch4J's example project Lunch-o-Matic for example uses of this pattern.

This pattern is also useful for a project that may not want to introduce an EJB application server initially, but that does not want to limit itself from taking advantage of one in the future. As long as developers are careful to isolate business code into interfaces and implementation classes and not directly rely on services specific to the environment, they should have no trouble porting to an EJB environment.