Deployment Guide
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This topic describes the tasks involved in deploying BEA Liquid Data for WebLogic in a production environment. It includes the following sections:
When you are deploying Liquid Data to a new domain understanding your deployment requirements and needs are a critical first step in the process of deploying Liquid Data in a production environment.
When planning a deployment, consider the following issues:
Which types of queries (stored or ad hoc queries) will they run? How frequently will users be running different types of queries? Which queries will be run more frequently or less frequently than others? What are the anticipated peak loads for processing concurrent query requests?
Clarifying the specific requirements for your deployment provides the knowledge you will need to design your deployment.
Liquid Data components are contained in the LDS.ear
file.
These components can be deployed from the Liquid Data node of the WebLogic Administration Console. Table 2-1 lists the deployable Liquid Data components.
EJB that contains all query-related classes, including the Query Processor and stateless session bean. For more information, see the Liquid Data Javadoc. |
For a multi-node and clustered deployment, deploy to each Managed Server. |
|
EJB for Data View Builder to obtain configuration information from the Liquid Data server. |
For a multi-node and clustered deployment, deploy to each Managed Server. |
|
For a multi-node and clustered deployment, deploy to each Managed Server. |
||
Liquid Data configuration tabs that appear in the WebLogic Server Administration Console. |
||
EJB that manages results caching for stored queries that are configured for results caching. For more information, see Configuring the Query Results Cache in the Administration Guide. |
For a multi-node and clustered deployment, deploy to each Managed Server. |
|
Listener application that listens to notifications from the MBean for changes to the global cache status (enabled or disabled), changes to a stored query that is cached, and changes to the cache policy for a stored query. |
For a multi-node and clustered deployment, deploy to each Managed Server. |
For details on using the Administration Console to deploy Liquid Data components see Deploying Liquid Data Components in the Administration Guide.
This topic describes how to design a Liquid Data deployment for the following types of domains:
The deployment architecture that you use depends on the requirements for your particular production environment, as described in Defining Deployment Requirements.
The following sections describe single domain deployments:
In a single server (standalone) deployment, the Liquid Data software is installed on a standalone WebLogic Server. This design is the simplest to set up and it is the one suggested for use in a development environment or in a production environment in which Liquid Data is the primary application and failover protection is not the top priority.
The following illustration shows Liquid Data and WebLogic Server deployed on a single server:
Figure 2-2 Liquid Data and WebLogic Platform Deployed on a Single Server
A multi-node deployment distributes Liquid Data and WebLogic Platform software components across multiple server machines. A multi-node deployment allows you to run the various software components on dedicated servers, distributing resource contention across machines and optimizing system performance.
In each multi-node WebLogic Server domain, one WebLogic Server instance acts as the Administration Server—the server instance that configures, manages, and monitors all other server instances and resources in the domain. In a multi-node deployment, the Administration Server has administrative control over the domain and hosts the server repository. All other servers in the domain are configured as Managed Servers—servers that are managed by the Administration Server.
The following illustration shows Liquid Data deployed in a sample multi-node domain with three dedicated servers, one each for Liquid Data, WebLogic Portal, and WebLogic Workshop:
Figure 2-3 Liquid Data Deployed in a Multi-Node Domain
A clustered deployment distributes Liquid Data and WebLogic Platform software components across multiple server machines. A cluster is a group of servers that work together to provide an application platform that is more powerful and reliable than a single server. A cluster appears to its clients as a single server but it is, in fact, a group of servers acting as one. In contrast to a multi-node deployment (in which Liquid Data and WebLogic Platform software components are installed separately on dedicated machines), in a clustered deployment, all Liquid Data and WebLogic Platform software components are installed on every machine.
A Liquid Data cluster is a deployment in which multiple copies of Liquid Data, referred to as instances, run simultaneously and work together to provide increased scalability and reliability. A Liquid Data cluster appears to clients to be a single Liquid Data instance. The server instances that constitute a cluster can run on the same machine, or can be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server. For additional information about clustering, see Using WebLogic Server Clusters in the WebLogic Server documentation.
In each WebLogic Server domain, one WebLogic Server instance acts as the Administration Server—the server instance that configures, manages, and monitors all other server instances and resources in the domain. In a clustered deployment, the Administration Server has administrative control over the domain and hosts the server repository. All other servers in the domain are configured as Managed Servers—servers that are managed by the Administration Server. In a single instance deployment, the sole WebLogic Server instance is the Administration Server by default.
Note: In general, avoid configuring the Administration Server as part of the cluster.
In a clustered deployment, you select the algorithm to use for load balancing (round robin, weight-based, or random). Once configured, the load balancing mechanism directs incoming XQuery query requests to available Liquid Data server instances. For more information, see Load Balancing in a Cluster in Using WebLogic Server Clusters in the WebLogic Server documentation.
In a clustered Liquid Data deployment, if a server fails, the WebLogic cluster can redirect request processing to another Liquid Data server instance in the cluster. For more information, see "Replication and Failover for EJBs and RMIs" in Failover and Replication in a Cluster in Using WebLogic Server Clusters in the WebLogic Server documentation.
The following illustration shows Liquid Data deployed in a clustered domain.
Figure 2-4 Liquid Data Deployed in a Clustered Domain
This design is suggested for a deployment environment in which:
Before proceeding to deploy Liquid Data in a cluster, you should determine whether running Liquid Data on a dedicated server machine, as configured in Multi-Node Deployments, meets the performance and availability requirements for your deployment. Using the single server as a baseline, you can monitor run-time performance, conduct capacity planning, and test to determine whether a single machine provides sufficient performance at high query request loads.
In a multi-domain deployment, Liquid Data and the WebLogic Platform component are installed on separate WebLogic domains.
![]() ![]() |
![]() |
![]() |