Making subscriber personalization easy and offering superior subscriber data protection is key to growing and maintaining a loyal subscriber base. The Platform Development Studio offers a straightforward way to extend the power of Oracle Communications Services Gatekeeper’s flexible policy-based control to the operator’s subscriber base. The mechanism can be divided into three parts:
|Note:||There is an example Profile Provider in
The first step in adding subscriber-centric policy to Oracle Communications Services Gatekeeper is to create a Subscriber SLA. This is an XML file based on the
|Note:||The schema file can be found in the
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, seein Concepts and Architectural Overview, a separate document in this set.) 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.
<reference> tag specifies the operator’s already-established Application and Service Provider Groups that are to be associated with this service class. There are two reference types that define the groups: the ApplicationGroupReference and the ServiceProviderGroupReference. In addition there are two additional reference types, the ServiceReference and the MethodReference that indicate specific service interfaces and methods, respectively, covered by those groups. In the Listing 13-1 snippet, the service class
news_subscription is defined. Evaluation of matches in the class occurs using the following rules:
So, in the case of Listing 13-1, the class covers any request that matches:
<MethodReference methodName="sendSms" />
<MethodReference methodName="getSmsDeliveryStatus" />
Use of the empty tag,
<references/>, matches everything.
In addition to the
<reference> tag, service classes may have a
<restriction> tag. This tag is used to attach default rates and quotas that are used to create budgets for the classes. These rates and quotas can be replaced in specific contracts.
|Note:||The XSD requires you either to specify a rate/quota restriction or to use the
These tags function exactly as they do in the other SLAs in Oracle Communications Services Gatekeeper. For more information on these tags, see the Contract structure section of the chapter of Managing Accounts and SLAs, a separate document in this set. If the
<limitExceedOK> tag is set to true, the request is allowed even when quota has been exceeded, but an alarm (Alarm id
200000) is fired
There is also a
<restrictAllType/> tag. This tag, as its name implies, denies access to all requests.
There are three management methods in the Service Level Agreement MBean for managing a Subscriber SLA. They are covered in detail in thechapter of Managing Accounts and SLAs, a separate document in this set. The methods allow you to load a Subscriber SLA as a string, to load a Subscriber SLA from a URL, and to retrieve a loaded Subscriber SLA.
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 j
|Note:||The subscriber contract constructor will throw 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.
|Note:||All class files related to creating Profile Providers are in the
The Profile Provider must implement the Profile Provider SPI. The SPI defines three methods;
init: Oracle Communications 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: Oracle Communications 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, Oracle Communications 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
ProfileProviderImpl has been created, the
.jar file containing it must be added to the
app-inf/lib directory of the
profile_providers.ear file, which can be found in the
$BEA_HOME/ocsg_4.1/applications directory. You must also modify the
app-inf/classes/ProfileProviders.prop file, adding a line containing the package and implementation file name of each of your providers (multiple providers are possible). For example:
Once the EAR is modified, it can be deployed in the normal manner. For more information on deploying EAR files in Oracle Communications Services Gatekeeper, see thechapter in the System Administrator’s Guide, a separate document in this set.
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.
|Note:||For more information on budgets in Oracle Communications Services Gatekeeper, see thechapter in the System Administrator’s Guide, a separate document in this set.|
When a request from an application arrives at Oracle Communications 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:
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.
truefor there to be an enforceable contract.
|Note:||The XML snippets correspond to the relevant sections of Listing 13-1:|
ApplicationGroupReferenceand is it relevant? See Figure 13-1
|Note:||The evaluation for methodExists is covered in Figure 13-3|
ServiceProviderGroupReferenceand is it relevant? See Figure 13-2.
|Note:||The evaluation for methodExists is covered in Figure 13-3|
Service Reference(and possibly a
MethodReference) and are they relevant? See Figure 13-3
Once the interceptor determines that an enforceable contract exists, it first determines whether the contract includes a
<restriction> tag set to
<restrictAll/>. If so, the request is immediately denied, and processing on the request ceases.
<restriction> tag is not set to
<restrictAll/>, the decision flow here is identical to the other budget evaluations that take place in Oracle Communications Services Gatekeeper.
If there are no relevant contracts, or there are relevant contracts and there is adequate budget to cover them, budgets are adjusted as necessary and the request passes on to the next interceptor. If there are relevant contracts and there is not adequate budget to cover them, the request is denied.