| Oracle® Communications Service Broker Installation Guide Release 6.0 Part Number E23522-02 |
|
|
View PDF |
| Oracle® Communications Service Broker Installation Guide Release 6.0 Part Number E23522-02 |
|
|
View PDF |
This chapter describes basic concepts of Oracle Communications Service Broker deployments and the different types of Service Broker deployments.
Service Broker deployments are implemented and administered using domains. A domain is a logically related group of servers.
Figure 1-1 shows domain components, which are explained in the following sections.
Each server runs on its own Java Virtual Machine (JVM), and the term “server” reflects a JVM rather than a physical host.
Servers within a domain are symmetrical, which means that they all have the same OSGi software bundles installed and started.
Servers can be added to and removed from the domain while the system is running, without service interruption.
A domain has an associated domain configuration, which is stored in a domain configuration directory. The domain configuration directory contains configuration for all servers in the domain and the OSGi software bundles that the servers run.
Individual servers do not store configuration locally except for security related details that they need to access the domain configuration directory.
All servers in the domain have read-only access to the domain configuration directory. When a server starts, it retrieves configuration data from the domain configuration directory and loads it into memory for use at runtime. The domain configuration directory is accessed using a shared file system or via the Domain Configuration Web server.
Domain servers can access the domain directory in one of the following ways:
Through a shared file system
Through HTTP
The Administration Console provides an interface for the domain configuration. With the Administration Console you manage the domain servers, the OSGi software bundles installed in the domain, and the data stored in the domain configuration directory. The Administration Console gives you read and write access to the domain configuration directory.
When running the Administration Console, it provides a Java Management Extension (JMX) interface for the domain configuration. It also provides an additional interface, whose type depends on Administration Console execution mode.
You can run the Administration Console in the following modes:
Web access mode (Web Administration Console)
Starting the Administration Console in Web access mode enables its graphical browser-based user interface. It allows administrators to configure the domain from any computer with a browser and network access to the Web Administration Console server.
Standalone mode (Standalone Administration Console)
In standalone mode, the Administration Console runs as a graphical Java client application. You can run the standalone console only on the physical computer on which the Administration Console is installed.
Scripting mode (Scripting Engine)
In the scripting mode, the Administration Console runs a scripting engine accepting XML-based scripts. The scripts express JMX operations and attributes that you invoke to change Service Broker configurations.
When running the Administration Console, you access the domain configuration either through the front-end interface enabled by the specific mode chosen, or through the JMX interface in the back-end.
The Administration Console can be installed and run from any host that has access to the domain configuration directory. It can run on the same physical computer hosting one or more of the servers in the domain, however, Oracle recommends a dedicated physical computer for the Administration Console.
The domain type reflects what kind of software bundles are started on the domain servers and the role that the servers perform.
There are three domain types:
Signaling domain
Servers in the signaling domain run the artifacts associated with the Service Broker signaling tier only, that is SSUs, which primarily serves for network connectivity. Servers in the signaling domain are often referred to as signaling servers.
Processing domain
Servers in the processing domain run the artifacts associated with the Service Broker processing tier, that is OE, IMs, SMs, applications and mediators, which primarily serve a traffic processing and mediation function. Servers in the processing domain are often referred to as processing servers.
Unified domain
This domain combines the processing and signaling tier functions. Servers in the unified domain run the artifacts associated with both the signaling tier and processing tier.
Note:
If your signaling domain or unified domain implements SS7 connectivity, then the maximum number of servers in the domain is as follows:For SIGTRAN connectivity, the domain consists of up to sixteen servers.
For TDM connectivity, the domain consists of up to two servers.
This section describes the domain topologies that you can use for Service Broker deployments. Domain topologies differ by the level of performance, high availability and service availability that they provide.
A multi-domain topology implements two types of domains:
A signaling domain, running SSUs and serving for network connectivity.
A processing domain, running stateful components such as IMs, OE, mediators and applications, and serving for traffic processing and mediation function.
The signaling domain includes two or more servers, providing availability, therefore if one server fails, other servers handle the new calls.
Components running on the processing servers are stateful, maintaining and distributing state information across servers in the domain, therefore services are continuously delivered without disruption. See the discussion about service continuity in "Service Mode" for more information.
Figure 1-2 shows a multi-domain topology with one signaling domain and one processing domain, and the session state distributed across the processing servers.
The signaling domain and processing domain interact, and propagate protocol events across the tier and domain boundaries.
Note:
If your system connects to a number of different networks, consider administrating the connectivity to each network separately, by implementing a different signaling domain to connect each of the networks.The single-domain topology implements only one domain, a unified domain, with multiple servers, wherein each server performs the role of both the signaling tier and processing tier. Multiple servers in the domain serve for availability.
Figure 1-3 shows a single-domain topology with one unified domain, wherein servers perform the role of both the processing and signaling tiers.
When implementing a single-domain deployment and creating a unified domain, you need to set the domain's service mode. See "Service Mode" for more information.
The components running in the processing tier are stateful, that is they maintain session information. They retrieve and store session state in an in-memory storage.
When state information is maintained and distributed across the domain servers, service continuity is assured: on server failure, functioning servers continue to retrieve and process all messages, including those stored in the in-memory state of the failed server. Therefore, if a server fails, another server continues to handle existing calls, providing service continuity.
Whereas a processing domain always implements service continuity, in a unified domain you can choose whether to turn service continuity on or off. Turning service continuity off improves performance significantly. When creating a unified domain, select the service mode:
Service availability: service continuity is turned off
Service availability and continuity: service continuity is turned on
A multi-domain deployment with separate processing and signaling domains always provides service continuity. A single-domain deployment with one unified domain may be configured to either provide service continuity or not.
In production systems, for best performance, Oracle recommends using the single-domain topology (described in "Single-Domain Topology") wherein service continuity is turned off, as shown in Figure 1-4. In this deployment, servers maintain state information, however the state information is not distributed across servers.
Another alternative is to implement the multi-domain topology (described in "Multi-Domain Topology"), that implements service continuity out of the box, as shown in Figure 1-5.
In a multi-domain deployment you can create multiple signaling domains (each connecting to a different network), and multiple processing domains, each supporting a different processing functionality. In complex Service Broker deployments, you may find administering different network connections and different functionality in separate domains easier.
Note:
In a production system, each domain that you install should include at least two servers, for redundancy and availability purposes.You can use a test and evaluation system to familiarize yourself with Service Broker, for integrations, for proof of concept labs, and for training purposes. A test and evaluation system does not have the same requirements for availability, service continuity and performance that a production system has.
A test and evaluation system is a basic, single-domain deployment. A test and evaluation deployment comprises one unified domain with a single server, or two servers at most, each preforming the role of both signaling tier and processing tier.
WARNING:
Never use a test and evaluation system in production.
Figure 1-6 shows a test and evaluation deployment with one domain, wherein one server perform 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 the service continuity turned on.
Scalability is the ability of a system to provide throughput in proportion to, and limited only by, available hardware resources. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.
The growth of computational power within one operating environment is called vertical scaling. Horizontal scaling is leveraging multiple systems to work together on a common problem in parallel.
Service Broker scales both vertically and horizontally. Scaling options differ according to whether you are scaling the processing tier or the signaling tier.
The processing tier of a Service Broker deployment includes two or more servers, employing an N+1 high availability schema, where several processing servers are grouped together to share the workload. The Service Broker processing tier can increase its throughput by adding a new processing servers to the processing domain. You can add a new processing server on either of the following:
A new physical host computer (horizontal scaling)
A physical computer that already host another processing servers (vertical scaling)
As in the processing tier, the signaling tier should include at least two servers, and more servers can be added as needed.
However, there are a few exceptions when implementing connectivity to SS7 networks, as follows:
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. Note that in the case of a unified domain, your processing tier is also limited to the same number of servers.
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 that in the case of a unified domain, your processing tier is also limited to the same number of servers.
To work around the limitations implied by the SS7 connectivity, Oracle recommends that you deploy a separate signaling domain to implement connectivity to the SS7 network. This way connectivity to other signaling networks is not affected, and servers can be added to the other signaling domain as needed.
To increase the throughput of SS7 connectivity in the case of TDM, you can also add another pair of signaling servers in a separate signaling domain.
Before you start an installation, you have to plan your Service Broker deployment.
Planning your deployment includes choosing a domain topology and defining each of the domains. That is the number of servers in the domain and additional domain considerations as described in "Setting Up a Domain".
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
