1 About Domain Configuration

This chapter provides an overview of main concepts that you need to understand before you begin configuring Oracle Communications Service Broker. In addition, the chapter explains tools that you can use to configure Service Broker.

Configuration Overview

A Service Broker deployment includes two types of domains:

Signaling Domain: Used to manage the servers of the Signaling Tier and the SSUs running on these servers.
Processing Domain: Used to manage the servers of the Processing Tier and the module instances (that is OE and IM instances) running on these servers.

Each domain has an associated domain configuration, which is stored in the domain configuration directory. When you make configuration updates, you need to make changes in the domain configuration directory.

About Domains

A set of Processing Servers are grouped into a Processing Domain, and a set of Signaling Servers are grouped into a Signaling Domain.

Servers within a domain are symmetrical. This means that all servers in a domain have the same bundles deployed and started. Each domain has an associated domain configuration located in a directory that the domain servers can access. Servers can access the domain configuration directory either using a shared file system or through HTTP.

The domains interwork and propagate protocol events across the tier boundaries. Figure 1-1 gives an overview of the tiers and the domains and how they work together.

Figure 1-1 Overview of Domains and Tiers

About Domain Configuration Modes

The domain configuration mode specifies how configuration updates are propagated to servers in the domain. You can use one of the following modes:

Online mode, when configuration updates are propagated to all servers in the domain as the changes are carried out.
Offline mode, when updates are carried out only to the domain configuration and applied to each server when it is re-started.

Setting the domain configuration offline makes it possible to perform a set of configuration updates and apply them the next time a server is restarted. This is used, for example, when doing a rolling upgrade of an installation.

About Locking Domain Configuration for Changes

You need to lock a domain configuration in order to make configuration updates to it. When you lock the domain, it is locked for edits from other administration clients.

After locking a domain configuration, you can make changes to it. You need to commit the changes in order to apply them on the domain configuration.

As long as you do not commit changes, you can discard them. After you discard all changes, the domain configuration is locked again.

About Configuration Tools

You can access a domain configuration directory using one of the following tools:

Administration Console: Graphical user interface.
JMX Configuration MBeans: Java software API based on standard Java Management Extensions (JMX). The API provides a system interface for configuration.
Scripting Engine: JMX Configuration MBeans are also accessible through a Scripting Engine. The script format is an XML which represent MBeans and MBean attributes that you want to configure. See “Using Scripting for Configuration and Management” in Oracle Communications Service Broker System Administrator's Guide for instructions.
JMX-compliant GUI: Any JMX-compliant GUI can be used, for example, JConsole, which is included with JDK.

All configuration tasks can be achieved in either way. You can use the Administration Console, the Configuration MBeans, the Scripting Engine and the JMX-compliant GUI interchangeably to make configuration changes, because all tools use Configuration MBeans as their underlying layer.

About the Administration Console

You can manage a domain configuration using the Administration Console. It renders in the GUI the data stored in the domain configuration directory, and it has read and write access to the domain configuration directory.

The Administration Console can be installed and run from any system that has access to the domain configuration directory.

The Administration Console can run in two ways:

Standalone Administration Console, which is a desktop software application provided with Service Broker.
Web Administration Console, which you can access using a standard web browser.

The Administration Console manages a single domain. In a typical production deployment there are two instances of the Administration Console, one to manage the Signaling Domain and another to manage the Processing Domain.

Note:

In a test environment, where one domain includes both Signaling Servers and Processing Servers, there is only one Administration Console instance. In this case, the Administration Console manages both the Signaling Tier and Processing Tier in one domain.

About Configuration MBeans

Service Broker provides a standard software API to configure the Service Broker modules in the form of Java Management eXtensions (JMX) Configuration MBeans. JMX is a Java technology that provides tools to manage system resources (for example, applications, devices). The resources are represented by objects called Management Beans (MBeans). JMX configuration MBeans are simple Java objects that provide an API to set/get configuration attributes. Service Broker configuration is entirely supported by JMX configuration MBeans and can be used by JMX clients to set/get Service Broker configuration. JMX is specified in the Java Specification Requests.

You can access and manage a domain configuration using the configuration MBeans on the domain's Administration Server (where the domain Administration Console is running). Each component in a domain, that is SSU, OE, IM or SM, has a set of MBeans, organized in a logical hierarchy, that together form the complete component configuration.

Figure 1-2 shows an example of the MBean hierarchy for the IM-SCF CAP phase 1 component:

Figure 1-2 Example of an IM Configuration MBean Hierarchy

Service Broker MBean Object Names

All MBeans are registered in the MBean Server under an object name of type javax.management.ObjectName. Service Broker encodes its MBean object names as follows:

com.convergin:Type=MBean-type-name,Target=server,Version=version_number, Location=AdminServer,Name=component-name.unique-resource-name

Table 1-1 describes the key properties that Service Broker encodes in its MBean object names.

Table 1-1 Service Broker MBean Object Name Key Properties

Property	Description
Type=MBean-type-name	The short name of the MBean's type. The short name is the unqualified type name without the MBean suffix. For example, for an MBean that is an instance of the LinksetMBean, the Type would be Linkset.
Target=server	In the specific case of SS7 SSU MBeans, this property specifies the name of the target server where the SSU is running.
Version=version_number	Specifies the version of the MBean instance. When you upgrade an MBean to a later version, this parameter parameter enables Service Broker to keep the same name for different versions of the same MBean and use the version number to differentiate between them.
Location=AdminServer	Specifies the location of an MBean. This parameter is always set to AdminServer.
Name=component-name.unique-resource-name	The name of the Service Broker component whose configuration is stored in the MBean, followed by a unique string that was provided upon creation of the MBean to identify the component resource which is represented by the MBean.

For example:

com.convergin:Type=IpRemoteSystem,Target=ssu_managed_1,Version=1.0, Location=AdminServer,Name=sbssuss7.SG01

About JConsole

JConsole is a Java Monitoring and Management Console included in JDK 5.0 or higher. It provides configuration GUI for applications running on java platforms and supporting the Java Management eXtension technology. By using JConsole you can manage the Service Broker configuration MBeans.

With JConsole you can:

View Service Broker configuration by viewing instances of configuration MBeans, as well as their attributes and operations
Update Service Broker configuration by setting writable attribute values and invoking operations

Figure 1-3 shows an example of using JConsole for viewing information about an MBean instance's attribute.

Figure 1-3 Viewing Information about MBean Instance's Attribute

For more information on using JConsole, see http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

Understanding the Hierarchy of MBeans in JConsole

For each individual MBean, JConsole automatically generates a tree structure based on the object name of an MBean. See "Service Broker MBean Object Names" for more information about the format of MBean object names.

In this tree structure, each nested node represents a single property of the object name. For example, the object name of an OeMbean instance is com.convergin:Type=OE,Version=1.0.0,Location=AdminServer,Name=oe_instance.oe_instance. Figure 1-4 shows the tree structure that JConsole generated for this MBean.

Figure 1-4 MBean Tree Structure

Notice that all Service Broker MBeans are located under the com.convergin node, because they all have a com.convergin domain in their object name. Under the com.convergin node you'll find all the types of Service Broker MBeans, each node represents one type of MBean.

Different instances of the same MBean type are displayed as different nodes nested into the node representing their common type. For example, Figure 1-5 shows different instances of DeploymentMBean displayed as different nodes under the Deployment node.

Figure 1-5 Example of Displaying Different Instances of the Same Type

DeploymentMBean instances displayed as nodes

About the Scripting Engine

You can manage and configure Service Broker programatically using scripts run by the Scripting Engine. The Scripting Engine has an MBean server that you can use to manage Service Broker configuration MBeans.

You define MBean operations to run and/or MBean parameters to change in your scripts and then execute them from the Scripting Engine. The script format is an XML representation of the MBeans.

See "Using Scripts for Configuration and Management" for details.