Skip navigation.

eDocs Home > BEA WebLogic Platform 8.1 Documentation > Deploying WebLogic Platform Applications > Preparing the Application for Deployment

Deploying WebLogic Platform Applications

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Preparing the Application for Deployment

As the application moves through the promotion stages, application source and configuration files may need to be modified before the application can be deployed. Modifications are necessary if the new target environment is different from the previous one in the following ways:

This chapter explains specific changes that you may need to make, the circumstances in which you might need to make those changes, and how to make them. The following topics are included:

 

Summary of Application Preparation Tasks

Table 7-1 lists tasks that you may need to perform for application files depending on the characteristics of the application, on the target environment, or both, and provides links to topics that explain how to do those tasks.

Table 7-1 List of Application Preparation Tasks You Might Need to Perform 

Application or Target Environment Characteristics

Tasks You May Need to Perform

For more information, see . . .

Any post-development environment

Obtain application files.

Access to Application Files

Update application project files to point to the domain in the target environment on which the application runs.

Updating the Server Path Attribute

Update WebLogic Portal cache configuration, behavior tracking, campaign, and commerce tax settings.

Instructions about updating the application-config.xml file in Summary of Changes to Deployment Descriptors and Configuration Files

Tune the application for a production environment.

Instructions for modifying the <jsp-descriptor> element of the weblogic.xml deployment descriptor in Summary of Changes to Deployment Descriptors and Configuration Files.

Tune WebLogic Workshop dispatcher and container EJBs for a production environment.

Instructions for modifying these EJBs in Summary of Changes to Deployment Descriptors and Configuration Files.

The application is targeted to a cluster.

Enable session replication to maintain information about object state in the event of a server failure.

Enabling Session Replication

The application uses Web service controls to access other applications.

Update host, port, and optionally security protocol of target service specified in the Web service controls.

Enabling Inter-Application Communication

The application uses the Business Process Monitoring features of WebLogic Integration.

Set the concurrency strategy for stateful business process entity beans.

Specifying a Concurrency Strategy for Stateful Business Process Entity Beans

The application uses Application Integration features of WebLogic Integration.

Update the WebLogic Integration application views.

Reconfiguring Application Views

Specify Application Integration adapter target event generators.

Specifying Event Generator Targets

Secure access to the application is needed.

Restrict application access to authenticated users only.

Limiting Access to Authenticated Users

Restrict application access to SSL requests only.

Restricting Application Access to SSL Traffic Only


 

 

Summary of Changes to Deployment Descriptors and Configuration Files

Like any J2EE application, a WebLogic Platform application has a number of deployment descriptors that you might need to tune for your production environment. The production environment also has a number of properties files that you might need to modify as well. The following table identifies these files, summarizes the changes that may be needed, identifies how to make the changes and when they can take effect, and provides links to topics that provide more information. Each file described in the following table, and the directory in which it is located, is shown in bold in the first column. In this table:

 

Managing Application Files for Promotion to Production

This section contains the following topics, which make recommendations for managing application files for promotion to production:

Access to Application Files

The two primary mechanisms for providing access by an application administrator to application files include the following:

Two considerations for choosing a mechanism include:

One main advantage of using a version control system is that changes to application files can be tracked, and such a system is usually integrated with the WebLogic Workshop IDE. This integration provides a convenient means to rebuild application files. However, changes made to those files for the purposes of deploying into a target environment need to be tracked. In larger team environments, complications may arise if changes are made simultaneously by multiple team members.

However, when an application administrator is given an application EAR file, access to the build environment might not be available. If a change requires a rebuild of the application files, the application administrator might not be able to make the change, which could be a limitation. But when the method chosen for making file changes is to edit deployment descriptors directly, nothing more than access to the EAR file is needed. Deployment descriptors can be easily extracted, modified, and staged. In addition, handing off the EAR file to the application administrator might work better to control changes made to application source files. Moreover, it is usually easier to create scripts that work directly with EAR files. Depending on the policies that an IT team uses, the role of the application administrator, the promotion process, and the application, one mechanism might be more appropriate than the other.

Most of the changes described in this chapter are made to the deployment descriptors, which are automatically available in the EAR file, and not to application source files. So the issue of source file control, unless otherwise noted, is not a factor regarding this chapter's scope.

Using a Version Control System

It is highly recommended to use a source control tool for version control and maintain an archive of application files. WebLogic Workshop integrates directly with CVS, Perforce, and IBM Rational ClearCase. Once you have added the files in your WebLogic Workshop application to a repository managed by one of these source control products, you can check files in and out using commands available in WebLogic Workshop.

When developing an application in WebLogic Workshop, the files to add to source control are:

For more information about integrating a version control system with WebLogic Workshop projects, see "Integrating with Source Control Systems" in the WebLogic Workshop Help at the following URL:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/guide/devenv/conIntegratingWithSourceControlSystems.html

Files that Should Not Be Under Version Control

While it is important to use a source control tool, such as Perforce or CVS, there are files that should not be checked into the source tree managed by such a tool. These include files that need to be installed before building the application for production deployment. These include JAR and library files provided by WebLogic Workshop for WebLogic Portal and WebLogic Integration, and also include files such as NetUI tag libraries and Liquid Data Control files. These files are staged by WebLogic Workshop automatically when you enable the templates for the applications you create for those products.

In addition, you should not check in files that are automatically generated by WebLogic Workshop during development, which include the following:

.workshop directory
META-INF (except the application-config.xml file)
<web-project>/WEB-INF/*.tld
<web-project>/WEB-INF/*.tldx
<web-project>/WEB-INF/jpf-struts-config*.xml
<web-project>/WEB-INF/classes
<web-project>/WEB-INF/lib
<schema-project>/system/*.*
*.jar
*.war

In the preceding list:

Note: If a JAR file was generated in a different application and you add it as a library or a module to the current application, put it under source control. However, if you build the library in your application, do not put it under source control, and do not copy it into the production domain. Remember that JAR files added as a module in the Modules folder of WebLogic Workshop's Application pane are placed by WebLogic Workshop in the root folder of your application, while JARs added as a library in the Libraries folder of WebLogic Workshop are placed in the APP-INF/lib directory.

 

Enabling High Availability

When developing an application in WebLogic Workshop, you typically do not need to be concerned with several aspects of the production environment, such as:

The strength of WebLogic Workshop is that it allows you to focus on the business logic of your application, freeing you from having to write code that enables the portability, reliability, availability, and scalability features that typically are required for an enterprise-level application in a production environment. WebLogic Workshop does this, in part, by making a number of resources and capabilities available automatically, or in a very simplified way, in the development environment; for example, database access, client access, and communication with other applications.

When you move an application from development to production, however, you need to make a small number of modifications to application files to enable the application to access resources, and be accessible by clients, in a clustered environment. By making these simple modifications, you enable your application to fully leverage the high-availability and load-balancing capabilities provided by a clustered WebLogic domain environment.

There are three key areas where you typically need to make modifications so your application can function in a clustered production domain:

Enabling Inter-Application Communication

When building applications that must interoperate with distributed systems over a network, using Web service controls can be a powerful and convenient means to enable communication with back-end resources and other applications. In a development environment, applications can use direct access to invoke a Web service or Web application—for example, by specifying localhost:7001 as the service's host and port. However, in a production environment, those Web services typically are not available locally, or their locations may have changed, or they may be accessed only via a Web proxy server or a load balancer to servers in the target environment.

Therefore, one challenge of moving an application from the WebLogic Workshop development environment to a production environment is ensuring that Web service controls used in that application contain correctly updated URLs. The information presented in this section does not simply explain a procedural step for application deployment, but also provides important considerations for the proper design of the application.

The need to update URLs in Web service controls typically occurs in the following situations:

In either situation, the host and port specified in the Web service control is subject to change until the application is deployed in the production environment. This section shows an example Web service control URL, and describes four techniques you can use to update that URL.

Example Web Service Control URL

When you incorporate a Web service control in an application to invoke a Web service, WebLogic Workshop generates the host and port of the invoked Web service into a JCX file, and includes the host and port as part of the @jc:location annotation. The following example shows the @jc:location annotation for the Web service control generated during development. The host and port are shown in bold.

/**
 * @jc:location http?url="http://localhost:7001/processes/CSR.jpd"
 * @jc:wsdl file="#CSR_ProcessWsdl"
 */

Techniques for Updating URLs in Web Service Controls

Before you build the application EAR file for production deployment, the host and port in the @jc:location annotation must updated to specify the Web proxy server or load balancer of the production domain in which the target Web service is deployed, as in the following example. 

/**
  * @jc:location http?url="http://proxysvr2:9201/processes/CSR.jpd"
  * @jc:wsdl file="#CSR_ProcessWsdl"
  */

You can use the following techniques to update host and port information specified for Web service controls in your application:

Techniques 1 and 2 involve source-level changes to the application, so access to the build environment is required to make these changes, and the application must be rebuilt for the changes to take effect. Techniques 3 and 4 do not require source-level changes to application files at deployment time as the previous two techniques do, but they do reflect features that would need to have been designed into the application during development.

Regardless of which technique you use, the development team needs to provide a list of remote services that are used by the application so that production environment system administrator can update the corresponding service control files appropriately before doing the final production environment build and deployment.

Technique 1: Reimport the target Web service's WSDL file into your project

When you move your application into a production domain, you can reimport the target Web service's WSDL file into your project. This WSDL file needs to have been generated from the target Web services after they have been deployed in the production environment. This method ensures an accurate update of your application's Web service controls.

Technique 2: Manually update your application's @jc:location annotations

In WebLogic Workshop, you can manually update each @jc:location to specify the correct host and port for each target Web service. This method may be quickest and simplest, but this also requires a recompilation of your application in the IDE. Because you are doing the updates manually, there is the risk of errors.

Technique 3: Implement an invocation to the setEndPoint() method on the service control

Each service control has a setEndPoint() method that you can implement to force the control, at run time, to use URL endpoint information included in a properties file that you create. Considerations for using this technique include:

Technique 4: Implement a Service Broker control

The Service Broker control allows a business process to send requests to and receive callbacks from another business process, a Web service, or a remote Web service or business process. The Service Broker control is an extension of the Web service control, and it allows you to pass endpoint information to your application dynamically. For example, you can specify properties in the WebLogic Integration Administration Console. Implementing this method does not require a rebuild of the application.

Enabling Session Replication

WebLogic Server uses standards-based communication techniques and facilities to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine whether an object has stopped before finishing its job (because the machine on which the application is running has failed), and where there is a copy of the object to complete the job that was interrupted.

Information about what has been done on a job is called state. One technique used by WebLogic Server to maintain information about state is session replication. When a particular object unexpectedly stops doing its job, session replication enables a copy of the object to pick up where the failed object stopped, and finish the job.

Applications that are deployed in a WebLogic Platform domain should have session replication enabled. Without this setting, you will not have failover of a user's state information if a server in the cluster is stopped. To enable session replication across the cluster, configure the <session-param> descriptor element in the weblogic.xml deployment descriptor file for the application, as in the following example:

<session-descriptor>
        <session-param>
                <param-name>PersistentStoreType</param-name>
                <param-value>replicated_if_clustered</param-value>
        </session-param>
</session-descriptor>

Specifying a Concurrency Strategy for Stateful Business Process Entity Beans

Most database systems, such as Oracle, do not hold a lock after an insert operation. The first transaction of a business process always includes an insert operation. If a business process is intended to receive another message or callback before the first transaction completes, database concurrency may be insufficient. In this case, use exclusive concurrency. Note that the subsequent messages or callbacks must originate on the local server for this to work.

To enable exclusive concurrency, make sure that the <ejb-concurrency-strategy> element in the wlw-config.xml file is set to exclusive for stateful business process entity beans. For information about issues regarding specific databases, see the BEA WebLogic Integration Release Notes at the following URL:

http://download.oracle.com/docs/cd/E13214_01/wli/docs81/relnotes/index.html

For information about modifying the wlw-config.xml file, see "wlw-config.xml Configuration File" in the WebLogic Workshop Help at the following URL:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/reference/configfiles/con_wlw-config_xml_ConfigurationFile.html

 

Reconfiguring Application Views and Adapters

The aiConfigurator utility allows an administrator to modify environment-specific information across application view, adapter, and connection factory descriptors used with WebLogic Integration. This allows an administrator to preconfigure application integration resources to deploy correctly in a production system environment. Further tuning of these resources can then be performed using the WebLogic Integration Administration Console.

The following sections explain and provide examples of how you can use the aiConfigurator utility to reconfigure application views and target event generators:

Reconfiguring Application Views

If your application uses application views from WebLogic Integration as interfaces to services and events in an application enabled by one or more adapters, those applications views must be updated as appropriate for the configuration in the production environment. For example, if your application uses an application view with a DBMS adapter, the settings for the DBMS used in the production domain will be different from those in the development domain.

BEA provides the aiConfigurator utility to automate the reconfiguration of application views. For information about using the aiConfigurator utility, see "Administering Environment-Specific Application Integration Information" in Deploying WebLogic Integration Solutions at the following URL:

http://download.oracle.com/docs/cd/E13214_01/wli/docs81/deploy/config_appx.html

Specifying Event Generator Targets

When using an Application Integration adapter that supports multiple generator instances, such as the sample DBMS adapter, event generators can be distributed to each node in the cluster. This is done by specifying the Event Generation Targets using the -inboundMessagingTargets option to the aiConfigurator utility.

The target specification depends on whether the adapter has implemented event generator instance support. Considerations for implementing event generator support are described in "Developing an Event Adapter" in Developing Adapters at the following URL:

http://download.oracle.com/docs/cd/E13214_01/wli/docs81/devadapt/7devea.html

 

Preparing Application Security

The following sections explain changes that may need to be made to application files depending on the security requirements of the target environment:

Limiting Access to Authenticated Users

If access to the application in the target environment is to be restricted only to authenticated users, you need to specify either FORM or CLIENT-CERT, as appropriate, in the <login-config> element of the web.xml deployment descriptor.

The following example shows setting the <auth-method> subelement of the <login-config> element to CLIENT-CERT:

<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>

Restricting Application Access to SSL Traffic Only

If the security model for the target environment is to restrict the application to receive SSL requests only, regardless of whether the host server is configured to receive requests only on an SSL listening port, complete the following steps.

  1. Update Web Service controls for the invoking application

    2. Enabling Inter-Application Communication explains how to update Web service controls to specify the host and port of the Web proxy or load balancer that handles access to target Web services invoked by your application. If you want to restrict application access to SSL requests only, you need to update the same Web service controls to specify a secure transport in the Web service URLs.

    The following code snippet shows the secure transport that needs to be specified in the target Web service URL in a service control:

    /**
    * @jc:location http-url="https://proxysvr1:7002/webservice/Report.jws"
    * @jc:wsdl file="#ReportWsdl"
    */
    public interface ReportControl extends com.bea.control.ControlExtension, com.bea.control.ServiceControl

    This update can be made at the same time you modify the host and port in the target Web service URL, as explained in Techniques for Updating URLs in Web Service Controls.

    Note: The application also needs to have additional mechanisms implemented in its code in order to use one or two-way SSL; however, this is a development task, not deployment. For more information, see "WebLogic Workshop Security Overview" in the WebLogic Workshop Help at the following URL:

    http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/guide/security/navSecurity.html

  2. For an application to receive only requests delivered via SSL, specify CONFIDENTIAL in the <transport-guarantee> section of the <user-data-constraint> element in the application's web.xml deployment descriptor, located in the WEB-INF directory. For example:

    3. <security-constraint>
    <!-some other configs -->
    <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>

Warning: Domain-level security also needs to be set up properly; namely, the SSL listen port has to be configured. Corresponding changes to the invoking application are needed to enable the use of SSL. For an example of sending a client certificate, see "WebServiceA.jws Sample" in the WebLogic Workshop Help at the following URL:

Warning: http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/samplesrc/SamplesApp/WebServices/security/transport/clientCert/WebServiceA-jws.html

 

Packaging the Application

WebLogic Workshop produces J2EE enterprise applications for deployment in a production domain. In an archived format, these are typically EAR files. Note that you cannot deploy a Web application project alone; you can deploy a Web application project only as part of an entire application.

The following topics are included:

Updating the Server Path Attribute

When you move an application from one environment to another, which you do at each stage of promotion, the application EAR file must be rebuilt via the wlwBuild command. When an application's projects are moved to another environment, you must reset the server.path attribute of the application's .work file to point to the target environment's root domain directory.

The application's .work file is located in the root of the application directory.

In the following example, the server.path attribute is set to the domain platDomain:

<option name="server.path" value="../../../domains/platDomain"/>

For more information about the wlwBuild command, see "wlwBuild Command" in the WebLogic Workshop Help at the following URL:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/reference/commands/cmdWlwBuild.html

Generating the EAR File

You can generate an EAR file for a WebLogic Workshop application using either of the following methods:

The wlwBuild tool is somewhat more flexible because you can set flags to build a JAR file for a specific project, instead of building an EAR file for the entire application. In addition, the wlwBuild tool can be easily invoked from an Ant task that you can either autogenerate or create manually. For details, see "How Do I: Call wlwBuild.cmd from an Ant build.xml file?" in the WebLogic Workshop Help at the following URL:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/workshop/guide/deployment/howCallWLWBuildFromAnt.html

When building an application, note the following:

For more information about packaging applications for deployment, see the following topics:

 

Skip navigation bar  Back to Top Previous Next