This chapter is a high level introduction to Oracle Communications Services Gatekeeper communication services. For more detailed information on communication service components, see ”Understanding Communication Service Components” in Services Gatekeeper Extension Developer's Guide.
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).
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, OneAPI RESTful interfaces, and 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 WebLogic 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 operations and management (OAM) operations, to register a description of the types of data it is interested in such as delivery notifications, incoming messages, 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.
The following steps describe the application-initiated traffic flow. Steps 1-3 are optional.
An application establishes an HTTP session using the WebLogic Session Management Web Service in the facade layer. For details on creating a session see ”Using Sessions and Session Persistence” in Fusion Middleware Developing Web Applications, Servlets, and JSPs, for WebLogic Server.
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.
The session is valid until the application terminates it or an operator-established time period has elapsed.
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 or OAuth 2.0 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 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
http://www.w3.org/TR/xmlenc-core/
For information about W3C XML digital signature standard, see
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
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.
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.
The request is sent to the Plug-in Manager.
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.
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.
The request is passed to the network.
When the network node acknowledges the request, charging data about the completed request is recorded.
The transaction commits.
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 the discussion on "Managing and Configuring the Tier Routing Manager" in Services Gatekeeper System Administrator's Guide for more information.
The following functionality is common to all communication services:
Service level agreements related to policy enforcement
Service level agreements related to network protection
Traffic security
Events, alarms, and charging
Statistics and transaction units
For information about service level agreements, see Services Gatekeeper Accounts and SLAs Guide.
For information about traffic security for SOAP-based interfaces to the communication services, see Overview of Exception Handling Using SOAP Faults and other SOAP-related chapters in Oracle WebLogic Server Understanding Security for WebLogic Server.
RESTFul Web Services to the communications services use either HTTP basic or OAuth 2.0 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:
http://www.ietf.org/rfc/rfc2617.txt
OAuth 2.0 is a draft open source Web authorization protocol developed by the Internet Engineering Task Force (IETF). For detailed specifications and more information see the IETF web site:
http://tools.ietf.org/wg/oauth/
For information about Services Gatekeeper support for OAuth 2.0 authentication, see "Services Gatekeeper OAuth 2.0 Authorization and Resource Servers".
For general information about events, alarms, and charging, see "Events, Alarms, and Charging".
For information about statistics, see the "Statistics" sections in the individual chapters in this guide.
For communication services that access Session Initiation Protocol (SIP) networks, Services Gatekeeper connects applications to SIP-based functionality by using the Oracle Communications Converged Application Server product, which is included with Services Gatekeeper. Converged Application Server is collocated with Services Gatekeeper in the network tier.