This chapter explains the Oracle Communications Services Gatekeeper software architecture for running communication services on networks that require traditional telephony protocol.
Services Gatekeeper is built on the Oracle WebLogic Server 12c product, is closely aligned with JEE standards, and tightly integrated with Oracle Communications Converged Application Server (Converged Application Server). Services Gatekeeper communication services provide access to network capabilities such 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 by using the Platform Development Studio. Services Gatekeeper provides a secure container for running communication services.
When used with traditional telephony networks, all traffic in Services Gatekeeper is processed through communication services. As shown in Figure 1-1, each communication service consists of:
A service facade layer that includes an application-facing interface used to communicate with the application, a security layer for authentication, and the XML Serialization to convert the data into a form that can be readily transported.
A service enabler layer that includes a processing layer and a protocol translation layer. Transactions begin in the processing layer, where requests are validated according to service level agreements (SLAs) and are then routed to a protocol translation layer, which communicates with the underlying network element.
For details on administering and deploying communication services see Services Gatekeeper System Administrator's Guide.
For details on the service plug-ins available for you to use in custom communication services see Services Gatekeeper Application Developer's Guide.
For information on creating your own custom communication services see Services Gatekeeper Extension Developer's Guide.
Figure 1-1 Communication Service Components
When used with traditional telephony networks, Services Gatekeeper provides a container in which communication services are run. The container leverages the standard container services that Oracle WebLogic Server provides, and adds services specific to communication services and Services Gatekeeper generally. Container services include:
Budget
Manages cross-cluster bandwidth allocation, and supports geographically redundant installations. In the context of quota and rate SLAs, it also maintains historical data on usage patterns.
Event Data Record (EDR)
Broadcasts events and manages their translation into charging data and alarms, as necessary.
Storage
Provides access to data storage using distributed caching and the database.
Core
Performs initial setup tasks.
Event Channel
Broadcasts events among modules and servers in the cluster.
Configuration
Stores mostly read-only data, such as configuration information.
Statistics
Generates system statistics.
Geographic Redundancy
Provides support for geographically redundant installations.
Plug-in Manager
Manages the service enabler processing layer.
SNMP
Provides SNMP service for alarms.
Account
Manages SLAs and sessions.
Figure 1-2 and Figure 1-3 show the interactions between the Parlay X 2.1 Short Messaging/SMPP communication service and selected container services as traffic flows through the service enabler layer of the communication service. Figure 1-2 shows this interaction for application-initiated traffic and Figure 1-3 shows this interaction for network-triggered traffic.
Figure 1-2 Interaction with Container Services for Typical Application-Initiated Traffic
Figure 1-3 Interaction with Container Services for Typical Network-Triggered Traffic
When used with traditional telephony networks, communication services are typically deployed in two clustered tiers, an Access Tier and a Network Tier, typically separated 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 EAR files may contain either multiple application-facing interfaces (such as the Parlay X 2.1 Short Messaging and Binary SMS/SMPP communication services) or multiple network plug-ins (such as the Parlay X 2.1 Third Party Call/SIP communication service) that support the same basic service capability.
A communication service can be installed or removed without impacting 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 of the communication service is undeployed. Communication services may be deployed selectively, as needed.