Oracle® Communications Service Broker System Administrator's Guide Release 6.0 Part Number E23523-02 |
|
|
View PDF |
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.
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.
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.
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.
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.
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.
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.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:
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
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.
For more information on using JConsole, see http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
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.
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.
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.