Skip Headers
Oracle® Communications Services Gatekeeper Communication Service Guide
Release 5.0

Part Number E21362-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

1 About Communication Services

This chapter presents a high level introduction to Oracle Communications Services Gatekeeper communication services.


All application service request data flows through Services Gatekeeper communication services. A communication service consists of a service type, such as Multimedia Messaging, Terminal Location, and so on, an application-facing interface (also called a "north" interface), and a network-facing interface (also called "south" interface).

How They Work

Communication services are separated into two functional layers: the service facade and the service enabler. The service facade contains the application-facing interfaces and manages interactions with applications. The service enabler contains the mechanisms necessary for communicating with the underlying network nodes.

Application-initiated requests (also called mobile terminated, or MT requests) enter through the service facade. A facade comprises a set of application-facing interfaces of a particular type. Services Gatekeeper supplies facades for traditional SOAP Web Services interfaces, RESTful interfaces, and, in three cases (MM7, SMPP, and UCP) native telephony interfaces. There is also a facade specifically designed to work with the Oracle Service Bus, for SOA-style installations.

After the requests have been processed by the service facade, they are sent to the service enabler by using Remote Method Invocation (RMI). The service enabler layer manages service authorization and policy enforcement, charging, and traffic throttling and shaping. The enabler translates the request into a form appropriate for the underlying network node.

Although the operator may choose instead to run in a sessionless mode, by default Services Gatekeeper requires that applications (except those using native telephony interfaces) acquire a Services Gatekeeper session before sending request traffic. Applications do this using the Session Manager interface appropriate for their facade type. The Session Manager returns a session ID, which the application adds to the header of all its requests. Services Gatekeeper can use the session ID to keep track of all the traffic that an application sends for the duration of the session. Sessions allow correlation among sequences of operations. They are not used for authentication

Network-triggered (also called mobile originated, or MO) traffic enables applications to receive data from the telecom network. To do so, the application must first send a request to Services Gatekeeper, or have the operator perform the equivalent task using operation, administration, and maintenance (OAM) operations, to register a description of the types of data it is interested in – delivery notifications, incoming messages, etc. – and any criteria that the data must be meet to be acceptable. For example, an application might specify that it is only interested in receiving incoming SMS messages that are addressed to the 12345 short code and that begin with the string blue.

Typical Application-Initiated Traffic Flow

The following steps describe the application-initiated traffic flow. Steps 1-3 are optional.

  1. An application establishes a session using the Session Management Web Service in the facade layer.

  2. A session is established, and the session ID is returned to the application. After the application has been established, it may access multiple communication services across the cluster transparently.

  3. The session is valid until the application terminates it or an operator-established time period has elapsed.

  4. A request for a particular operation, usually transported over Secure Sockets Layer (SSL), enters at the application-facing interface in the facade layer, either directly from the application, or, if the particular installation uses an Oracle Service Bus, from the Oracle Service Bus. The application-facing interface is implemented as a SOAP-based Web Service or a RESTful Web Service. Requests using the RESTful requests are authenticated with HTTP basic authentication using a user name and password. SOAP-based Web Service requests are authenticated using WebLogic Server WS-Security, which supports plain text or digest passwords, X.509 certificates, or SAML tokens.

    All requests are authenticated in this manner, whether or not the application uses the session mode.

    In addition, SOAP-based requests may be further secured through encryption using the W3C's standard XML encryption and through digital signatures using the W3C XML digital signature standard. The particular security requirements of the installation are specified in the WS-Policy section of the operator-published WSDL file.

    For information about W3C's standard XML encryption, see

    For information about W3C XML digital signature standard, see

    It is possible to use the appropriate standard Parlay X 2.1 or 3.0 WSDL to create SOAP-based requests, but the developer would then be required to ascertain the appropriate security type from the operator and insert the information manually.

  5. The request is serialized and passed on to the service enabler over RMI.

    From this point on, requests that enter the communication service using the SOAP Service Facade and those using the RESTful Service Facade use the same service enablers. SLA construction, CDRs, EDRs, alarms, and so forth are same for the SOAP-based requests as they are for the RESTful requests of the same type.

    The entrance point for the service enabler marks the beginning of the application-initiated transaction.

  6. The request is sent to the Plug-in Manager.

  7. The Plug-in Manager invokes the Interceptor Stack to evaluate the request. The Interceptor Stack is a flexible set of chained evaluation steps that:

    • Validates the request

    • Enforces a range of policy decisions based on SLAs and possibly additional rules

    • Performs any necessary data manipulation

    • Routes the request to an appropriate protocol translation module (a network plug-in): Routing can be done on a wide variety of parameters.

    If a request fails because of an unavailable module, an interceptor retries the request using one of the remaining eligible modules.

  8. The request is sent to the network plug-in to be translated into the protocol suitable for the underlying network node. All state information required by the underlying network node is stored within the network plug-in.

  9. The request is passed to the network.

  10. When the network node acknowledges the request, charging data about the completed request is recorded.

  11. The transaction commits.

Typical Network-Triggered Traffic Flow

To receive network-triggered traffic, an application must indicate to Services Gatekeeper that it is interested in receiving traffic from the network. It does this by registering for (or subscribing to) notifications, either by sending a request to Services Gatekeeper or by having the operator set up the notification using OAM operations.

For example, the application could send Services Gatekeeper a request to begin receiving SMS messages from the network, indicating that it is only interested in messages that are sent to the address 12345 and that begin with the string blue. SOAP-based requests indicate the URL of the Web Service that the application has implemented to receive these notifications back from Services Gatekeeper.RESTful requests indicate the channel to which the notifications should be published.

The registration for notifications is stored in the appropriate network plug-in, which in most cases passes it on to the underlying network node. In certain cases the Services Gatekeeper operator must do this manually. When a matching SMS message reaches the plug-in from the network, the plug-in sends the message to the Plug-in Manager, which invokes the Interceptor Stack for evaluation. Then, using RMI, the final interceptor passes the notification, along with the appropriate location from the registration, to the facade layer, which sends it on either to the application, the channel, or to the Oracle Service Bus.

Installations that include multiple facade layers (for example, both RESTful and SOA) can be set up to use the same service enabler layer. Special configuration is required in such installations to route network-triggered traffic to the appropriate facade layer. See “Managing and Configuring the Tier Routing Manager” in System Administrator's Guide for more information.

Common Features

The following functionality is common to all communication services:

For information about service level agreements, see Accounts and SLAs Guide.

For information about traffic security for SOAP-based interfaces to the communication services, see Oracle Fusion Middleware Securing Oracle WebLogic Server at:

RESTFul Web Services to the communications services use HTTP basic authentication with a user name and password. SSL is required. For information about basic HTTP authentication, see HTTP Authentication: Basic and Digest Access Authentication at:

For general information about events, alarms, and charging, see Appendix A, "Events, Alarms, and Charging."

For information about statistics, see the "Statistics" sections in the individual chapters in this guide.

Connectivity to SIP Network Infrastructure

For communication services that access Session Initiation Protocol (SIP) networks, Services Gatekeeper connects applications to SIP-based functionality by using Oracle Converged Application Server. Converged Application Server is collocated with Services Gatekeeper in the network tier.