Saturday, May 21, 2011

Java EE Application Directory Structure

I had a discussion with a colleague about what would be the best directory structure for a Java EE application. So what is the best structure?

While using Eclipse in the Java EE perspective you can create an Enterprise Application Project that contains a client module, an ejb module, a web module and a connector module. You can add additional projects that will be modules specific to some logical distinction in your application. So you might have a module for  calculations and another for accessing external services etc.

Both Logical and Organizational considerations come into play. Each EAR would contain all the pieces that are related for a particular capability. We can always assume that each EAR will be self contained and can be deployed on one or more containers. The typical approach that I have always followed is to have each EAR contain one or more jars and wars. Each war or jar contains some key component or set of related components. The EAR represents an Enterprise application that contains the components and web apps for the application. An Example is a Payment processing system I was involved in. The EAR contained everything required to run the Payment Processing system. This included half a dozen jars and 3 wars. Each jar represented some functionality or logical grouping of functionality. Each war represented a web app. An example of the jar's composition:

  • a jar for core functionality
  • a jar for ejbs
  • a jar for our advanced financial math pieces
  • a jar for our security pieces
  • etc.

Having multiple jars was dictated by the fact that different people developed different pieces so they worked in different Eclipse projects and combined them all as needed.

There are no hard and fast rules, just whatever works for your team and situation.

The official position from Oracle-Sun is

A Java EE application is delivered in an Enterprise Archive (EAR) file, a standard Java Archive (JAR) file with an .ear extension. Using EAR files and modules makes it possible to assemble a number of different Java EE applications using some of the same components. No extra coding is needed; it is only a matter of assembling (or packaging) various Java EE modules into Java EE EAR files.

An EAR file contains Java EE modules and deployment descriptors. A deployment descriptor is an XML document with an .xml extension that describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. At runtime, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly.

EAR File Structure

Diagram of EAR file structure. META-INF and web, application client, EJB, and resource adapter modules are under the assembly root.

There are two types of deployment descriptors: Java EE and runtime. A Java EE deployment descriptor is defined by a Java EE specification and can be used to configure deployment settings on any Java EE-compliant implementation. A runtime deployment descriptor is used to configure Java EE implementation-specific parameters. For example, the Sun Java System Application Server runtime deployment descriptor contains information such as the context root of a web application, the mapping of portable names of an application’s resources to the server’s resources, and Application Server implementation-specific parameters, such as caching directives. The Application Server runtime deployment descriptors are namedsun-moduleType.xml and are located in the same META-INF directory as the Java EE deployment descriptor.

A Java EE module consists of one or more Java EE components for the same container type and one component deployment descriptor of that type. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. A Java EE module without an application deployment descriptor can be deployed as a stand-alone module.

The four types of Java EE modules are as follows:

  • EJB modules, which contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.

  • Web modules, which contain servlet class files, JSP files, supporting class files, GIF and HTML files, and a web application deployment descriptor. Web modules are packaged as JAR files with a .war (Web ARchive) extension.

  • Application client modules, which contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension.

  • Resource adapter modules, which contain all Java interfaces, classes, native libraries, and other documentation, along with the resource adapter deployment descriptor. Together, these implement the Connector architecture (see J2EE Connector Architecture) for a particular EIS. Resource adapter modules are packaged as JAR files with an .rar (resource adapter archive) extension.