| Oracle® Communications Service Broker System Administrator's Guide Release 6.1 Part Number E29444-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker System Administrator's Guide Release 6.1 Part Number E29444-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of essential concepts and tools you need to understand before you can configure Oracle Communications Service Broker.
A Service Broker deployment can include two types of domains:
Signaling Domain: Used to manage the of the Signaling Tier servers and the Signaling Server Units (SSUs) running on those servers.
Processing Domain: Used to manage the Processing Tier servers and the Interworking Modules (IMs) and Orchestration Engine (OE) running on those servers.
When you use an Administration Console to update the domain configuration, your changes are implemented in the domain configuration directory. Each domain has an associated domain configuration that is stored in the domain configuration directory for that tier.
See the discusson on Service Broker deployments in Service Broker Installation Guide for more information.
A Processing Domain contains a set of logically related Processing Servers, and a Signaling Domain contains a set of logically related Signaling Servers.
Managed servers in a given domain are symmetrical. All servers in the domain have the same software bundles deployed and started. Initial XML configuration data is stored inside the JAR file of the bundle that owns the configuration. Subsequent configuration changes are stored outside the software bundles in a separate location.
Configuration versioning is achieved by storing a copy of each version of the configuration JAR in an archive. At runtime, when the managed servers start only the most recent configuration version is pre-loaded into memory.
Managed servers have read-only access to the domain configuration that is stored in the domain configuration directory. Managed servers can access the domain configuration directory using either a shared file system or an HTTP/HTTPS connection to a domain Web server.
The domains interwork and propagate protocol events across tier boundaries. Figure 1-1 shows the tiers and the domains and how they work together.
Service Broker creates managed server clusters using the Oracle Coherence technology which provides replicated and distributed data management and caching services on top of a highly scalable peer-to-peer clustering protocol.
Oracle Coherence automatically and transparently fails over and redistributes its clustered data management services. When a new managed server is added, or when a failed managed server is restarted, it automatically joins the cluster.
A Service Broker cluster also provides interprocess communication and persistence. Managed servers in all domains, including processing, signaling, and unified domains distribute events among each other across domain boundaries.
After you lock a domain configuration, you can make changes to it. When you lock a domain, it is locked for edits from all other administration clients. To apply the configuration changes you must commit them.As long as you do not commit changes, you can discard them. After you discard all changes, the domain configuration is also unlocked.
This section describes update options for making changes to the domain configuration and then propagating those configuration changes to the managed servers.
An update to the domain configuration and managed servers requires both of these steps:
After you lock a domain for editing, you can make changes to the configuration using either of the following modes.
Autocommit mode
Autocommit is the default mode when using JMX-clients. Autocommit is not an option that is available when using the Administration Console. When you update configurations using the Autocommit mode, your changes are committed and written to the configuration directory immediately. Each change is considered a separate transaction.
Transaction mode
When you update configuration in this mode, changes are not made in real time. Instead, multiple changes accumulate into one transaction. Transaction mode makes it possible to specify a set of configuration changes and have them applied all at once.
Note:
The Administration Server always uses the transaction mode.You can manage transactions by using the following commands:
Administration Console: Lock & Edit, Commit, Discard
JMX-client: Begin, Commit, Rollback
The Domain Configuration Update Mode specifies how configuration updates are propagated to servers in the domain.
You can use either of the following modes:
Online mode: Configuration updates are propagated to all servers in the domain when the changes are committed.
Offline mode: Updates are carried out to the domain configuration and applied to each server only when the server is restarted.
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 either making configuration changes with no running servers (e.g. initial configuration), or when performing a rolling upgrade of an installation.
Configuration validation: The Service Broker validates configurations if made through either online or offline mode. An invalid configuration results in an error.
The Service Broker Administration Server exposes a set of Java Management eXtensions (JMX) Configuration MBeans enabling JMX-compliant clients to manage and monitor the system.
After initial domain configuration, the typical method for a telecom carrier to work with Service Broker is to integrate it with a JMX-compatible Network Management System (NMS).
You can enable read and write access to the domain configuration using any of the following tools:
Administration Console: A Web-based graphical user interface.
JConsole: A component of the Java JDK located here: JDK_HOME/bin.
Scripting Engine: The scripting format is an XML file that represent the MBeans, attributes and operations you want to configure. See "Using the Scripting Engine to Configure a Domain" for details.
Other JMX-compliant clients: You can integrate a JMX-compatible Network Management System (NMS) and use it to configure and monitor Service Broker.
The Administration Server enables you to manage a domain configuration. The Administration Console displays the data stored in the domain configuration directory and provides write access.
Each Administration Server manages a single domain. In a typical production deployment you use two instances of the Administration Server: One for the signaling tier and another for the processing tier.
Note:
In a test environment you can use a single unified domain that hosts one or more managed servers with each server performing the role of both the signaling and processing tiers. If you implement this type of test environment, you need to install only a single Administration Server.You can display the Administration Console using a standard Web browser from any computer that has network access to the domain configuration directory. Configuration updates are propagated to all servers in the domain when the changes are committed.
Access to edit a domain configuration is available to one Administration Console at a time. All other users view the Administration Console in read-only mode though an administrator can seize the lock ("force lock") to go to edit mode.
The Administration Console provides users with intuitive application logic by transparently grouping Java objects into useful functional units. However, a site can integrate Service Broker with an NMS by connecting directly to the underlying Service Broker configuration and runtime MBeans.
Service Broker also provides remote monitoring using the Simple Network Management Protocol (SNMP). However, the Service Broker MIB objects are read-only. You cannot modify a Service Broker configuration using SNMP. See Chapter 16, "Remote Monitoring Service Broker with SNMP" for more information.
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 and monitor system resources.
The Service Broker Configuration MBeans provide an API to set/get configuration attributes and to perform operations for configuring the managed resources.
Each component in a domain exposes a set of MBeans, organized in a logical hierarchy, that together form the complete component configuration.
Using the configuration MBeans, Service Broker can be integrated with JMX-compliant clients such as a network management system, JConsole, or the Service Broker scripting engine.
Service Broker provides an MBeans Javadoc as part of its documentation. For more information, see the Oracle Communications Service Broker Configuration and Runtime MBean Java API Reference.
JConsole is a monitoring and management application that is included in the Java JDK. You can locate JConsole here: JDK_HOME/bin/jconsole.
You can use JConsole to do the following:
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
You can manage and configure Service Broker programatically using scripts run by the Scripting Engine. Scripts can automate lengthy and recurring configuration tasks. For example, you can use a script to automate installing the Service Broker on multiple servers.
The scripting format is an XML representation of the MBeans. You define the MBean attributes to change and MBean operations to run and then execute the script from the Scripting Engine.
See "Using the Scripting Engine to Configure a Domain" for details.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
