1 About Service Level Agreements and Accounts

This chapter describes the Service Level Agreements (SLAs) and accounts that Oracle Communications Services Gatekeeper uses to define and enforce access to Services Gatekeeper and to the underlying telecommunication network.

About SLAs

An SLA is an XML document that defines and enforces access to Services Gatekeeper or, in the case of node SLAs, to the underlying network nodes. The core element in an SLA is a contract element whose child elements specify the details of the access. Examples of these details are the dates in which access is permitted, the number of requests to be processed within a certain time period, and the denial of the use of certain methods or parameter values to an application.

SLAs are associated with application service providers through a tiered system of accounts that are organized into account groups.

If you are using the Services Gatekeeper API management features through the Partner Manager and API Management Portal, Partner Portal, and Network Service Supplier Portals, most of the required SLA creation and management is transparent to you. See "Using Partner and API Management Portal to Manage SLAs and Accounts" for more information. If you are using the Service Gatekeeper features, then you need to follow the instructions in this book to create and manage SLAs.

You can load an SLA into a Services Gatekeeper implementation from the Administration Console console using the operations provided in the ApplicationSLAs section of the AccountService container service. See "Managing SLAs" for information about the AccountService operations to load and manage SLAs. These SLA load operations offer options for loading SLAs to all geo-redundant locations if your implementation uses this feature.

As an alternative, you can manage SLAs through external management systems integrated with Services Gatekeeper using the Services Gatekeeper Partner Relationship Management interfaces. For information about the Partner Relationship Management interfaces, see ”Partner Relationship Management Interfaces” in Services Gatekeeper Portal Developer's Guide. You can also manage SLAs programmatically using MBeans. For information about the ServicelevelAgreement MBean, see "All Classes" section of Services Gatekeeper OAM Java API Reference.

System SLAs

System SLAs have static XML Schema Documents (XSDs). The enforcement logic is already in place for these types of SLAs, except for the subscriber SLA, which requires custom subscriber policy logic. The following types of SLAs are system SLAs:

  • Global node SLA

  • Service provider group SLA

  • Application group SLA

  • Service provider node SLA

  • Subscriber SLA

Service provider group SLAs and application group SLAs define service provider and application access to Services Gatekeeper. See "Defining Service Provider Group and Application Group SLAs" for information about these types of SLAs and "Sample SLA XML File" for a complete example.

Node SLAs define access to the underlying network, either by service provider group or for Services Gatekeeper as a whole regardless of the service provider whose requests are being processed. See "Defining Global Node and Service Provider Group Node SLAs" for information about node SLAs.

Subscriber SLAs define subscriber policy and manage subscriber access. The implementor defines the subscriber policy logic using the Platform Development Studio. For more information, see ”Using Policies to Manage Subscribers” in Services Gatekeeper Extension Developer's Guide.

Custom SLAs

Custom SLAs are enforced by customized logic for which the XSDs are developed using the Platform Development Studio. For information on custom SLAs and an example of one, see ”Custom Service Level Agreements” in Services Gatekeeper Extension Developer's Guide.

The following SLAs are custom SLAs:

  • Custom global SLAs

  • Custom service provider group SLAs

  • Custom application group SLAs

The custom logic that operates on data is provided in the SLAs and on data that comes with the request. The data in the SLA is formatted according to the SLA XSD, and the enforcement logic uses the Document Object Model (DOM) representation of the XSD to get the data in the SLA. The request can provide information such as application ID, application instance, service provider ID, application group ID, and service provider group ID.

Custom SLAs can be associated with application groups and service provider groups or be global. A custom global SLA is valid for all requests, regardless of which application group or service provider group the application that triggered the request.

About Accounts

Each service provider and application that uses the Services Gatekeeper application-facing interfaces must establish an account.

Service provider accounts, application accounts, and application instances have states that can be changed using the Administration console. This enables the administrator to take them out of service temporarily.

Accounts

There are two types of accounts:

  • Service Provider Account: Every service provider that has access to the operator's Services Gatekeeper facilities has a service provider account.

  • Application Account: Every application that has access to the operator's Services Gatekeeper facilities has an application account. Each application account is associated with a service provider account.

See "Managing Service Provider and Application Accounts" for information about creating and managing accounts.

Account Groups

For the purposes of SLA enforcement, accounts are organized into account groups. There are two types of account groups:

  • Service provider group

  • Application group

When you load an Application Group SLA or Service Provider Group SLA, you provide the identifier of the group with which the SLA is associated along with the SLA.

Following is an example of how a Services Gatekeeper administrator might use system SLAs to create three different service provider groups:

  • Bronze

  • Silver

  • Gold

Each of these service provider groups would be associated with different SLAs with different privileges regarding maximum throughput and Quality of Service (QoS parameters. When a new service provider is provisioned, the service provider is associated with the appropriate group based on, for example, the amount of network traffic the service provider is projected to generate. If the outcome is not what was predicted, the service provider account can be reassigned to another service provider group that has a different QoS parameter defined in its service provider SLA.

See "Managing Groups" for information about creating and managing groups.

Application Instances

In the context of SLAs in Services Gatekeeper, an application instance is an application service provider. Each application instance has a user name and password or certificate. Each application instance is associated with a service provider account / application account combination. An application instance must be in the ACTIVATED state to send traffic through Services Gatekeeper.

See "Managing Application Instances" for more information about creating and managing application instances.

Associations Among SLA Types, Account Types, and Group Types

Figure 1-1 illustrates the associations among the different account types, group types, and SLA types.

Figure 1-1 Service provider and application model with SLAs

Description of Figure 1-1 follows
Description of ''Figure 1-1 Service provider and application model with SLAs''

Note the following relationships:

  • An application instance, which uniquely identifies an account, belongs to an application account and a service provider account.

  • An application account belongs to a service provider account and an application group.

  • A service provider account belongs to a service provider group. A service provider account can have zero or more application accounts associated with it.

  • An application group is associated with an application group SLA and zero or more custom application group SLAs.

  • A service provider group is associated with a service level agreement on the service provider-level and may also be associated with a service provider node SLA and zero or more custom service provider group SLAs.

  • Zero or more custom global SLAs can be defined,. These are not associated with any special group or account, but are valid for all accounts and groups

  • A global node SLA is not associated with any special group or account, but is valid for all accounts and groups.

In light of the relationships between applications, groups, and SLAs, you configure them in the following order:

  1. SLAs

  2. Service provider groups

  3. Service provider accounts

  4. Application groups

  5. Application accounts

The process steps are listed in the section, "Typical SLA and Account Workflow".

Note that the IDs of service provider groups, application groups, application instances, and service provider accounts must be unique. The combination of service provider account and application account for an application instance must be unique.

The separation of accounts and groups provides a flexible way of defining service level agreements. Groups allow the Services Gatekeeper administrator to offer tiers of service at both the service provider and application level.

Application group SLAs and service provider group SLAs can be managed and enforced either locally in one site or across geo-redundant sites.

Typical SLA and Account Workflow

In a typical SLA and account workflow, you complete the following steps in that order:

  1. Create service provider and application groups that will correspond to the levels of service to be defined in the SLAs. See "Managing Groups" for more information.

  2. Define the set of service classes, expressed as SLAs, at both the service provider group level and the application group level. See "Defining Service Provider Group and Application Group SLAs" for more information.

  3. Define the set of node service classes, expressed as SLAs, at both the service provider node level and global node level. See "Defining Global Node and Service Provider Group Node SLAs" for more information.

  4. Associate the service provider group SLAs and application group SLAs with the groups. See "Managing SLAs".

  5. Load the global node SLA and service provider group node SLAs. See "Managing SLAs" for more information.

  6. Create a service provider account and associate it with the appropriate service provider group. See "Managing Service Provider and Application Accounts" for more information.

  7. Create an application account and associate it with the appropriate application group. See "Managing Service Provider and Application Accounts" for more information.

  8. Create an application instance, see "Managing Application Instances" for more information.

  9. Depending on which communication service is being used, provision communication service-specific data using the operation and management for relevant communication service.

  10. Distribute the credentials to be used by the application to the service provider.

Using Partner and API Management Portal to Manage SLAs and Accounts

Partner and API Management Portal, along with a companion GUI, Partner Portal act as ”front-office” offerings provide a friendlier workflow, insulating you from the intricacies of Services Gatekeeper administration. Use the menu selections and/or input fields on well-defined pages of the two GUIs to set up your SLAs and manage your service provider accounts.

Network operators and service provider managers use Partner and API Management Portal to manage:

  • Global node SLAs

  • Service provider group SLAs

  • Service provider group node SLAs

  • Service Provider accounts

  • Application accounts

The Actions tab available to each API on the Partner and API Management Portal also provides these SLA capabilities:

  • The ability to add access limitations for specific API endpoint

  • The ability to authenticate API traffic using a an API key inside message headers

Network operators authorize service providers to act as partners with access to Partner Portal and create applications using these SLAs. For more information on how to use these GUIs, see Services Gatekeeper Partner and API Management Portal Online Help and Services Gatekeeper Partner Portal Online Help.