|Oracle® Communications Services Gatekeeper Concepts Guide
Part Number E16613-02
The following chapter provides an overview of Oracle Communications Services Gatekeeper's software architecture.
Services Gatekeeper is built on Oracle WebLogic Server 11g, closely aligned with JEE standard, and tightly integrated with Oracle Communications Converged Application Server. Services Gatekeeper supplies communication services providing access to such network capabilities as messaging, audio call, call control, terminal location, terminal status, presence information, and device capabilities. You can easily extend these communication services or create new ones with the Platform Development Studio.Services Gatekeeper provides a secure, high-performance container for running communication services.
All traffic in Services Gatekeeper is processed through these communication services. A communication service consists of:
A service facade, that includes an application-facing interface to communicate with the application, and a security layer for authentication.
A service enabler, consisting of a processing layer where requests are validated according to service level agreements (SLAs), and routed.
A protocol translation layer, which communicates with the underlying network element.
Communication services are described in detail in Communication Service Reference, another document in this set.
Services Gatekeeper provides a container that is highly optimized for running communication services. The container leverages the many standard container services that Oracle WebLogic Server provides, but adds a number of services designed for the specialized needs of communication services and Services Gatekeeper generally. See Figure 3-2 and Figure 3-3 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.
Event Data Record (EDR)
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
Performs initial setup tasks
Broadcasts events among modules and servers in the cluster
Stores largely read-only data, such as configuration information
Generates system statistics
Provides support for geo-redundant installations
Manages the processing layer
Provides SNMP service for alarms
Manages Service Level Agreements and sessions.
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.
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.