Application Deployment: Common Concepts

Beyond standard packaging, there are three distinct tasks before we can make a successful deployment:

  • We need to prepare the application server by setting up server-wide resources such as connection pools, which our applications rely on.

  • We need to write the required proprietary deployment descriptors for our target application server and include them for packaging with our application.

  • In some servers, we may need to perform additional steps to prepare a deployment unit for the target server, such as generating and compiling EJB home and component interface implementation classes.

Let's look at each task in turn.

Configuring a Server to Run the Application

Let's look at some of the most important server-wide configuration issues we're likely to encounter. These involve creating the services the application will rely on at runtime, and ensuring that any dependencies are satisfied.

Creating Connection Pools

In most J2EE applications, we'll need to perform RDBMS access. This means that we must configure a javax.sql.DataSource and ensure that it is bound in the server's global JNDI naming context. This usually involves creating a connection pool, the details of which will be server-specific, and defining a server-specific DataSource that exposes it. DataSource objects can be used by code running in either the EJB or web container.

Typical configuration parameters we will need to set when defining a connection pool are:

  • The JDBC driver class. This is normally a class supplied by the RDBMS vendor, such as oracle.jdbc.driver.OracleDriver.

  • The JDBC URL. The format will depend on the driver.

  • Username and password, assuming that the container, not the application, will perform authentication (the commonest option in J2EE applications).

  • The maximum size of the connection pool. This may have a significant effect on performance, as threads will block while waiting for connections if all connections are in use. However, an excessively large pool size may waste valuable database resources, especially if multiple J2EE servers access the same RDBMS server.

  • The initial size of the connection pool. Sometimes it's best to allocate several connections on startup, if we know that an application will make heavy use of the connection immediately on starting up.

  • Pool maintenance settings such as the time until inactive connections are closed.

We'll also need to ensure that the necessary database driver is available at application server (rather than application) level, as connection pools are independent of applications.

Creating JMS Destinations

JMS destinations are another example of server-wide resources. These are not limited to any single application. In fact, they can be used for inter-application communication.

In JBoss 3.0, the $JBOSS_HOME/deploy/jbossmq-destinations-service.xml file defines the default JMS topics and queues, setting their JNDI names. In Orion the same role is performed by the /config/jms.xml file.

Setting up Authentication

Different application servers have different approaches to authentication, but we will need to provide the application server some way of checking user credentials against a persistent store. This usually involves specifying a class, which may be provided by the application server or may be custom, which checks users and role information. Most application servers define a fairly simple interface such classes must implement. User information is usually held in an RDBMS.

In Orion, authentication can be configured at an application level, but in WebLogic and JBoss, it's server-wide.

Installing Libraries

We may wish to install binaries used by multiple applications at server level, rather than distribute them as part of each application. We can do this if necessary by modifying the command that invokes the application server by adding additional classpath elements, although it's more elegant to follow server conventions. In JBoss, we can simply copy the necessary .jar or .zip files to the /lib directory of the relevant server.

Note that when we install libraries at a server-wide level, it will be impossible to modify them without restarting the application server; the application server will be unable to load them in a dynamic classloader such as it may use for application code.

In general, it's better to keep applications self-sufficient, by shipping all required binaries within J2EE deployment units. However, the following are typical cases when we might choose a server-wide approach:

  • When the binaries in question relate to the server, rather than a specific application. Database drivers are in this category. They cannot usually be included in applications, as servers typically start connection pools before starting applications, and therefore need the drivers before loading applications.

  • For products such as JDO implementations that will be used by all applications, and which may require server-wide JNDI bindings.

  • When we need to replace or patch a server-side library, and Servlet 2.3 WAR-first class loading (discussed above) won't solve our problem. For example, JBoss 3.0.0 ships with Log4j. Including a later version of Log4j with an application will produce no effect, as the version loaded with the server's class loader will always take precedence. Thus the only way to update the version of Log4j would be to replace it at a server level.

Important 

Don't update or patch libraries used by an application server unless it's essential, as it risks affecting the behavior of the application server.

Occasionally it may be necessary to deploy some classes at server-wide level to avoid class loading problems between WAR and EJB deployments. However, as we've seen, this often reflects poor design of the classes in question, and is a last resort, rather than a positive choice.

Writing Proprietary Deployment Descriptors for an Application

In additional to server configuration, we will need to add proprietary information for inclusion in deployment units.

Proprietary deployment descriptors are required to provide additional information that fills gaps left by the standard deployment descriptors and to configure implementation-specific parameters. For example, proprietary deployment descriptors must be used to:

  • Tell the server where to find resources the standard deployment descriptors identify. For example, the standard deployment descriptors require declaration of the JNDI names used in application code to access resources such as DataSources, but don't specify how these should be mapped onto server-wide data sources created during server configuration.

  • Specify how stateless session EJB pooling should work. Stateless session bean pool size is an important configuration parameter, normally specified in proprietary deployment descriptors. However, as the implementation is vendor-specific, ejb-jar.xml rightly doesn't describe configuration parameters.

The structure of proprietary descriptors varies, but there's much commonality between their content. The settings I'll discuss below are common to all servers I've worked with.

Note 

Entity beans with CMP often require complex proprietary deployment descriptors, the format of which varies between application servers. As I don't advocate use of entity beans, I won't attempt to cover this here. If using CMP entity beans, please refer to documentation about proprietary descriptors for your application server. Plan to use tools to manage the complexity of such deployment descriptors; manual editing is not a viable option for the necessary ejb-jar.xml elements and proprietary descriptors.

EJB-Specific Configuration

Usually the most complex parameters relate to EJBs. We'll always need to provide mappings for the JNDI names declared in ejb-jar.xml. However, other settings may include:

  • Stateless session bean pooling options.

  • Replication options for stateful session beans.

  • Other cluster-related options, such as routing algorithm within a cluster.

  • In applications that use EJBs with remote interfaces, whether EJB invocations within the same JVM should be optimized to use call-by-reference. This is the default in most servers, and will greatly improve performance, but may cause unexpected results if the EJBs were coded with the expectation of call-by-value.

  • Transaction timeouts for CMTs.

  • Transaction isolation levels to be applied to methods using CMT. In some servers these can only be set for entity beans; in WebLogic, they can be set for any type of EJB.

Note that we don't always need to override the defaults, which may ensure appropriate behavior for most applications.

Web-Tier Configuration

Web-tier configuration is usually simpler than EJB-tier configuration, because the relevant container infrastructure is simpler, because there are fewer gaps in web.xml, and because using an MVC framework (such as Struts or the framework we discussed in Chapter 12) tends to move much of the configuration of web-tier components into framework-specific deployment descriptors.

Typically we'll need only to provide mappings for the JNDI names declared in resource references in web.xml. However, we may be able to set options such as the following (configurable in weblogic.xml):

  • JSP compilation options, such as which compiler to use, special command-line arguments, and whether all JSP pages should be precompiled when the application starts up

  • Session tracking options

  • How to store session data (to a flat file, RDBMS etc.)

  • Session replication configuration

Deploying an Application

The steps in deploying an application will vary between servers.

Web applications don't generally require any special steps besides making the WAR available to the server, as a web container merely needs to load the relevant servlet classes and make the necessary resources available through JNDI.

EJB deployments, however, may be more complex, as the EJB classes implemented as part of the application don't implement the bean's EJBObject and home interfaces. The server must provide implementations of these interfaces, invoking application classes to perform business logic.

Some servers use dynamic proxies to implement EJB component and home interfaces, wrapping application classes. However, many servers, such as WebLogic, require a compilation step, in which the container generates and compiles the necessary classes. The use of container-generated classes may produce marginally better performance by minimizing the need for reflection, although it's unlikely that any such gain will be significant in most applications. Until J2SE 1.3 introduced dynamic proxies, container-generated classes were the only available deployment strategy.

In WebLogic's case, the proprietary ejbc tool is used to generate container-specific classes and add them to the EJB JAR file before deployment to the server. WebLogic can automatically perform this step on deployment of a standard EJB JAR file, but it unnecessarily wastes server resources and may make it harder to track down deployment errors, by combining the operations of building the WebLogic-specific EJB JAR file and deploying it on a running server.

Important 

If a server-specific "compilation" step is required, use an Ant target to invoke it and ensure that it occurs before deployment.

Deployment Parameters for the Sample Application

Now we know enough to list the essential tasks required to configure any server to run our sample application and add the necessary deployment descriptors to our application. Only how we accomplish these tasks will differ between servers:

  • Create a server-wide DataSource for our Oracle database.

  • Create the server-wide JMS topic for reference data update messages.

  • Make the DataSource available to the BoxOffice EJB through a proprietary deployment descriptor.

  • Make the DataSource and JMS topic available to components running in the web container through a proprietary deployment descriptor.

  • Make the BoxOffice EJB available to code running in the web container.



Expert One-on-One J2EE Design and Development
Microsoft Office PowerPoint 2007 On Demand
ISBN: B0085SG5O4
EAN: 2147483647
Year: 2005
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net