Deploying WebLogic Platform Applications

Understanding the Target Environment

The application promotion process is influenced not only by the application's design, but also by the hardware and software characteristics of the target environment in which the application will run. These characteristics include the machines, the operating systems on those machines, the network, databases, clusters, load balancers, and more, that host or significantly interact with the application.

This chapter describes four different environments into which WebLogic Platform applications are deployed, gives considerations regarding how the characteristics of each environment influence how the domains for each environment need to be configured, and identifies how application files may need to be modified prior to deployment into each environment. Specific considerations regarding security, high availability, and database usage are also provided.

The following topics are included:

• Typical Deployment Environment
• Considerations for Configuring WebLogic Platform Domains
• WebLogic Platform Domain Examples

The information provided in this chapter is at a conceptual and summary level only. For a detailed reference of the targeting and deployment of system-level resources, services, and applications in a WebLogic Platform domain, see Deployment Targeting Reference.

 

---

Typical Deployment Environment

A basic deployment environment based on a WebLogic domain typically includes the components listed in the following table. This table also shows the graphical symbols that represent these components in the illustrations throughout this chapter.

Table 2-1 Components of a Basic Application Deployment Environment

Component	Description
Domain	The basic organizational unit in which the deployed resources are administered. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed, collectively, as one unit.
Machine	Hosts the WebLogic software, which is installed on the machine and on which WebLogic Server instances run, applications, database and RDBMS, and other software used in the environment.
Administration Server	One instance of WebLogic Server in each domain acts as an Administration Server, providing a central point for managing all server instances.
Managed Server	Hosts application components and resources in a domain. A machine may host multiple Managed Servers.
Node Manager	A Java program provided with WebLogic Server that enables you to start, stop, and monitor remote WebLogic Server instances. To enable these capabilities, you run an instance of Node Manager on each physical machine in your domain.
Cluster	Consists of multiple server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients as a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. Note: The Administration Server can never be a member of a cluster.
Database	Hosts application and system data. WebLogic Platform supports common RDBMS systems for databases, such as PointBase, Oracle, Microsoft SQL Server, DB2, and Sybase. Interaction with an RDBMS is enabled via WebLogic JDBC.
Load Balancer/Proxy	Distributes client connection requests, provides load balancing and failover across the cluster, and provides security by concealing the local area network addresses from external users. A load balancer/proxy can be implemented via one of the following ways: An instance of WebLogic Server with the HttpClusterServlet A Web server supported by WebLogic Platform that is configured with the WebLogic Server proxy plug-in A hardware load balancer

 

Figure 2-1 shows an example of a typical WebLogic Server domain with Managed Servers and a cluster.

Figure 2-1 Typical WebLogic Domain with Managed Servers and a Cluster

 

For detailed information about WebLogic Server domains, see "Overview of WebLogic Server Domains" in Configuring and Managing WebLogic Server at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/adminguide/overview_domain.html

The section that follows discusses some of the considerations of and requirements for configuring a WebLogic Platform domain.

 

---

Considerations for Configuring WebLogic Platform Domains

When configuring a domain for WebLogic Platform applications, and that domain has at least one cluster, you should take into account the following considerations:

• The domain configuration templates that you use to create domains, namely via the Configuration Wizard or the WebLogic Scripting Tool (WLST) Offline, dictate the structure of the servers that run in that domain. That is, all the servers in that domain are configured to contain the components specified in that template. For example, if you create a WebLogic Integration domain, every server in that domain is configured with WebLogic Integration resources and not with WebLogic Portal resources. Conversely, every server in a WebLogic Platform domain is configured with the resources required to run all the WebLogic Platform components.
• You should consider using at least one cluster in any domain that is configured for a production environment. Clusters provide the sort of high-availability, load balancing, and failover features that are usually necessary for a production application.
• A WebLogic Portal application, as well as the Administration Portal tools, is usually targeted to both the cluster and the Administration Server. This is necessary to enable a very powerful feature of WebLogic Portal, which is to dynamically propagate updates and other customizations to each server instance in the domain.
• A WebLogic Integration application is targeted to the cluster, and the WebLogic Integration Administration Console is targeted to the Administration Server.
• A domain may have no more than one WebLogic Integration cluster. That is, a WebLogic Integration application, and the system-level resources required for that application, can be targeted to no more than one cluster. (Note that this restriction complicates creating a multi-cluster domain that is configured to run a WebLogic Integration application on one cluster, and a WebLogic Portal application on another cluster, discussed in Multi-Cluster Platform Domain Example.)
• A WebLogic Platform domain requires a Relational Database Management System (RDBMS).
• An RDBMS is required for the WebLogic Workshop run-time framework, and also for system- and application-level WebLogic Portal and WebLogic Integration resources.
• A set of JDBC resources—including connection pools, data sources, and transactional data sources—is required by WebLogic Platform components for handling system-level RDBMS operations. These resources are explained in more detail in Considerations for Configuring and Targeting Resources.
• Each WebLogic Server instance in a WebLogic Platform domain is configured with a JMS server. A JMS server manages all the destinations, connection factories, message stores, keys, etc. required for both the application as well as system-level resources that use JMS.

In addition, each Web application project that you create in WebLogic Workshop that makes asynchronous requests to Web services, including for WebLogic Integration and WebLogic Portal, by default has an asynchronous queue and an asynchronous error queue for which you must create a pair of corresponding JMS queues on each target server on which the application is deployed. If the target domain is clustered, you must configure these queues as distributed queues. For more information, see Adding Application Resources Required by the WebLogic Workshop Runtime.

• A cluster should have a minimum of three Managed Servers for load balancing. In the event that one Managed Server fails, load balancing can continue between the two remaining Managed Servers.

 

---

WebLogic Platform Domain Examples

This section describes considerations for the configuration of WebLogic Platform applications in the following four example domain environments:

• Development Domain Example
• Single-Cluster Platform Domain Example
• Multi-Domain Example
• Multi-Cluster Platform Domain Example

The purpose of presenting these examples is two-fold:

To describe WebLogic Platform configurations that can be used as stages in the promotion process.
To introduce the scope of the deployment and configuration tasks that are described later in this document.

These examples are not meant to imply any limitations on the variety of configurations that are possible with WebLogic Platform. There are other configurations that work equally well; however, if you are new to WebLogic Platform, these examples are a useful starting place.

In the diagrams shown in these sections, the types of applications running on a machine imply the minimum set of WebLogic Platform products installed on that machine. For example, a machine hosting a WebLogic Portal application must have WebLogic Portal, WebLogic Workshop, and WebLogic Server installed. However, the types of applications running on a given machine do not imply that only those products are installed. For example, it is possible that a WebLogic Portal application can run on a machine on which all WebLogic Platform products, including WebLogic Integration, are installed.

Development Domain Example

A typical development environment for using WebLogic Workshop consists of a single-server domain as shown in the following figure.

Figure 2-2 Single-Server Development Domain Example

 

Components Shown in Example

The development environment shown in Figure 2-2 has the following characteristics:

• The entire domain, including the database, is located on one machine.
• The RDBMS, which manages the database required by system-level components of WebLogic Platform, may be the default single-user PointBase RDBMS. Or, it can be any production-capable RDBMS supported by WebLogic Platform. Note that it is a best practice to use the same RDBMS in development that will be used in the production system; however, this is not a requirement. WebLogic Platform provides scripts that simplify switching from one database and RDBMS to another, which include extracting the database schemas from one database and inserting them into another.
• The domain in this example includes a single server that hosts the single WebLogic Platform application, shown as PlatApp, in this figure. As defined in About WebLogic Platform Applications, a WebLogic Platform application incorporates all components of WebLogic Platform.
• The server also hosts all the administration components of WebLogic Platform, which are the following:
• The WebLogic Server domain administration components, represented as WLS Console
• WebLogic Portal system-level Web applications and EJBs, represented as Portal Console. These components include the WebLogic Administration Portal and the datasync Web application.
• WebLogic Integration Administration Console and other administrative components, represented as WLI Console. These components include EJBs and Web applications, startup and shutdown classes, and configuration queues and topics.
• WebLogic Platform domain JMS and JDBC resources.

Considerations for this Configuration

This is a basic WebLogic Platform domain configuration and is typically used for application development. Server administration is simplified, and all application-level and system-level resources are automatically configured and located on the one server. Considerations for using this configuration for development include the following:

• This domain is created with the Configuration Wizard using the Express mode, which is the easiest and quickest way to create a domain and is ideal for a development environment. Express mode uses the default settings from the configuration template. Keep in mind that in this mode you cannot modify template settings (for example, server port numbers) while you are creating your domain.
• The server in this domain is configured with all the resources necessary to run any kind of application supported in WebLogic Platform; that is, WebLogic Server, WebLogic Workshop, WebLogic Integration, and WebLogic Portal.
• This domain is configured to run in development mode, which is different from production mode in the following ways:
• The use of demo security certificates is enabled
• WebLogic Server instances automatically deploy and update applications
• A limited number of system-level resources are made available by default

For more information about how resources are configured in a domain created in development mode, see "Differences Between Configuration Startup Modes" in "Creating a New WebLogic Domain" in Creating WebLogic Configurations Using the Configuration Wizard at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs81/confgwiz/newdom.html

• All security data is stored in the WebLogic embedded LDAP server. Access to the domain is trusted by default.
• This configuration is not recommended for a production environment. Because all system and application components are on a single machine, if the machine fails, the entire system fails.

Single-Cluster Platform Domain Example

A single-cluster WebLogic Platform domain environment is shown in the following figure.

Figure 2-3 Single-Cluster Platform Domain Example

 

Components Shown in Example

The production environment shown in Figure 2-3 has the following characteristics:

• The domain in this configuration is based on the Basic WebLogic Platform Domain template.
• This domain has a single cluster, which is composed of four Managed Servers:
• Two Managed servers are assigned to one machine, and two are assigned to a second machine.
• Each machine in the cluster has WebLogic Platform installed. Each machine is also configured with a Node Manager.
• Each managed server instance hosts three applications:
• A WebLogic Portal application, represented as PortApp
• A WebLogic Integration application, represented as IntApp
• A WebLogic Platform application, represented as PlatApp.

Each of these applications is deployed as an EAR file; that is, each is a discrete deployment unit.

• Each managed server instance also hosts the WebLogic Administration Portal, WebLogic Portal administration tools, and the datasync Web application. The collection of these system-level resources is represented as Portal Console.
• The Administration Server is assigned to a third machine, and hosts the following:
• WebLogic Server domain administration infrastructure, which includes the WebLogic Server Administration Console, represented as WLS Console.
• The WebLogic Administration Portal, WebLogic Portal administration tools, and the datasync Web application, represented as Portal Console.
• WebLogic Integration Administration Console, and other WebLogic Integration administrative EJBs and Web applications, startup and shutdown classes, and configuration queues and topics, represented as WLI Console.
• The WebLogic Portal application is also typically deployed on the Administration Server, represented as PortApp, but is used for the purposes of propagating WebLogic Portal data throughout the domain, and not for handling client requests.
• A load balancer/proxy server routes client requests to an available server in the cluster. Using this component is a requirement for handling client requests to applications that are deployed on a cluster, but it also implements important practices for a production system:
• Applications on the cluster are accessed externally by the IP address of the machine on which the load balancer/proxy is hosted. Therefore, client applications never directly address the specific machine on which the application is hosted, which is very desirable from a security standpoint.
• You can use the load balancer/proxy to prevent external access to the Administration Server, which provides increased security.
• A load balancer/proxy allows you to have in-memory replication of client session information, which is very desirable from an availability standpoint. In the event of the failure of a machine on which a server is hosted, the client session can be reestablished with another running server instance.
• You can add Managed Servers to the cluster without affecting how clients access the applications hosted on those servers.
• The RDBMS is hosted on a standalone machine.

Considerations for this Configuration

By incorporating multiple machines and servers into a domain, it becomes possible to enable the sort of availability and reliability capabilities in WebLogic Platform that are necessary in a production system. For example, by configuring a cluster, multiple servers can perform similar functions. Any server in the cluster can process a request from a particular client. In addition, a cluster automatically provides load balancing across servers.

Note the following considerations about this configuration:

• This domain can be created using either the Configuration Wizard or the WebLogic Scripting Tool (WLST) Offline. When you create a domain similar to the one in this example, you cannot use Express mode in the Configuration Wizard; instead, you need to use Custom mode so that you can configure the cluster and other resources required for this configuration.

An example of creating a single-cluster production domain using WLST Offline is provided in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline.

• This single-domain configuration is simplest for a WebLogic Platform application in a production environment. Controls can be leveraged in WebLogic Workshop to simplify application development and intra-application requests and responses. Having portals, business processes, etc. in the same EAR file simplifies deployment. In addition, several individual components of WebLogic Platform include sample applications that demonstrate best practices of design and development for single-cluster environments.

However, this configuration requires targeting of individual application modules so that the WebLogic Integration Web application and EJBs are targeted only to the cluster, and WebLogic Portal EJBs and Administration Portal are targeted to both the Administration Server and cluster.

For information about targeting considerations of application modules in a WebLogic Platform application, see Application Targets.

• The Administration Server should not handle client application requests. Therefore, in general, applications should only be targeted to the cluster. This way, the Administration Server is never exposed externally to clients of the applications deployed in the domain. One exception to this is WebLogic Portal applications, discussed next.

Also, note that the Administration Server must be running at all times to support WebLogic Platform applications.

• WebLogic Portal applications are deployed on the Administration Server as well as the cluster so that customizations and other dynamic updates to the portal application can be propagated to all deployed instances of the application throughout the domain. However, only those instances of the application that are deployed on the cluster can be accessed by external clients, which is done via the load balancer/proxy.

The files in a WebLogic Portal application include several system-level EJBs, JAR files, Web applications, and Web services, such as the following:

• WebLogic Administration Portal
• Datasync Web application
• Content management
• Personalization
• Pipeline services or commerce services, if installed

These components are copied automatically into the application project directory tree by the WebLogic Workshop IDE when you create the application. You typically deploy the EAR file on all servers in a domain; however, it is possible to target only the WebLogic Portal application to the cluster, and the Administration Portal and other administrative components only on the Administration Server.

• As noted in Considerations for Configuring WebLogic Platform Domains, each Web application project that you create in WebLogic Workshop that makes asynchronous requests to Web services has an asynchronous queue and an asynchronous error queue for which you must create a pair of corresponding distributed JMS queues on the cluster. The names of these queues are identified in the wlw-manifest.xml file that WebLogic Workshop provides with each EAR file. For information about creating these distributed queues, see Adding Application Resources Required by the WebLogic Workshop Runtime.
• In a production environment, the domain should be configured with a database managed by an enterprise-level RDBMS supported by WebLogic Platform. This database is not located any machine on which WebLogic Platform, or any of its components, is installed.

There are a number of steps you need to take to configure the database for the target environment, including:

• Creating and preparing the database
• Promoting WebLogic Integration and WebLogic Portal database schema

Configuring the database is discussed in Configuring the Production Database. This chapter includes an example of using WLST to load WebLogic Portal and WebLogic Integration database schema.

• Security considerations include the following:
• In a production environment, insulate the domain infrastructure from potential attacks by always locating the Administration Server on a separate machine from those that host Managed Servers, and do not include the Administration Server in any cluster. As stated previously, do not target applications on the Administration Server (with the exception of WebLogic Portal applications, as noted).
• By default, user and group information is stored in the embedded LDAP server, which is fully adequate for development, system integration, testing, and other pre-production domain environments. The WebLogic Security Service makes it easy to export security information, such as policies set on domain resources, including applications, and the configuration of security providers, from one deployment environment and import it into another. For more information, see Promoting Embedded LDAP Security Data to the Target Database.

However, in a production environment within an enterprise, user and group information is typically stored in the LDAP server used by the enterprise. Therefore, a key step in promoting an application into a production environment is configuring security providers with that external LDAP server. For information about using an external LDAP server, see Using an External Store for User Information in Security in WebLogic Platform 8.1.

• During domain creation, there is dynamic table creation for WebLogic Server subsystems, such as JMS when JMS is configured to use a JDBC store. Administrators need the appropriate access granted to the database so that they can update the tables as necessary. Therefore, when configuring the domain, make sure that the appropriate database access is granted.
• Note that WebLogic Platform supports the use of multiple authentication providers. For information about configuring multiple authentication providers with WebLogic Server, see Configuring Security Providers in Managing WebLogic Security. For information about managing multiple authentication providers in the WebLogic Administration Portal, see Using Multiple Authentication Providers with WebLogic Portal. For information about using multiple authentication providers in WebLogic Portal application development, see Using Multiple Authentication Providers in Portal Development.
• When configuring a production domain, you might want to configure each Managed Server for SSL so that only SSL-based requests are received by the applications deployed on those servers. However, depending on your environment, it might be preferable to enable SSL in the load balancer, or to enable SSL at the application level and not for the entire Managed Server, to save on the overhead of enabling SSL by default for the entire server.

For information about how to modify your applications' deployment descriptors so that they receive SSL-based requests only, or allow only authenticated users to have access, see Preparing Application Security.

• The use of a load balancer/proxy introduces considerations for session replication. For information about configuring a load balancer/proxy, see Using Load Balancers and Web Proxy Servers.

If you are promoting an application from a nonclustered to a clustered environment, there are considerations for accessing other applications. Instead of accessing other applications directly, clients must access it via a load balancer/proxy. Enabling Inter-Application Communication explains how to modify application files so that access via a load balancer is enabled.

Multi-Domain Example

A loosely coupled, multi-domain production environment is shown in the following figure.

Figure 2-4 Multi-Domain Example

 

Components Shown in Example

The production system shown in Figure 2-4 is characterized by the following:

• A WebLogic Portal domain is created based on the Basic WebLogic Portal Domain template. This domain contains:
• A cluster hosted on two machines
• Each machine in the cluster hosts two Managed Servers
• Each Managed Server hosts one WebLogic Portal application
• An Administration Server, which hosts the WebLogic Portal application, the Administration Portal, the datasync Web application, and WebLogic Portal system EJBs and Web services.

Note that each Managed Server, as well as the Administration Server, can host multiple WebLogic Portal applications. The Administration Server is not constrained to host only one WebLogic Portal application.

• A WebLogic Integration domain is created based on the Basic WebLogic Integration Domain template. This domain contains:
• A cluster hosted on two machines.
• Each machine in the cluster hosts two Managed Servers.
• Each Managed Server hosts one WebLogic Integration application.
• An Administration Server, which hosts the WebLogic Integration administrative Web application, WebLogic Integration system EJBs, and other system components.
• Each cluster has a load balancer/proxy for handling requests.
• A database is shared by both domains.

Considerations for this Configuration

The considerations for this multi-domain production system include the following:

• This configuration is appropriate when the WebLogic Portal domain is used as the access point to the applications and resources in the WebLogic Integration domain. This loosely coupled configuration allows individual applications to be scaled as needed:
• A portal can be scaled broadly, independently of the WebLogic Integration application usage requirements. For example, the optimum performance might be achieved via scaling up a number of small machines on which it is deployed.
• WebLogic Integration application might require fewer, but more powerful machines.

An example of creating this domain using WLST Offline is provided in Example: How to Configure a Multi-Domain Environment Using WLST Offline.

An example of creating this domain using the Configuration Wizard in silent mode is provided in Example: How to Configure a Multi-Domain Environment Using the Configuration Wizard in Silent Mode.

• This configuration separates the application types more distinctly, resulting in simplified development, configuration, and deployment tasks. However, because the applications are deployed in separate domains, this configuration results in more complex interactions between the WebLogic Portal and WebLogic Integration components: for example, a JPD Proxy or Web service interface for invoking business processes must be used.
• The security considerations described for the single-cluster example in Considerations for this Configuration also apply to the multi-domain example. In a production environment, both domains should be configured with the user information in a central LDAP server. However, if user information is maintained in the embedded LDAP server in one of the domains, identity propagation and credential passing between the domains is more complex.
• Sharing a single database is not problematic because WebLogic Portal and WebLogic Integration do not share database schema.
• For interdomain communication, note the following considerations:
• Trust should be enabled for RMI traffic between the two domains.
• Consider enabling two-way SSL if your applications use Web services.
• Use JMS for asynchronous communication, such as via a Messaging Bridge or Foreign JMS Server.
• Domain configuration and application deployment is simplified, but each domain must be managed separately.

Multi-Cluster Platform Domain Example

It is possible to create a multi-cluster domain in which WebLogic Integration and WebLogic Portal applications are deployed on separate clusters in the same domain. This configuration is shown in the following figure.

Figure 2-5 Multi-Cluster Platform Domain Example

 

Components Shown in Example

The production system shown in Figure 2-5 is characterized by the following:

• Two clusters configured in the domain: one that has a WebLogic Integration application targeted to it, the other that has a WebLogic Portal application targeted to it.
• Each cluster comprises two machines. Each machine is configured with a Node Manager.
• Each machine in a cluster hosts two Managed Servers.
• Each Managed Server in each cluster hosts one application.
• The domain shown in this example is a custom WebLogic Platform domain. Because of the restriction that limits a domain to having one and only one WebLogic Integration cluster, not all the Managed Servers in this domain are the same: the servers in the portal cluster are not configured with the resources necessary to run WebLogic Integration applications.
• This domain has a machine hosting the Administration Server. The Administration Server has the following targets:
• WebLogic Server domain administration infrastructure.
• The WebLogic Portal application, the Administration Portal, the datasync Web application, and WebLogic Portal system EJBs and Web services.
• WebLogic Integration administrative EJBs and Web applications, startup and shutdown classes, and configuration queues and topics.

Configuration Considerations

Considerations for configuring a multi-cluster domain include the following:

• As with Multi-Domain Example, separating the WebLogic Integration cluster from the WebLogic Portal cluster allows each application to be scaled independently.
• A single domain configuration allows:
• Centralized management of applications and resources
• Simplified messaging between applications; this does not require a Messaging Bridge or Foreign JMS Server, as with Multi-Domain Example.
• The advantages of this configuration include:
• You can consolidate the WebLogic Portal application cluster, enabling you to scale it independently from the WebLogic Integration application. This allows you to improve load balancing and reliability because one application continues to work if the other application becomes unavailable or intermittently available.
• The machines hosting the Managed Servers do not require as much memory because the footprint of the application, and the WebLogic Platform resources that support it, is smaller. This allows you to more finely tune the functions each server is performing.
• Creating a multi-cluster domain that includes a WebLogic Integration application is complex, but it can be created in multiple ways. Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline provides an example of creating this configuration. Some of the steps can be automated via WLST Offline, but some steps need to be performed manually. The following summarizes the steps used in this example:
Using WLST Offline, the domain is created using the Basic WebLogic Platform Domain template.
Two clusters are configured: one for WebLogic Integration and the other for WebLogic Portal.
Four machines are configured: two are assigned to the WebLogic Integration cluster, and two to the WebLogic Portal cluster.
The JMS JDBC store is configured for the WebLogic Portal cluster.
The targets for the system resources and WebLogic services for each cluster are manually reassigned: WebLogic Portal resources are unassigned from the WebLogic Integration cluster, and WebLogic Integration resources are unassigned from the WebLogic Portal cluster.
The targets for the applications are corrected. First, all applications are unassigned from the Adminstration Server, the first Managed Server assigned in the WebLogic Integration cluster, and both clusters. Next, each application is assigned to its correct targets.
The domain config.xml file is modified manually to create JMS resources for the WebLogic Portal cluster.
• As with the preceding single-domain and multi-domain configuration examples, you need to create resources based on the content of the wlw-manifest.xml file. But you need to distinguish between the resources that must be created on each cluster.
• This configuration requires a load balancer/proxy for each cluster.
• The security considerations described for the previous two configuration examples apply to the multi-cluster configuration. User information can be stored in the embedded LDAP server or in an external LDAP server. Both clusters can use the domain security configuration easily.
• Communication between the clusters is implemented via messaging; for example, a JMS reliable transport, MQ Series when you need a Messaging Bridge, or calls from a control. This configuration requires precise targeting of applications and also of system-level JMS and JDBC resources. Consider enabling two-way SSL if your applications use Web services.