12 Using SLA Policies to Manage Subscribers

About Using Policies to Manage Subscribers

As a network operator, you can use Services Gatekeeper to evaluate the status of requests in terms of policy, or rules governing a variety of service characteristics and manage the normal request traffic policy evaluation flow using service contracts to evaluate requests and to generate subscriber budgets.

To do so, you create a Subscriber SLA, based on a provided schema, which describes sets of service classes. The service classes define access relationships with the services of particular service provider and application groups, along with default rates and quotas. Profile providers created by you or your network integrator can associate those service classes with subscriber URIs to create subscriber contracts. A single subscriber can be covered by multiple subscriber contracts, based on that individual subscriber's requirements.

Service Classes and the Subscriber SLA

Making subscriber personalization easy and offering superior subscriber data protection is key to growing and maintaining a loyal subscriber base.

The first step in adding subscriber-centric policy to Services Gatekeeper is to create a Subscriber SLA. This is an XML file based on the sub_sla_file.xsd schema.

The schema file can be found in the wlng.jar file located in the Middleware_home/ocsg_pds/lib/wlng directory.

The SLA is used to define classes of service in the context of existing Service Provider and Application Groups.(For more information on Service Provider and Application Groups, see the discussion on managing application service providers in Services Gatekeeper Concepts. These service classes can then be associated with subscribers, based on their preferences and permissions, defining individualized relationships between subscribers and Service Provider and Application Group functionality.

<ServiceClass name="news_subscription">
        <references>
            <ApplicationGroupReference id="silver_app_group"/> 
            <ApplicationGroupReference id="gold_app_group"> 
                <ServiceReference serviceInterface="com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin"/>
            </ApplicationGroupReference>
            <ServiceProviderGroupReference id="content_sp_group">
                <ServiceReference serviceInterface="com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin">
                    <MethodReference methodName="sendSms" />
                    <MethodReference methodName="getSmsDeliveryStatus" />
                </ServiceReference>
            </ServiceProviderGroupReference>
        </references>

<restriction>
            <rate>
              <reqLimit>5</reqLimit>
              <timePeriod>1000</timePeriod>
            </rate>
            <quota>
              <qtaLimit>600</qtaLimit>
              <days>3</days>
              <limitExceedOK>true</limitExceedOK>
            </quota>
</restriction>

The Profile Provider SPI and Subscriber Contracts

Once the Subscriber SLA is established, the various service classes it defines must be associated with individual subscribers. The combination of a subscriber (identified by URI) and a service class is called a subscriber contract. A subscriber (a URI) can have multiple subscriber contracts associated with it.

The subscriber contract object contains a URI designating the subscriber and the service class type with which it is associated. It also contains an expiration time, represented as a java.util.Date.

The subscriber contract constructor throws an exception if the URI, service class type, and expiration time are not specified.

The subscriber contract may also replace the default rate and/or quota settings in the service class, or set this subscriber to RestrictAll, that is, to deny access for all requests.

The operator or integrator is responsible for creating the mechanism, a Profile Provider, that supplies these subscriber contracts.

The Profile Provider must implement the Profile Provider SPI. The SPI defines three methods;

• init: Services Gatekeeper initializes the Profile Provider by passing in a list of the service classes that are defined in the Subscriber SLA and a list of any previously defined subscriber contracts. The Provider returns a list of updated subscriber contracts.

• contractExpired: Services Gatekeeper sends the Provider a list of service classes and a list of expired contracts. The Provider returns an updated list of contracts for those that have expired. The Provider can remove or add contracts to the returned list.

• serviceClassesUpdated: Whenever the Subscriber SLA is updated, and the service classes are thus modified, Services Gatekeeper sends the Provider a list of the updated service classes and a list of all current contracts. The Provider returns an updated list of contracts. The Provider can make any necessary updates to the subscriber contracts.

The Profile Provider implementation must have a public constructor with no parameters or a static method which returns ProfileProvider.

com.mycompany.mypackage.MyProfileProviderImpl

Subscriber Policy Enforcement

Once the providers.ear is deployed, the singleton SubscriberProfileService initializes the Profile Provider(s) and receives the relevant subscriber contracts. It uses the Budget Service to create budgets for the contracts, based on the specified rates and quotas, and also creates and schedules a timer based on the expiration times in the contracts. Both the Subscriber SLA and the subscriber contracts are persisted using the Storage Service.

When a request from an application arrives at Services Gatekeeper, it passes through the Interceptor Stack for policy evaluation. The EnforceSubscriberBudget interceptor manages policy enforcement for subscriber contracts. The process within the interceptor has two phases:

• Do Relevant Subscriber Contracts Exist?

• Is There Adequate Budget for the Contracts?

Do Relevant Subscriber Contracts Exist?

The first thing the interceptor must determine is whether one or more contracts exist that are relevant to the particular request that is being evaluated. The interceptor iterates through all the target URIs in the application request, and evaluates whether or not there are contracts in effect that it should enforce.

• If there are no contracts at all associated with a particular URI, the request is simply passed on to the next interceptor in the sequence.

• If there are contracts associated with a particular URI, a set of evaluations must be carried out. The figures below show the decision flow for the evaluations. All three sections must evaluate to true for there to be an enforceable contract.

  Note:

  The XML snippets correspond to the relevant sections of Example 12-1.

  • Is there an ApplicationGroupReference and is it relevant? See Figure 12-1.

Figure 12-1 Application Group Reference Evaluation

Description of ''Figure 12-1 Application Group Reference Evaluation''

Note:

The evaluation for methodExists is covered in Figure 12-3.

• Is there a ServiceProviderGroupReference and is it relevant? See Figure 12-2.

Figure 12-2 Service Provider Group Reference Evaluation

Description of ''Figure 12-2 Service Provider Group Reference Evaluation''

Note:

The evaluation for methodExists is covered in Figure 12-3.

• Is there a Service Reference (and possibly a MethodReference) and are they relevant? See Figure 12-3.

Figure 12-3 Service and Method Reference Evaluation

Description of ''Figure 12-3 Service and Method Reference Evaluation''