Welcome to Oracle Communications Services Gatekeeper™ 4.0. As the leading Telecom Service Access Gateway, Gatekeeper integrates telecom network technologies with Web Services to provide a reliable framework for developing and deploying highly available, scalable, and secure telecommunications applications and features. Gatekeeper's seamless integration of disparate, heterogeneous platforms and applications enables your network to leverage existing software investments and share the carrier-class services and data that are crucial to building next-generation telecommunication applications.
For version 4.0, Gatekeeper’s development has been driven by two main concerns:
This chapter describes at a high level what new features in Gatekeeper have been created to support these goals. In addition the following topics are covered:
Version 3.0 marked a substantial change to the basic architecture of Gatekeeper. Version 4.0 builds on that change, preparing the way for future developments.
WebLogic Server 10.0 MP1
In version 4.0, Gatekeeper has been moved to WebLogic Server 10.0, MP1. This has multiple benefits for the Gatekeeper platform, including:
Support for Java Enterprise Edition v5
Unicast for cluster communication. Unicast is easier to configure and uses fewer network resources than multicast
Support for Oracle Fast Connection Failover
Cluster-wide timers
Upgrades of Web Services Security Standards
WS-SecureConversations 1.0 -> 1.3
WS-Security 1.0 -> 1.1
WS-SecurityPolicy 1.2
WS-Trust 1.0 -> 1.3
Enhanced Deployment Model
In version 3.0, Gatekeeper was deployed as a single large EAR file. Making changes required editing the EAR, which was cumbersome. In addition, platform-wide services were stored in the same EAR as the components that implemented network integration logic (Communication Services), tying them to the Gatekeeper classloader and lifecycle. This has been changed in version 4.0
Platform-wide services (Container Services) are integrated into WebLogic Server itself as Server Services. Their lifecycle is now tied to the lifecycle of the container, and they belong to the container’s classloader. The container itself is hardened and tuned for the needs of telecom usage.
Each Communication Service is packaged in its own EAR, making it much simpler to deploy and un-deploy individual services, aligning the system more closely with the standard JEE application deployment model.
Production Upgrade
Gatekeeper 4.0 supports a fully automated upgrade model, supporting hitless (zero down time) upgrades
Most Communication Services can be upgraded dynamically, with the older network translation component (the plugin) keeping track of in-flight traffic and retiring gracefully only after that traffic has been processed, while new traffic is sent to the updated version.
Supported for HTTP-based, Parlay, SMPP, SIP, and LDAP plug-ins
Not supported for INAP
Platform-based Container Services can be upgraded using the WLS rolling upgrade method.
Components are now versioned, and versioning information is now propagated through management interfaces, accounting records, logs, and so forth.
All upgrades can be managed through the Administration Server.
Subscriber-Centric Policy
Previous versions of Gatekeeper supported fine-tuned policy control for service providers and applications. Version 4.0 introduces the capability of creating a similar system for an operator’s subscribers
Provides a mechanism for highly granular subscriber personalization and protection.
Adds subscriber SLAs, which can be enforced on a per subscriber level.
Allows subscriber-centric throttling, based on the cluster-wide budget service.
CORBA Removal
Previous versions of Gatekeeper required the use of the ORB as a basic infrastructure component. This is not the case in version 4.0
All OAM methods are now pure JMX-based MBeans
Gatekeeper can be run in a completely ORB-free mode
CORBA only used at the Communication Services level, for Parlay Gateway connectivity
New Account Module
Version 4.0 represents a major update in the handling of partner account information.
SLA management (including editing) from the Adminstrative Console
CORBA removed
Aligned with CSS and the Java security model
The on-boarding account structure documented in the security contex of the thread
Database access no longer necessary from the Access Tier, increases firewall security
PRM
WS-Security support
No sessions required for 4.0 clients
Stateless WS to JMX bridge
Multiple deployment options
Version 2.2 and 3.0 backwards compatible
Respond to Customer Feedback
The updated design of Gatekeeper version 4.0 also includes multiple features requested by customers, in both the area of usability and extensibility.
Usability
The task of managing a service access gateway is inherently complex, but version 4.0 has a number of features designed to ease the process.
Plugin Instantiation
New Plugin hierarchy
New Plugin Service module contains the plugin definition, including a mapping to a specific protocol. It is also responsible for aspects of the instance’s lifecycle
New Plugin Instance is a single runtime instance of a Plugin Service
Instances can be added and provisioned at runtime, without redeployment
Each plugin instance can have a separate configuration
Out of the box installation creates no instances by default, saving on resources
Extension APIs to cover this new hierarchy
Sessions Optional
System-wide setting to enable clients to authenticate with the Gatekeeper using only WS-Security.
Sessions can be used to hold client identity when WS-Security is disabled
Sessions are necessary in the context of Geo-Redundancy
SMPP
Support for multiple SMPP BINDs
Dynamically configurable pool of connections for each plugin instance
Supported for Transmitter, Receiver, and Transceiver
Distinct pool sizes can be set up
Optional per connection window size
Support for concatenation of segmented messages (network-triggered) in the plugin.
OAM
Based on standard MBeans, available through JMX. No CORBA
Verbose description of every method argument
Published, JavaDoc’ed API
ObjectName Conventions
Customization and Extensibility
Because all networks are different, being able to customize and extend Gatekeeper to tune its behavior is crucial.
Service Interceptors
Previous versions of Gatekeeper relied on a Policy Engine to make enforcement decisions. This release introduces an entirely new mechanism designed to be both very powerful and easily extensible.
Interceptors have full control over all traffic flow: application-initiated and network-triggered
The Interceptor Stack represents all out of the box traffic processing: validation, policy enforcement, and routing
The Policy Engine is still available via the Interceptor Stack if desired
The order of processing in the Stack can be easily changed
There is a rich SPI for creating new interceptors
Interceptors are deployed in their own EAR
Platform Development Studio
The Extension Toolkit that was shipped with version 3.0 has been extended and enlarged, and is now called the Platform Development Studio.
The Eclipse Wizard has been updated to reflect the new architecture
A full range of scripts, ANT tasks, and code samples has been added
The Unit Test Framework has been brought forward
The Platform Test Environment, formerly known as GTool, and offered only through Dev2Dev, has been substantially upgraded and extended. It is now a part of the product. It includes tools for accessing all aspects of Gatekeeper, including an MBean browser, JMS listeners, database table browsers, and much more, as well as a rich testing enviroment, including test clients and network simulators. It also easily extensible.
Proxy Communication Service
The SOAP-to-SOAP Communication Services function allows operators to expose SOAP-based Web Services requests of any kind to the rigorous monitoring, routing, and resource protection facilities of Gatekeeper, even if the data itself is not being transported by Gatekeeper’s standard Communication Services.
Generated and deployed from WSDLs using the Eclipse Wizard. No development effort is needed.
Exposes existing operator SOAP resources without having to code a line
Can supports both application-initiated and network-triggered traffic.
Provides:
Resource protection
Resource monitoring
Routing
Health monitoring
Load balancing
Subscriber Data Access
In addition to the Subscriber-Centric Policy mechanism mentioned above, Gatekeeper offers a new Subscriber Profile Communication Service that provides LDAP access
Applications can access subscriber data, within bounds defined by operator constructed filters
Uses an efficient connection pool to manage access
Supported Interfaces
Gatekeeper 4.0 has support for a number of application-facing interfaces. The following communication services (application-facing interfaces with related network plugins) are included in this release, including three call control services built on the Parlay X 3.0 standards, which allow multiple functionalities to interact within the same call session. All of these services take advantage of the enhanced version 3 architecture. They include:
Parlay X 3.0 Audio Call connecting to Parlay 3.3
Parlay X 3.0 Third Party Call connecting to Parlay 3.3
Parlay X 3.0 Call Notification connecting to Parlay 3.3
Parlay X 2.1 Third Party Call connecting to INAP and SIP
Parlay X 2.1 Call Notification connecting to SIP
Parlay X 2.1 SMS connecting to SMPP 3.4
Extended Web Services Binary SMS connecting to SMPP 3.4
Parlay X 2.1 MMS connecting to MM7
Parlay X 2.1 Terminal Location connecting to MLP3.0/3.2
Parlay X 2.1 Presence connecting to SIP
Extended Web Services WAP Push connecting to PAP
Extended Web Services Subscriber Profile connecting to LDAP
Changed Behavior and Naming Conventions
The changes in version 4.0 mean that some features and naming conventions from earlier versions have changed in significant ways.
The components previously called “traffic paths” are now called “communication services”.
Note:
These components were also call “exposure services” in the version 4.0 Technical Preview.
The “Extension Toolkit” has become the “Platform Development Studio”.
Parlay Gateway connectivity is not supported, except in the three Parlay X 3.0 call control services.
What used to be called the “Application Instance Group” is now called the “Application Instance” and functions essentially as an authentication username. It must be unique.
Some database tables have been changed. There are migration scripts provided as part of the post-installation phase of setting up Gatekeeper to bring installed databases up to current status.
Supported Configurations
The supported configurations have not changed since the writing of the Architectural Overview. For a complete listing, see the Technical Specifications chapter.
