Re-wire Oracle SOA Datasource to use Active GridLink for RAC

Starting 11gR1 PS5 (11.1.1.6), Oracle SOA Suite platform is enhanced to support Active GridLink for Real Application Clusters (RAC).

WebLogic Server Active GridLink (AGL) for RAC provides the best available support for the RAC features in Oracle Database 11g. The generic data source is the implementation for single database access. The Multi-data source is the native WebLogic middle tier implementation for RAC integration, which does not leverage Oracle Notification Service (ONS).

The GridLink data source is the new Active GridLink implementation and includes the features of generic data sources, taking advantage of Oracle RAC supporting Fast Connection Failover (FCF), Runtime Connection Load-Balancing (RCLB), and XA Affinities. A GridLink data source is created for JDBC connectivity between WebLogic Server and a service targeted to an Oracle RAC cluster. It uses the Oracle Notification Service (ONS) to adaptively respond to state changes in an Oracle RAC instance.

Here are couple of good resources that can help you understand the AGL concepts in more detail:
- What is Active GridLink
- Benefits of AGL data sources

Basically, a data source configuration is always an Active GridLink (AGL) data source configuration if FanEnabled=true or the OnsNodeList is non-null.

Here is a modified version of a python script (borrowed from my colleague), that you can use to rewire the SOA data sources to use Active GridLink for RAC databases. Before executing the script, remember to shutdown all the WLS SOA domain servers; its an offline wlst script.

Configuring SOA Distributed Destination Topics using WLST

The organization of topics and the granularity of subscriptions to them is an important part of a publish/subscribe application’s architecture. A message delivered to a topic is distributed to all consumers that are subscribed to that topic. Ensuring that a clustered application gets exactly one copy of each message, and parallel processing of topics messages may require significant additional configuration, coding, and message hops. To address such limitations, WebLogic JMS provides load balancing and failover for physical JMS destination members (queues or topics) through its "Distributed Destinations" that applications can leverage.

In a typical SOA Suite production cluster deployment, load balancing the JMS topic messages against the SOA composites will be a common requirement. It is to ensure that messages are evenly distributed (load balanced) to SOA cluster members, and to avoid duplication in some scenarios. This can be achieved by configuring the SOA JMS Topic to use a "Distributed Destination" setting the appropriate forwarding policy and other advanced parameters.

Here is a sample WLST offline script:


Note that there in no support to define the UniformDistributed Queue/Topic in weblogic application extension templates' file config/jms/<%jms-module%>-jms.xml (as of the latest SOA PS6 release). Refer the "Fusion Middleware Programming JMS for Oracle WebLogic Server" guide for more details on WLS JMS Distributed Destinations.

Configuring Oracle SOA TLOGS JDBC Persistence Store using WLST Offline

In this post, we will look at configuring Oracle SOA to use TLog JDBC persistent stores using WLST (offline).

First, some info on TLogs. Weblogic Server (WLS) holds records of the state of in-flight transactions that are marked to be committed, in a 'TLOG' (Transaction Log) persistent store. The persistent store can either be files on a file-system or a table in database. When an instance is restarted, the TLog files are used to perform the second step of a two-phase commit on a transaction that was in progress.

So, why is this persistent-store configuration important? Configuring a WLS TLOG store to persist transaction logs to a database provides the following benefits (covered in the WLS documentation):

• Leverages replication and High Availability characteristics of the underlying database.
• Simplifies disaster recovery by allowing the easy synchronization of the state of the database and TLOGs.
• Improved Transaction Recovery service migration as the transaction logs to do not need to be migrated (copied) to a new location.

Now onto the sample WLST OFFLINE python script to see how the persistent store configuration can be accomplished. At a high level, the SOA TLOG configuration script enables JDBC Persistent Store for each Weblogic SOA managed server that belongs to the SOA Cluster. The script was verified in a 11g SOA PS6 env and will give you a general idea on what commands need to be executed.

Oracle SOA Suite JMS Deployment Topology

Java Message Service (JMS) messaging architecture relies on a data centric approach for application integration. The Oracle Service Oriented Architecture (SOA) core infrastructure engine (or ESB) implements messaging to enable services to be integrated in a message-based paradigm – both synchronous and asynchronous styles. Hence, for those familiar or working with SOA Suite 11g, it becomes necessary to know the SOA JMS resources that are configured in Weblogic Server.

So, when it comes to understanding JMS deployment in a Weblogic environment, it helps to be aware of the major components of the WebLogic JMS Server architecture. JMS Servers act as management containers for JMS Queue and Topic destinations in JMS Modules, which contains configuration resources such as Queues, Topics, distributed Destinations and Connections Factories. These JMS module resources are grouped and targeted to Weblogic server resources such as JMS servers, server instances, or cluster by a mechanism called SubDeployment. Information on JMS modules' administered objects are placed in a JNDI namespace and are written to the file <product-module-name>--jms.xml in the config\jms subdirectory of the domain directory. The JMS module will be referenced in the domain's config.xml file as a <jms-system-resource> element.

Here is a representation of the JMS resources deployment from a standalone i.e. non-cluster SOA Suite 11g-PS6 deployment, that could be helpful in enhancing your understanding. The persistent store depicted can either be 'File' or a table in database.

Some points to remember for a successful JMS resources deployment and transparent access:

• All JMS server names must be unique within a domain and across all inter-operating domains 
• All JMS store (File or JDBC) names must be unique and have unique MBean names
• All user-defined JMS connection factories targeted to servers/clusters in a domain must have unique JNDI and MBean names
• Queue destinations can use the same name as other Queues on different JMS servers 
•  Topic destinations can also use the same name as other Topics on different JMS servers

Refer the official documentation for latest and greater details on Weblogic JMS architecture.

Java Management Extensions and Weblogic Server MBeans

The best part I like about Java Management Extensions (JMX) framework is that it allows developers of applications, services, or devices to make their products manageable in a standard way without having to understand or invest in complex management systems.

JMX has been around as a core JEE API for a long time and is the foundation for everything you can do to manage the Oracle Weblogic Server. The JMX architecture in the context of Weblogic Server as I see it is shown in figure below:

Application components designed with their management interface in mind can typically be written as MBeans. WLS MBeans are 3 types - Domain, Server and Application level MBeans. You can instrument your applications deployed to WLS by providing one or more management beans. For example, the DomainRuntimeMBean provides a federated view of all of the running JVMs in a Weblogic administrative domain. All Weblogic Server MBeans can be organized into one of the following general types - Runtime MBeans or Configuration MBeans based on whether the MBean monitors the runtime state of a server or configures servers and JMX manageable resources.

WLS MBean Server acts as a container for MBeans. The MBean servers available in a Weblogic domain are:

1. Runtime MBeanServer: is the MBeanServer available from any Weblogic process, and contains both Weblogic and user MBeans. Each server in the domain hosts an instance of this MBean server.
2. Domain MBeanServer: This MBeanServer provides federated access to MBeans for domain-wide services. Collocated with the WLS domain admin server process, this server  also acts as a single point of access for MBeans that reside on Managed Servers.  So, as long as a managed server is up, its MBeans can be accessed through the "Domain Runtime" MBeanServer.
3. Edit MBeanServer: Collocated with the WLS domain admin server process, it provides access to pending configuration MBeans and operations that control the configuration of a Weblogic Server domain. No application MBeans can be registered in this MBeanServer. 

The JMX API enables to perform remote management of resources by using JMX technology-based connectors (JMX connectors). Adaptors and connectors make all MBean server operations available to a remote management application. Fusion Applications Control (or commonly known as EM Console) is the primary administration management interface. Developers can programmatically monitor Weblogic Server by using the JMX interface directly in a Java program or by writing scripts using a tool such as WLST.

Here is a good blog article on managing WLS using Jconsole: http://blogs.oracle.com/WebLogicServer/entry/managing_weblogic_servers_with

Please refer the Oracle Weblogic Server documentation for the latest on WLS-MBeans.