bea.com | products | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > Liquid Data for WebLogic > Deploying Liquid Data > Deployment Tasks |
Deploying Liquid Data
|
Deployment Tasks
This topic describes the tasks involved in deploying BEA Liquid Data for WebLogicTM in a production environment. It includes the following sections:
Defining Deployment Requirements
Defining deployment requirements is a critical first step in the process of deploying Liquid Data in a production environment.
When planning a deployment, consider the following issues:
At a minimum, BEA WebLogic ServerTM and Liquid Data need to be deployed on at least one server.
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.
Designing a Deployment
This topic describes how to design a Liquid Data deployment. It describes:
The deployment architecture that you use depends on the requirements for your particular production environment, as described in Defining Deployment Requirements.
You choose one of these types of deployments when you create the domain using the WebLogic Platform Configuration Wizard. For more information, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Single Domain Deployments
The following sections describe single domain 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-1 Liquid Data and WebLogic Platform Deployed on a Single Server
For instructions on how to deploy Liquid Data and other WebLogic Platform components on a single server (standalone) deployment, see the following sections:
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-2 Liquid Data Deployed in a Multi-Node Domain
To deploy this design, follow the steps described in Deploying Liquid Data on a Multi-Node WebLogic 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 extensive 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 Liquid Data 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-3 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.
To deploy this design, follow the steps described in:
Multi-Domain Deployments
In a multi-domain deployment, Liquid Data and the WebLogic Platform component are installed on separate WebLogic domains. To deploy this design for WebLogic Portal, follow the steps described in Deploying Liquid Data and WebLogic Portal in Separate Domains.
Deploying Liquid Data in a WebLogic Platform Domain
The following topics describe how to deploy Liquid Data with WebLogic Platform:
Deploying Liquid Data on a Standalone WebLogic Platform Domain
This section describes how to deploy Liquid Data on a standalone (single server) WebLogic Platform domain. For more information about single server deployments, see Single Server Deployments.
To deploy Liquid Data on a standalone WebLogic Platform domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Platform domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying Liquid Data on a Multi-Node WebLogic Domain
This section describes how to deploy Liquid Data on a WebLogic domain with an Administration Server and Managed Servers in a multi-node, non-clustered environment. For more information about multi-node domains, see Multi-Node Deployments.
Notes: Due to limitations with WebLogic Integration, do not configure WebLogic Integration on a WebLogic domain in a multi-node environment.
Before you begin, verify that your BEA software license is appropriate for your deployment.
To deploy Liquid Data on a multi-node WebLogic Platform domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Platform domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying a Liquid Data Cluster on a WebLogic Platform Domain
This section describes how to deploy a Liquid Data cluster on a WebLogic domain with an Administration Server and Managed Servers. Clustering is typically used to provide scalability in deployments with high volumes of query requests and to provide fail-over protection in deployments with high availability requirements. For more information about clustered deployments, see Clustered Deployments.
Note: Before you begin, verify that your BEA software license is appropriate for your deployment.
To deploy a Liquid Data cluster on a WebLogic Platform domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Platform domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying Liquid Data in a WebLogic Integration Domain
The following sections describe how to deploy Liquid Data with WebLogic Integration.
Note: Due to limitations with WebLogic Integration, do not configure WebLogic Integration on a WebLogic domain in a multi-node environment.
Deploying Liquid Data On a Standalone WebLogic Integration Domain
This section describes how to deploy Liquid Data on a standalone (single server) WebLogic Integration domain. For more information about single server deployments, see Single Server Deployments.
To deploy Liquid Data on a standalone WebLogic Integration domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Integration domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=%BEA_HOME%\weblogic700\liquiddata
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImple.jar
set SVRCP=%SVRCP%;%LDCLASSPATH%
LD_HOME=$BEA_HOME/weblogic700/liquiddata
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
SVRCP=$SVRCP:$LDCLASSPATH
Deploying Liquid Data in a Clustered WebLogic Integration Domain
This section describes how to deploy Liquid Data in a clustered WebLogic domain. Clustering is typically used to provide scalability in deployments with high volumes of query requests and to provide fail-over protection in deployments with high availability requirements. For more information about clustered deployments, see Clustered Deployments.
Note: Before you begin, verify that your BEA software license is appropriate for your deployment.
To deploy Liquid Data in a clustered WebLogic Integration domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Integration domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=%BEA_HOME%\weblogic700\liquiddata
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImple.jar
On the Administration Server, specify the following command:
set SVRCP=%SVRCP%;%LDCLASSPATH%
On any Managed Servers, specify the following command:
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
In the startup script, verify that the following information about the Administration Server is correct:
set ADMIN_URL=admin_server_name:admin_server_listening_port
LD_HOME=$BEA_HOME/weblogic700/liquiddata
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
Deploying Liquid Data in a WebLogic Server Domain
The following sections describe how to deploy Liquid Data in a WebLogic Server domain:
Deploying Liquid Data in a Standalone WebLogic Server Domain
This section describes how to deploy Liquid Data in a standalone (single server) WebLogic Server domain. For more information about single server deployments, see Single Server Deployments.
To deploy Liquid Data in a standalone WebLogic Server domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Server domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
<Security CompatibilityMode="true" GuestDisabled="false" Name="wls_domain_name" Realm="myRealm" RealmSetup="true"/>
<Realm FileRealm="myFileRealm" Name="myRealm"/>
<FileRealm Name="myFileRealm"/>
This example assumes that you are using a file realm for the compatibility security realm. For other types of security realms, see "Specifying a Security Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
ServerCertificateFileName="democert.pem"
ServerKeyFileName="demokey.pem" TrustedCAFileName="ca.pem"
ServerPrivateKeyAlias="demokey"
ServerPrivateKeyPassPhrase="WhatEverHere"
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar;
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying Liquid Data in a Clustered WebLogic Server Domain
This section describes how to deploy Liquid Data in a clustered WebLogic Server domain. Clustering is typically used to provide scalability in deployments with high volumes of query requests and to provide fail-over protection in deployments with high availability requirements. For more information about clustered deployments, see Clustered Deployments.
Note: Before you begin, verify that your BEA software license is appropriate for your deployment.
To deploy Liquid Data in a clustered WebLogic Server domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Server domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
<Security CompatibilityMode="true" GuestDisabled="false" Name="wls_domain_name" Realm="myRealm" RealmSetup="true"/>
<Realm FileRealm="myFileRealm" Name="myRealm"/>
<FileRealm Name="myFileRealm"/>
This example assumes that you are using a file realm for the compatibility security realm. For other types of security realms, see "Specifying a Security Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
ServerCertificateFileName="democert.pem"
ServerKeyFileName="demokey.pem" TrustedCAFileName="ca.pem"
ServerPrivateKeyAlias="demokey"
ServerPrivateKeyPassPhrase="WhatEverHere"
set LD_HOME=ld_home_dir
set LD_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LD_LIB%\wlldi.jar;%LD_LIB%\LDS-descriptions,jar;%LD_LIB%\castor-0.9.3.9.jar;%LD_LIB%\xercesImpl.jar
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying Liquid Data in a WebLogic Portal Domain
The following topics describe how to deploy Liquid Data with WebLogic Portal:
For general information about managing WebLogic Portal in a production environment, see System Administration in the WebLogic Portal Administration Guide.
Deploying Liquid Data in a Standalone WebLogic Portal Domain
This section describes how to deploy Liquid Data in a standalone (single server) WebLogic Portal domain. For more information about single server deployments, see Single Server Deployments.
To deploy Liquid Data in a standalone WebLogic Portal domain:
For instructions, see Developing Portals—Tutorials in the Development Guide in the WebLogic Portal documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Portal domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar;
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
Deploying Liquid Data and WebLogic Portal in Separate Domains
To deploy Liquid Data and WebLogic Portal in separate domains:
<taglib>
<taglib-uri>LDSTLD</taglib-uri>
<taglib-location>/WEB-INF/lib/LDS-taglib.jar</taglib-location>
</taglib>
Note: When Liquid Data and the WebLogic Platform are deployed in separate domains, use the Liquid Data EJB API instead of the Liquid Data tag library. The Liquid Data tag library does not support multi-domain security. For more information, see Invoking Queries in EJB Clients in Invoking Queries Programmatically.
Deploying Liquid Data in a Standalone WebLogic Workshop Domain
This section describes how to deploy Liquid Data in a standalone (single server) WebLogic Workshop domain. For more information about single server deployments, see Single Server Deployments.
To deploy Liquid Data in a WebLogic Workshop domain:
For instructions, see Creating a New WebLogic Domain in Using the Configuration Wizard in the WebLogic Platform documentation.
Note: If you want to deploy Liquid Data on an existing WebLogic Workshop domain instead of creating a new one, then the existing domain must use a WebLogic Server compatibility security realm. For more information, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.
<Realm FileRealm="myFileRealm" Name="myRealm"/>
<FileRealm Name="myFileRealm"/>
<Security CompatibilityMode="true" GuestDisabled="false" Name="<workshop_domain_name>" Realm="myRealm" RealmSetup="true"/>
set LD_HOME=ld_home_dir
set LDI_LIB=%LD_HOME%\server\lib
set LDCLASSPATH=%LDI_LIB%\wlldi.jar;%LDI_LIB%\LDS-descriptions.jar;%LDI_LIB%\castor-0.9.3.9.jar;%LDI_LIB%\xercesImpl.jar;
set CLASSPATH=%CLASSPATH%;%LDCLASSPATH%
LD_HOME=ld_home_dir
LDI_LIB=$LD_HOME/server/lib
LDCLASSPATH=$LDI_LIB/wlldi.jar:$LDI_LIB/LDS-descriptions.jar:$LDI_LIB/castor-0.9.3.9.jar:$LDI_LIB/xercesImpl.jar
CLASSPATH=$CLASSPATH:$LDCLASSPATH
export CLASSPATH
group.Administrators=system,domain_user_name
acl.lookup.weblogic.jndi=everyone
acl.modify.weblogic.jndi.weblogic.fileSystem=Administrators
acl.admin.weblogic.jdbc=Administrators
acl.lookup.weblogic.jndi.weblogic.fileSystem=Administrators
acl.lookup.weblogic.jndi.weblogic.ejb=Administrators
acl.list.weblogic.jndi.weblogic.rmi=Administrators
acl.shrink.weblogic.jdbc=Administrators
acl.create.weblogic.jms.ConnectionConsumer=Administrators
acl.lockServer.weblogic.admin=Administrators
acl.shutdown.weblogic.admin=Administrators
acl.boot.weblogic.server=Administrators
acl.list.weblogic.jndi.weblogic.fileSystem=Administrators
acl.lookup.weblogic.jndi.weblogic=Administrators
acl.modify.weblogic.jndi.weblogic.rmi=Administrators
acl.modify.weblogic.jndi.weblogic=Administrators
acl.list.weblogic.jndi.weblogic=Administrators
acl.send.weblogic.jms=Administrators
acl.lookup.weblogic.management=Administrators
acl.receive.weblogic.jms=Administrators
acl.reserve.weblogic.jdbc=Administrators
acl.modify.weblogic.management=Administrators
acl.lookup.weblogic.jndi.weblogic.rmi=Administrators
acl.list.weblogic.jndi=Administrators
acl.modify.weblogic.jdbc=Administrators
acl.modify.weblogic.admin.acl=Administrators
acl.list.weblogic.jndi.weblogic.ejb=Administrators
acl.modify.weblogic.jndi=Administrators
acl.write.managedObject=Administrators
acl.reset.weblogic.jdbc=Administrators
acl.read.managedObject=Administrators
acl.admin.weblogic.jdbc.connectionPoolcreate=Administrators
acl.unlockServer.weblogic.admin=Administrators
acl.execute.weblogic.servlet=Administrators
acl.modify.weblogic.jndi.weblogic.ejb=Administrators
Copying a Server Configuration to Another Server
This topic describes the steps involved in copying Liquid Data server configuration information from one server to another, such as from a development environment to a production environment. Rather than configuring the production server manually, you can transfer settings already configured in the development environment.
The following illustration shows the Liquid Data components that you need to transfer to the production server:
Figure 2-4 Migrating From a Development to a Production Server
To migrate from a development environment to a production environment, you need to migrate the following configuration information:
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |