2 Software Architecture Overview

This chapter explains the Oracle Communications Services Gatekeeper's (Services Gatekeeper) software architecture.

Overview

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.

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 Oracle Communications Services Gatekeeper Communication Service Guide, another document in this set.

Figure 2-1 Communication service structure

Description of "Figure 2-1 Communication service structure"

Container Services

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 2-2 and Figure 2-3 for some typical uses of these services. They include:

• Budget

  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

• Storage

  Provides transparent 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 largely read-only data, such as configuration information

• Statistics

  Generates system statistics

• Geo-Redundancy

  Provides support for geo-redundant installations

• Plug-in Manager

  Manages the processing layer

• SNMP

  Provides SNMP service for alarms

• Account

  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.

Figure 2-2 Container Services in Typical Application-Initiated Traffic

Description of "Figure 2-2 Container Services in Typical Application-Initiated Traffic "

Figure 2-3 Container Services In Typical Network Triggered Traffic

Description of "Figure 2-3 Container Services In Typical Network Triggered Traffic"

Deployment Model

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.