J2EE Application Overview

In J2EE and in Orion, the Application concept is very central, and this document describes what it is and what this means.

1 Introduction

    This is the main documentation index for the Orion Application Server. It mostly contains links to other documents but it also contains some documentation itself. It is organized in different sections ordered somewhat "cronologically" starting with installing Orion and then proceeding to configuration, development and deployment:

2 J2EE Applications

    Java 2 Enterprise Edition introduces the concept of J2EE applications. A J2EE application contains J2EE modules, which could be web applications, EJBs and application clients. It also contains meta-information about the application as well as shared libraries. You can also say that a J2EE application is a set of J2EE modules with some added glue that binds them together into a complete integrated application. The shape of a J2EE application is a single Java Archive file with the .ear filename extension. However, Orion also supports keeping these archives unpacked into a directory to make it easier to perform updates.

    To learn more about J2EE applications, The J2EE specification is actually pretty good reading.

    2.1 Why J2EE applications matter

      Possibly, the benefits of the J2EE applications are already apparent, but some people will also claim that they just add extra bloat and complexity. We feel however that they are of great importance.

      The J2EE specification states that the main goals of the J2EE application concept is "to provide scalable modular application assembly and portable deployment of J2EE applications into any J2EE product". What this means is that there are basically two goals, compatibility and making it easy to distribute prefabricated J2EE applications.

    2.2 Compability

      J2EE applications are said to be binary compatible. The binary code can be used in any J2EE environment and the procedure for deploying a J2EE application should be similar and simple across different implementation of the J2EE platform. This means that it is very easy to test that your application is really compatible with different platforms. It also means that the whole J2EE industry will be pressured to achieve higher compatibility, since users can easily just plug an existing application into another J2EE implementation from the one that it was built with. Any compatibility problems will become very visible.

    2.3 Distribution

      Before J2EE, distributing a complete enterprise application including EJBs, servlets, JSPs, stand-alone clients, etc. was usual difficult and problematic. There were a few different ways to do this but none of them was really tempting. You could either just zip it all up and write a text saying how to deploy it in a certain environment or just zip it up, explain your pieces and hope that the person taking care of the installation knew how to deploy the different pieces in their environment. You could also write an installer setting it up with a specific environment. With J2EE, it is not specified exactly how all pieces fit together and how they can be distributed in one single archive.

3 J2EE Roles

    J2EE has seperated the different roles of producing a complete application

    3.1 The Application Assembler Role

      The Application Assembler is the person who takes a set of J2EE modules and assembles them into a complete J2EE application, packaged as an Enterprise Archive. To help them Orion provides graphical assembly tools, and you can also use tools from a third party J2EE tool vendor. Of course they don't have to use the GUI tools and the application assembler should still know how the internals work and be able to assemble an application by-hand using a text editor and the deployment descriptors. They are also responsible for providing instructions describing external dependencies of the application, making it possible for the Deployer to install the application into the production environment.

      The Application Assembler is responsible for setting the J2EE deployment descriptors.

    3.2 The Deployer Role

      The Deployer will take the packaged application and install it into the production environment. They are usually an expert in a specific production environment, like Orion. Their job consists of three tasks:

      Installation: Putting the Enterprise Archive on the server and make it available to Orion.

      Configuration: Resolving all the external dependencies of the application. The Deployer needs to configure the environment specific parts. For example the Deployer will often need to set up the user management for the application, mapping the security roles defined by the Application Assembler to the user groups and accounts that exist in the environment into which the application components are deployed. The Deployer may also want to configure how Container Managed Persistence beans will be mapped to a data store (although this is usually done automatically), how the finder methods are implemented, where on the web site he wants the web applications to show up and set the correct JNDI properties and manifest for the application clients. The Management Console can be used to assist this process.

      Execution: Starting up the newly installed and configured application

      The Application Deployer is responsible for setting the Orion deployment descriptors

      Of course a deployed archive with valid Orion deployment descriptors can be shipped as an .ear to customers if you know that they will be using Orion, so you can perform the deployer's task as a developer.

4 Application Development LifeCycle

    The J2EE application model, with its different roles, is very suitable for a software production line with distinctly defined phases.

    Of course this is not a lifecycle your development will always follow, and you will probably want to iterate over this cycle a few times over the course of a large project. In theory however, this should be the lifecycle of your implementation (analysis, requirements specifcation and other phases are disregarded in this model, we are only concerned with the implementation phase).

    4.1 Component Creation

      First of all, the component provider creates components, like EJBs, JSP:s and Servlets.

      Tools available for this phase: EJB Maker (ejbmaker.jar)

    4.2 Component Packaging

      When the components have been developed they are packaged into J2EE modules (EJB jars, web-applications, etc.).

      Tools for this phase: EJB Assembler (ejbassembler.jar), Web-application Assembler (webappassembler.jar), Taglib Assembler (taglibassembler.jar), Application-clientassembler (clientassembler.jar).

    4.3 Application Assembly

      This is where the application assembler enters the picture. We discussed their role before, and as we said there, they areprovided with complete J2EE modules that they will combine into one J2EE application. They do this following certain steps:

        Select which J2EE modules will be used for the application Create the directory structure for the application.

        Place the modules in their correct places in the application structure

        Edit J2EE module deployment parameters Create the application deployment descriptor

        Create documentation intended for application deployers

        Package the application.

      Tool for this phase: The application assembly tool (earassembler.jar).

    4.4 Application Deployment

      When the application is assembled it is ready to be deployed in a J2EE application server. The tasks done in this phase by the Deployer were described in the section about the Deployer role.

      Tool for this phase: The management console (orionconsole.jar, orion.jar -console).

Copyright © 2005 IronFlare AB