|
|
This document describes how to deploy AquaLogic Service Bus configurations in a production environment. The following sections introduce key concepts and tasks for deploying ALSB in your organization:
This document focuses on the deployment phase of the ALSB software lifecycle. For a general overview of ALSB, see BEA AquaLogic Service Bus Concepts and Architecture.
For information about configuring ALSB, see the documentation available at http://download.oracle.com/docs/cd/E13171_01/alsb/docs30/index.html
ALSB combines intelligent message brokering with service monitoring and administration to provide a unified software product for implementing and deploying your Service-Oriented Architecture (SOA). When deploying ALSB configurations, consider the following goals:
You can achieve these goals and others with every ALSB configuration.
Deploying ALSB may require completing some or all of the following tasks:
To deploy an integrated solution successfully, a deployment team must include people who perform the following roles:
One person can assume multiple roles, and all roles are not equally relevant in all deployment scenarios. A successful deployment, however, requires input by people in each role.
Deployment specialists coordinate the deployment effort. They are knowledgeable about the features of the ALSB product. They provide expertise in designing the deployment topology for an ESB solution, based on their knowledge of how to configure various ALSB features on one or more servers. Deployment specialists have experience in the following areas:
WebLogic Server administrators provide in-depth technical and operational knowledge about WebLogic Server deployments in an organization. They have experience and expertise in the following areas:
Database administrators provide in-depth technical and operational knowledge about database systems deployed in an organization. They have experience and expertise in the following areas:
This section provides an overview of resources that can be modified at deployment time. The term resource is used in this document to refer to technical assets in general, except in discussions of security where it is used to refer only to WebLogic Server entities that can be protected from unauthorized access using security roles and security policies.
The key resources that may be modified at deployment time are:
This section provides general information about WebLogic Server resources that are most relevant to the deployment of an ALSB solution. You can configure these resources from the WebLogic Server Administration Console or through J2EE and WebLogic resource descriptors.
WebLogic Server provides many configuration options and tunable settings for deploying ALSB solutions in any supported environment. The configurable WebLogic Server features that are most relevant to ALSB deployments are:
A cluster is a group of servers that can be managed as a single unit. Clustering provides a deployment platform that is more scalable than a single server. To increase workload capacity, you can run WebLogic Server on a cluster. For more information about clustering, see Understanding ALSB Clusters.
The WebLogic Java Message Service (JMS) enables Java applications sharing a messaging system to exchange (create, send, and receive) messages. WebLogic JMS is based on Java Message Service Specification version 1.0.2 from Sun Microsystems, Inc.
JMS servers can be clustered and connection factories can be deployed on multiple instances of WebLogic Server. For more information about WebLogic JMS, see the following topics:
The number of EJBs in an ALSB deployment affects system throughput. You can tune the number of EJBs in the system through either the EJB pool or the EJB cache, depending on the type of EJB. The following table describes types of EJBs and their associated tunable parameter.
For more information about controlling throughput, see “Server Self-Tuning for Production Environments” under New and Changed Features in WebLogic Server Environments in Designing and Configuring WebLogic Server Environments.
Java Database Connectivity (JDBC) enables Java applications to access data stored in DBMS. To reduce the overhead associated with establishing database connections, WebLogic JDBC provides ready-to-use connection pools.
JDBC connection pools are used to optimize DBMS connections. If you are using the ALSB JMS Reporting Provider, you can tune ALSB performance by configuring the size of JDBC connection pools. A setting that is too low may result in delays while ALSB waits for connections to become available. A setting that is too high may result in slower DBMS performance.
For more information about WebLogic JDBC connection pools, see:
The execution thread pool controls the number of threads that can execute concurrently on WebLogic Server. A setting that is too low may result in sequential processing and possible deadlocks. A setting that is too high may result in excessive memory consumption, and may cause thrashing.
The number of execute threads also determines the number of threads that read incoming socket messages (socket-reader threads). This number is, by default, one-third of the number of execute threads. A number that is too low can result in contention for threads to read sockets and can sometimes lead to a deadlock.
Set the execution thread pool high enough to run all candidate threads, but not so high that performance is hampered due to excessive context switching in the system. Monitor your running system to empirically determine the best value for the execution thread pool.
| Note: | Most production applications require an execution thread count greater than the default value. A thread count of 50 is a commonly used value. Be sure to adjust your JDBC connection pool to match your thread count value. |
For more information about controlling throughput, see “Server Self-Tuning for Production Environments” under New and Changed Features in WebLogic Server Environments in Designing and Configuring WebLogic Server Environments.
The WebLogic J2EE Connector Architecture (JCA) integrates the J2EE Platform with one or more heterogeneous Enterprise Information Systems (EIS). The WebLogic JCA is based on the J2EE Connector Specification, Version 1.0, from Sun Microsystems, Inc.
For information about the WebLogic J2EE-CA, see J2EE Connector Architecture in Programming WebLogic Resource Adapters.
ALSB configuration resources contain environment-specific settings that you will want to change or tune when deploying the configuration to a new domain. The following sections describe the resources that you may need to reconfigure after deploying a configuration.
Business services are ALSB definitions of the enterprise information services with which you want to exchange messages. Business services in a production environment could specify multiple endpoints (URLs) for load balancing purposes and high availability. For information on how to add endpoints to a business service, see “Viewing and Changing Business Services” under Business Services in Using the AquaLogic Service Bus Console. For information on how to update the value of existing endpoints, see “Finding and Replacing Environment Values” in System Administration in Using the AquaLogic Service Bus Console.
Proxy services are ALSB definitions of intermediary Web services that ALSB implements locally on WebLogic Server. While the majority of the metadata that defines a proxy service can be deployed without change in a new environment, there is some information you may need to update:
For more information about proxy services, see Proxy Services in Using the AquaLogic Service Bus Console.
ALSB uses WSDL (Web Service Definition Language) to describe proxy services and business services. WSDL is used to describe what a Web service can do, where it resides, and how to invoke it.
You can base the definition of proxy services and business services on existing WSDL files, and complete configuring the service using the ALSB Console. WSDL files used as the basis for defining services are stored as ALSB resources. These resources are unlikely to require updating when deployed to a new environment, because ALSB does not use the URLs in these WSDL files at run time.
| Note: | ALSB creates a new WSDL file for each HTTP proxy service. You can view the contents of this WSDL file by appending ?wsdl to the endpoint for the service. For example, when running the ALSB Examples Server (Start ProgramsBEA ProductsExamplesAquaLogic Service BusStart Examples Server), you can view the WSDL for the loangateway2 proxy service at http://localhost:7021/crejws_basic_ejb/loangateway2?wsdl. |
A schema is a document that defines valid content for an XML document. Schemas are used to add XML information to messages exchanged in ALSB. These resources are unlikely to require updating when deployed to a new environment.
ALSB uses service accounts to provide authentication when connecting to a service or server. For information about using this resource appropriately in your production environment, see AquaLogic Service Bus Security Guide.
ALSB uses proxy service providers to supply credential-level validation to proxy services. The following types of security are available:
For information about how to configure this resource appropriately for your environment, see Proxy Service Providers in Using the AquaLogic Service Bus Console.
ALSB uses Web Service Policies (WS-Policies) to associate Web service security policy with proxy services and business services. For information about how to configure this resource appropriately for your production environment, see AquaLogic Service Bus Security Guide.
These resources are unlikely to require updating when deployed to a new environment.
Transformation maps describe the mapping between two data types. ALSB supports data mapping using either XQuery or the eXtensible Stylesheet Language Transformation (XSLT) standard. These resources are unlikely to require updating when deployed to a new environment.
Message Format Language (MFL) is a BEA proprietary language used to define rules to transform formatted binary data into XML data. MFL documents are unlikely to require updating when deployed to a new environment.
JARs (Java ARchive) are zipped files that contain a set of Java classes. They are used to store compiled Java classes and associated metadata that can constitute a program. JARs act as callable program libraries for Java code elements (so that a single compilation link provides access to multiple elements, rather than requiring bindings for each element individually). JARs are unlikely to require updating when deployed to a new environment.
An Alert Destination resource captures a list of recipients that can receive alert notifications from the AquaLogic Service Bus. In typical system monitoring contexts, alerts generated by AquaLogic Service Bus bear significance to a finite set of users. In AquaLogic Service Bus, each Alert Destination resource may be configured to include a set of recipients according to a given context. Alert Destinations are used by Alert actions configured in the message flow, and also by SLA alert rules. An Alert destination could include one or more of the following types of destinations: Console, Reporting Data stream, SNMP trap, E-mail, JMS queue, or JMS topic. In the case of E-mail and JMS destinations, a destination resource could include a list of E-mail addresses or JMS URIs, respectively. Alert Destinations are unlikely to require updating when deployed to a new environment.
A UDDI Registry resource is a global resource that stores information about UDDI Registries used by ALSB. After the UDDI Registry resource is configured, you can then publish ALSB proxy services to the associated registry, or import business services from the registry to be used by an ALSB proxy service. You must be in an active session to configure the UDDI registry resource. UDDI Registry resources must be updated or reconfigured when deployed to a new environment. For more information on updating UDDI Registry resources during deployment, see Best Practices to Follow When Migrating Global Resources.
JNDI Provider resources are definitions of JNDI providers that describe the URL (or list of URLs in the case of clustered deployments) of the JNDI providers used by ALSB. They are global resources and can be re-used across projects with an ALSB domain. If the JNDI provider is secured, then the JNDI Provider resource description also carries a user name and password to gain access. JNDI Provider resources must be updated or reconfigured when deployed to a new environment. For more information on updating JNDI Provider resources during deployment, see Best Practices to Follow When Migrating Global Resources.
SMTP Server resources are definitions of SMTP Servers that describe the URL and port for the SMTP Servers used by the ALSB. They are global resources and can be re-used across projects with an ALSB domain. If the SMTP Server is secured, then the SMTP Server resource description also carries a user name and password to gain access. SMTP Server resources are used while configuring Alert Destination resources and E-mail transport-based Business Services. SMTP Server resources must be updated or reconfigured when deployed to a new environment. For more information on updating SMTP Server resources during deployment, see Best Practices to Follow When Migrating Global Resources.
Global resources include the UDDI Registry, JNDI Provider, and SMTP Server resources. These resources typically have different values in testing environments from those that will be used in staging or production environments. When you migrate a deployment from a test environment to a production environment, use one of the following methods:
config.jar file. If there are any resources in the config.jar file that references Alert Destinations, JNDI providers, or SMTP providers, these references will simply snap into place when the import is complete.config.jar file . ALSB relies on database resources for storing message-reporting data by the JMS Reporting Provider. Database performance is a factor in overall ALSB performance. For information about database tuning requirements associated with ALSB applications, see BEA AquaLogic Service Bus Release Notes.
For additional information on tuning your database, see your database vendor’s documentation.
Hardware, operating system, and network resources play a crucial role in ALSB performance. Deployments must comply with the hardware and software requirements described in BEA AquaLogic Service Bus Release Notes.
|