2 Introducing Communication Service Features

This chapter presents a high level introduction to Oracle Communications Services Gatekeeper's communication service features.

Overview

All application service request data flows through Services Gatekeeper using communication services. A communication service consists of a service type (Multimedia Messaging, Terminal Location, etc.), an application-facing interface (also called a “north” interface), and a network-facing interface (also called “south” interface).

For complete information on supported communication services, see Communication Service Reference, another document in this set.

Some functionality is common to all communication services. This functionality includes:

• Service Level Agreements and Policy Enforcement

• Service Level Agreements and Network Protection

• Traffic Security

• Events, Alarms, and Charging

• Statistics and Transaction Units

Service Level Agreements and Policy Enforcement

A set of service level agreements (SLAs) between the application service provider and the Services Gatekeeper operator governs all application access to Services Gatekeeper's communication services. Services Gatekeeper uses a two-tiered account grouping system to categorize application services and their providers and to simplify the creation and maintenance of SLAs:

• Service Provider Group

• Application Group

For more information on the account system, see "The Administration Model", a section in this document. Services Gatekeeper provides standard SLAs for both service provider and application groups. Custom SLAs for both types can also be created.

These SLAs define whether a member of a service provider group or application group:

• Has access to a particular communication service. Access to a service can be regulated down to supported methods and parameters

• Participates in any quality of service (QoS) agreements such as:

  • Specifying the guaranteed number of requests a service provider may send through a particular communication service in a given period of time. These guarantees may be modulated by:

    • Time of Day/Day of Week

    • Rate (Invocations per time period)

    • Quota (Aggregated number of invocations)

For a more detailed look at Service Provider and Application SLA structure, see the discussion on managing SLAs in Accounts and SLAs Guide. For a communication service-focused description, see Communication Service Reference. These books are separate documents in this set.

SLA enforcement for communication services is provided by the Interceptor Stack. It is also possible to create extended rules that are evaluated using external policy engines. These rules represent operator specific policies defined by the operator and implemented by Oracle or a selected partner

A simplified version of the flow is illustrated in Figure 2-1 below.

Figure 2-1 Simplified Communication Service Policy Execution Flow

Network-triggered requests are also evaluated using the Interceptor Stack.

Service Level Agreements and Network Protection

There are also SLAs that help protect the underlying network node by setting priorities for sending requests on the level of a particular service provider group, or of Services Gatekeeper as a whole. Depending on the status of the underlying network, traffic can be throttled and shaped. If a particular node is overloaded, lower-priority traffic can be rejected altogether. For general information on these traffic-based (called Node) SLAs, see "The Administration Model" in this document. For more detailed information, see the “Defining Global Node and Service Provider Group Node SLAs” chapter in Accounts and SLAs Guide. Services Gatekeeper provides standard SLAs for global and service provider nodes. Custom SLAs for the Global Node type can also be created.

Traffic Security

For SOAP-based Web Services interfaces, Services Gatekeeper uses special SOAP headers to authenticate service provider applications. These headers are documented in the WS-Policy section of each interface's WSDL file. Processing is managed by WebLogic Server's WS-Security, which supports plaintext or digest passwords, X.509 certificates, or SAML tokens for authentication. To guarantee the confidentiality of communication between Services Gatekeeper and the application, traffic can be encrypted - fully or partially - using W3C's standard XML encryption. Message integrity can be assured using the W3C XML digital signature standard. The WS-Policy section of the published WSDL for each interface describes if and how either of these standards is being used. For more information on WebLogic Server's capabilities, see Oracle® Fusion Middleware Securing Oracle WebLogic Server at:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13707/toc.htm

Access to a particular communication service is based on the two types of SLAs discussed in "Service Level Agreements and Policy Enforcement".

For RESTful Web Services interfaces, Services Gatekeeper supports HTTP basic authentication, using username/password. SSL is required.

For general information about HTTP basic authentication, see

http://www.ietf.org/rfc/rfc2617.txt

In addition, if the underlying network node provides an authentication interface, Services Gatekeeper protocol plug-ins can register with it and be authenticated, making the request's transfer to the network secure. This capability is highly dependent on the protocol and the specific implementation in the node and the plug-in.

Events, Alarms, and Charging

All Services Gatekeeper modules can produce general events, alarms and charging events. General events are expected system occurrences that are of importance to the operator but do not need corrective action. Alarms are system occurrences that are unexpected and may require corrective action. Charging events are the basis for CDRs, the records that provide the information needed to charge for services. CDRs are written only when the transaction that brackets the request's flow through the Network Tier commits. For more information on events and charging, see “Events, Alarms, and Charging” in Communication Service Reference. For more information on alarms, see Alarm Handling Guide. These books are separate documents in this set.

Statistics and Transaction Units

Usage costs for Services Gatekeeper are based on a maximum allowed rate (measured in transaction units per second or TUPS) during a specific time period per 24-hour interval. Two TUPS rates are measured:

• Base Platform (the more general rate)

• Oracle Module (which covers only Services Gatekeeper-supplied communication services)

For more information on how these statistics are gathered, see Licensing Guide, another document in this set.