|
|
The following chapter provides an overview of Oracle Communications Services Gatekeeper’s software architecture, including:
Oracle Communications Services Gatekeeper provides a robust, secure and highly performant container optimized for the task of running communication services. Communication services are specialized components that allow telephony network operators to provide Internet-based application developers with a powerful but simple way to access the operator’s network services. Out of the box, Oracle Communications Services Gatekeeper supplies communication services providing access to such network capabilities as messaging, call control, terminal location, and presence. Extending the provided communication services or creating entirely new ones, based on the specific needs of the operator’s circumstances, is made easy with the supplied Platform Development Studio. Built on Oracle WebLogic Server 10.3, Oracle Communications Services Gatekeeper is closely aligned with JEE standards and tightly integrated with Oracle Communications Converged Application Server.
Communication services are components that run in the Oracle Communications Services Gatekeeper container. They provide the main functionality of Oracle Communications Services Gatekeeper, exposing network capabilities to Internet based applications in a form that is easy to use and manage. All traffic in Oracle Communications Services Gatekeeper is processed through these services. A communication service consists of a service facade, consisting of an application-facing interface which communicates with the application and a security layer, which handles authentication and a service enabler, consisting of a processing layer, where requests are validated, evaluated according to service level agreements (SLAs), and routed, and a protocol translation layer, which communicates with the underlying network element. A more detailed description can be found in Introducing Communication Services.
Oracle Communications Services Gatekeeper provides a container that is highly optimized for running communication services, the Oracle Communications Services Gatekeeper components that provide the interface between Internet-based applications and the functionality of the underlying telephony network. The container leverages the many standard container services that Oracle WebLogic Server 10.3 provides, but adds a number of services designed for the specialized needs of communication services and Oracle Communications Services Gatekeeper generally. See Figure 3-2 and Figure 3-3 below for some typical uses of these services. They include:
Manages cross-cluster bandwidth allocation, and supports geo-redundant installations. In the context of quota and rate SLAs, it also maintains an historical perspective on usage patterns.
Wraps the policy engine from older versions, which can still be used
Broadcasts events and manages their translation into charging data and alarms, as necessary
Provides transparent access to data storage using distributed caching and the database
Broadcasts events among modules and servers in the cluster
Stores largely read-only data, such as configuration information
Initializes the Orbacus ORB and makes it the default for the system. Can be disabled for systems that do not connect to Parlay Gateways
Provides support for geo-redundant installations
Provides SNMP service for alarms
The examples below show interactions between the Parlay X 2.1 Short Messaging to SMPP communication service and selected container services.
In production mode, communication services are typically deployed in two clustered tiers, an Access Tier and a Network Tier, separated, if desired, by a firewall. In a single physical site installation, this corresponds to a single WebLogic Server administration domain. Each communication service is deployed in its own EAR file, one per tier.
| Note: | Some EARs may contain either multiple application-facing interfaces (Parlay X 2.1 Short Messaging and Binary SMS/SMPP) or multiple network plug-ins (Parlay X 2.1 Third Party Call/SIP and INAP) that support the same basic service capability. |
Single communication services can be installed or removed without having an impact on other communication services. If no interfaces are changed, existing communication services can be upgraded while traffic is running. This process is called a hitless upgrade and tracks traffic so that in-flight requests can be completed before the older version is undeployed. Communication services may be deployed selectively, as needed.
|