Skip navigation.
Downloads | Product Documentation | Support

Deployment Guide

# Planning a Liquid Data Deployment

This topic describes the tasks involved in deploying BEA Liquid Data for WebLogic in a production environment. It includes the following sections:

- Defining Deployment Requirements
- Designing Deployments

# Defining Deployment Requirements

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:

- Business requirements. Identify and prioritize business requirements in a production environment, such as:

- system performance required at anticipated peak loads
- high availability and failover requirements
- security and data access requirements

- Resources to be deployed. Identify the components of the BEA WebLogic Platform to use.

At a minimum, BEA WebLogic Server and Liquid Data need to be deployed on at least one server.

- Production environment. Identify the hardware and software components of the production environment, including the network infrastructure, server nodes, and data sources.
- Usage requirements. Characterize how users are likely to utilize the system.

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?

- Data source requirements. Determine how to access any data sources used in Liquid Data queries.
- Security requirements. Determine which users need access to Liquid Data resources and the level of access they need. See Security in Liquid Data in the Administration Guide for detailed information and further references.
- Licensing requirements. Determine the BEA software licenses needed to implement your deployment solution.

Clarifying the specific requirements for your deployment provides the knowledge you will need to design your deployment.

# Deployable Liquid Data Components

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.

Table 2-1 Contents of the LDS.ear file

Component | Description | Deployment Target
--- | --- | ---
`ejb_query.jar` | 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_qbc.jar` | 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.
`XMediator.war` | Initializes the Liquid Data server. | For a multi-node and clustered deployment, deploy to each Managed Server.
`ldconsole.war` | Liquid Data configuration tabs that appear in the WebLogic Server Administration Console. | Always deploy to an Administration Server.
`cacheEjb.jar` | 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.
`ldcacheListener.war` | 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.

# Designing Deployments

This topic describes how to design a Liquid Data deployment for the following types of domains:

- Single Domain Deployments

- Single Server Deployments
- Multi-Node Deployments
- Clustered Deployments
- Multi-Domain Deployments

The deployment architecture that you use depends on the requirements for your particular production environment, as described in Defining Deployment Requirements.

## Single Domain Deployments

The following sections describe single domain deployments:

- Single Server Deployments
- Multi-Node Deployments
- Clustered Deployments

### Single Server 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

### Multi-Node Deployments

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

### Clustered Deployments

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:

- The high volume of concurrent query requests necessitates additional machines in order to achieve system performance requirements.
- High availability through failover protection in the event of a server failure is a deployment requirement.

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.

## Multi-Domain Deployments

In a multi-domain deployment, Liquid Data and the WebLogic Platform component are installed on separate WebLogic domains.