1 About Service Broker Deployments

This chapter describes essential concepts for understanding Oracle Communications Service Broker deployments.

Understanding the Domain-Based Administration Model

Service Broker is implemented and administered using the concept of domains. A domain is a logically related group of servers.

Figure 1-1 shows domain components, which are explained in the following sections.

Figure 1-1 A Service Broker Domain

About Managed Servers

Each managed server runs on its own Java Virtual Machine (JVM). Managed servers in a domain all have the same Open Services Gateway Initiative (OSGi) software bundles installed and started.

Managed servers have read-only access to the domain configuration directory. At startup, the servers load the software bundles and the required configuration from the domain configuration directory.

Managed servers can be added and removed from the domain without service interruption while the system is running.

About the Domain Configuration Directory

Each domain has one associated domain configuration which is stored in the domain configuration directory. The domain configuration directory contains:

• The configuration details stored in XML files for all the managed servers in the domain.

• The OSGi software bundles that the managed servers run.

When a managed server starts, it retrieves configuration data from the domain configuration directory and loads it into memory. Individual servers do not store configuration locally except for the initial configuration and the security-related details they need to enable access to the domain configuration directory.

Changes in the domain configuration directory are managed by the Administration Server. The Administration Server saves all configuration updates to the domain configuration directory during runtime.

Managed servers access the domain configuration directory using either of these data sharing methods:

• Shared network file system

• Domain Configuration Web server that connects to the managed servers using HTTP or HTTPS.

  Note:

  HTTP should never be used in a production environment.

About the Administration Server

The Administration Server enables you to manage the domain servers, the OSGi software bundles installed in the domain, and the data stored in the domain configuration directory. Oracle recommends using a dedicated computer for the Administration Server.

You can access the Administration Server using these clients:

• Administration Console:

  Web access enables administrators to configure the domain from any computer with a Web browser and network access to the Administration Server.

• JConsole or Scripting Engine:

  If you want, you can interact programmatically with the Administration Server by using JMX configuration MBeans. Typically, working with MBeans involves integrating Service Broker with a JMX-enabled network management system.

  Scripts can be used if you need to repeat lengthy and complicated configuration changes. The scripting engine is a shell script that accepts an XML file argument. The XML file defines operations and attributes on Administration Server configuration MBeans.

Domain Types

The domain type reflects which sets of software bundles are run on the managed servers and which Service Broker roles they perform.

There are three domain types:

• Signaling domain:

  Managed servers in the signaling domain run the software bundles associated with the Service Broker signaling tier. These components include the various signaling server units (SSUs) that enable network connectivity. Servers in the signaling domain are often referred to as signaling servers.

• Processing domain:

  Managed servers in the processing domain run the software bundle associated with the Service Broker processing tier. These components include the Interworking Modules (IMs), an Orchestration Engine (OE), applications, and mediators that enable traffic processing and mediation functions. Servers in the processing domain are often referred to as processing servers.

• Unified domain:

  This domain combines the processing and signaling tier functions. Managed servers in the unified domain run the bundles associated with both the signaling tier and processing tier.

Deployment Topologies

This section describes the topologies you can optionally use for Service Broker deployments. The selection of a deployment topology will affect level of performance, availability, and continuity. See the description of service availability and continuity in the "About Setting the Service Availability Mode" section for more information.

Multi-Domain Topology

A multi-domain topology implements two distinct types of domains:

• A signaling domain

• A processing domain

State information can be shared across servers in the domain, ensuring service continuity in case of server failure. The signaling domain and processing domain interact by propagating protocol events across the tier and domain boundaries.

Figure 1-2 shows a multi-domain topology with one signaling domain and one processing domain, with the session state distributed across the processing servers.

Figure 1-2 A Multi-Domain Topology

Note:

If your telecom system connects to multiple networks, you should consider implementing an additional signaling domain for each network.

Unified Domain Topology

Each managed server in a unified domain performs the role of both the signaling tier and the processing tier. Multiple managed servers in the domain enable server availability following a server failure. See "About Setting the Service Availability Mode" for more information about availability and continuity options.

Figure 1-3 shows a unified domain topology with one unified domain in which servers perform the role of both the processing and signaling tiers.

Figure 1-3 A Unified Domain Topology

About Clusters

Service Broker creates managed server clusters using the Oracle Coherence product technology, which provides replicated and distributed data management and caching services. Coherence uses a highly scalable peer-to-peer clustering protocol. See the Oracle Coherence product documentation for an introduction to this technology.

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 provides the following additional services:

• Interprocess communication

• Persistence

Managed servers in all domains (processing, signaling, and unified) distribute events among each other across domain boundaries.To make the domains aware of each other, you need to group them in a cluster using either of these two methods, which are mutually exclusive:

• Using IP multicast: In this case, you need to specify a single IP address. All servers use this address to send and receive broadcast messages. Multicast is the default option when you use the domain creation script.

• Using IP unicast: In this case, you need to specify IP addresses of all servers in both domains.

For more information on how to set up IP multicast and IP unicast, see the discussion on configuring coherence in Oracle Communications Service Broker System Administrator's Guide.

About Setting the Service Availability Mode

The components running in the processing tier are stateful; that is, they maintain session information. They retrieve and store session state using in-memory storage to maintain service availability.

When creating a domain, whether you create a unified or a multi-domain, you can select the desired service availability mode:

• Availability: Service availability is maintained and continuity is turned off.

• Continuity: Service availability is maintained and continuity is turned on.

Important: Turning service continuity off improves performance significantly. However, calls on a failed managed server are not saved.

Service availability ensures that if a managed server fails, other managed servers in that domain will handle all new incoming traffic. Service continuity ensures that if a managed server fails, functioning servers continue to retrieve and process all messages, including those stored in the failed server.

About Deploying Service Broker Products

Service Broker software installation and domain creation involve two separate procedures. After you run the installer, you are required to run a domain creation script. This script displays many prompts including one requesting that you select from a list of available product domains. The list of available domains depends on the products you installed.

Whether you select a multi-domain or a unified domain Service Broker deployment, you can implement a single Service Broker product or any combination of the following products:

• Service Controller

• Online Mediation Controller

• Policy Controller

Note:

• The Social Voice Communicator and Virtual Private Network applications can be installed only if you install Service Controller.

• If you deploy the Social Voice Communicator, the service availability mode for that domain will always be Availability.

If you install all Service Broker products and applications, you will be presented with a prompt similar to this.

Available Domains:

[0] Online Mediation Controller Domain
[1] Policy Controller Domain
[2] Service Controller Domain
[3] Social Voice Communicator Domain
[4] Virtual Private Network Domain

You can select one, or any combination, of the product domains.

If you run the script twice to create a multi-domain with separate signaling and processing tiers, be sure to choose the same product domains for each tier.

About Production Environments

For best performance in production environments, Oracle recommends using a unified domain topology with one domain in which servers perform the role of both the processing and signaling tiers as shown in Figure 1-4.

In this type of deployment, managed servers maintain state information but the state information is not distributed across the servers. Existing calls on a failed server will be dropped. However, another server in the domain will implement service availability and handle new incoming calls.

Figure 1-4 A Production Environment Unified Domain

An alternative is to use a multi-domain topology (described in "Multi-Domain Topology") that implements service continuity, as shown in Figure 1-5.

For complex Service Broker deployments, you can optionally create multiple signaling domains (each connecting to a different network), and multiple processing domains (each supporting a different processing functionality).

Figure 1-5 A Production Multi-Domain Deployment

Note:

In a production environment, each domain should always include at least two servers for server failover availability.

About Test and Evaluation Systems

You can use a test and evaluation system to familiarize yourself with Service Broker, for integrations, for proof of concept labs, and for training. A test and evaluation system does not have the same requirements that a production system has for performance, availability, service continuity, and tier redundancy.

A test and evaluation system can be deployed as a unified domain with a single managed server, or two managed servers at most, with each server preforming the role of both signaling tier and processing tier.

WARNING:

Never convert a test and evaluation system to a production system. A production system should be created independently with the highest degree of care.

Figure 1-6 shows a test and evaluation deployment with one domain. Each server performs the role of both the processing and signaling tiers. In this figure, service continuity is turned off. However, you can also deploy a system with service continuity turned on.

Figure 1-6 Test and Evaluation Deployment

Scaling the Deployment

Scalability is the ability of the Service Broker to handle increasing numbers of requests without adversely affecting performance.

Scaling options differ according to whether you are scaling the processing tier or the signaling tier.

Scaling the Processing Tier

The processing tier of a Service Broker deployment includes two or more processing managed servers that together provide high availability and load balancing. The Service Broker processing tier can increase its throughput by adding additional processing servers to the processing domain.

You can add new processing servers by using these scaling options:

• Vertical scaling: You can add to a single physical computer on its processing domain more processing servers.

• Horizontal scaling: You can add a physical computer and deploy processing servers to the same processing domain. The additional processing servers will balance the workload with the processing servers on the other physical computer.

Scaling the Signaling Tier

The signaling tier can also be scaled both vertically and horizontally. You can add signaling servers to the signaling domain on a single computer or by adding new server host computers. However, there are a few additional items to consider when implementing connectivity to SS7 networks:

• When implementing SIGTRAN-based SS7 connectivity, the signaling tier can include up to sixteen servers whether the servers are administered in a unified domain or in a separate signaling domain.

• When implementing TDM-based SS7 connectivity, the signaling tier can include up to two servers whether the servers are administered in a unified domain or in a separate signaling domain.

Note:

Note that in a unified domain, your processing tier is limited to the same number of servers.

To maximize scalability, Oracle recommends that you deploy a separate signaling domain to connect to the SS7 network. By doing this, connectivity to other signaling networks is not affected and servers can be added to the other signaling domains as needed.

To increase throughput of SS7 connectivity in the case of TDM, you can add another pair of signaling servers in a separate signaling domain.