Deploying WebLogic Platform Applications
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:
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.
Instructions about updating the
Instructions for modifying the
Instructions for modifying these EJBs in 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:
<App-dir>represents the root directory of the application.
<Web-project>represents the top-level directory of a Workshop project in the application.
<Domain-root>represents the root directory of the domain.
"Preparing and Deploying the EAR File" in the WebLogic Portal Production Operations User Guide at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/prodOps/deployment.html
For enabling session replication, see Enabling Session Replication.
Information is available on dev2dev in the WebLogic Workshop Internals document, in the topic "Application Customization," at the following URL: http://dev2dev.bea.com/products/wlworkshop81/articles/wlw_internals.jsp#65
Properties file that defines resources used by the WebLogic Workshop run-time framework, such as the data source used to persist conversational state and the JMS server used to buffer asynchronous service requests.
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.
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.
.workfile that represents the application. It appears at the root of the application directory.
resourcesdirectory in a Web project.
modulesdirectory. These files are stored at the root of your application in the file system.
APP-INF/libdirectory in the file system.
WEB-INFfolder in a Web project:
global.appfile in the
WEB-INFdirectory in a Web project, if you have page flows and JSP files in your project. These files end with the
WEB-INF/libdirectory in a Web project.
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.
META-INF (except the
<web-project>represents the top-level directory name for your application's WebLogic Workshop project in the domain directory; for example:
<schema-project>represents the top-level directory of the optional schema project, which contains your application's schema (XSD) files.
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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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:
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.
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:
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
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:
If access to the application in the target environment is to be restricted only to authenticated users, you need to specify either
CLIENT-CERT, as appropriate, in the
<login-config> element of the
web.xml deployment descriptor.
FORMto use form authentication, which requires a user to provide a valid username and password to use the application. The user must be a member of an appropriate role before the user can access the application.
CLIENT-CERTto use client certificate authentication, which requires the use of client certificates to enable access to the application.
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.
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.
* @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:
<user-data-constraint>element in the application's
web.xmldeployment descriptor, located in the
WEB-INFdirectory. For example:
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:
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.
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.
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:
wlw-manifest.xmlfile is produced and placed in the application's
wlw-manifest.xmlfile lists the server resources that must be created on the production server for the application EAR to run successfully.