1 Overview of the Platform Development Studio

Oracle Communications Services Gatekeeper provides substantial functionality right out of the box. But because all networks are different, matching the particular requirements and capabilities of some networks sometimes means that Oracle Communications Services Gatekeeper must be extended or that certain aspects of it must be closely integrated with existing network functionality.The Platform Development Studio is designed to ease this process by providing tools for creating new communication services, for customizing existing communication services, and for integrating a Services Gatekeeper installation with external systems.

Creating New Communication Services

Networks change. Existing functionality is parsed in new ways to support new features. New nodes with new or modified abilities are added. Because of Oracle Communications Services Gatekeeper's highly modular design, exposing these new features to partners is a straightforward proposition. The extension portion of the Platform Development Studio provides an environment in which much of the mechanics of creating extensions is taken care of, allowing extension developers to focus on only those parts of the system that correspond directly to their specific needs. This aspect consists of three main parts

• The Eclipse Wizard

• Example Communication Service

• The Platform Test Environment

The Eclipse Wizard

At the core of the extension portion of the Platform Development Studio is an Eclipse plug-in that creates projects based on the responses that the developer makes to an Eclipse Wizard. The developer supplies some basic naming information and the location of a Web Services Description Language (WSDL) for each application facing interface that the Communication Service is meant to support, and the Wizard generates either a complete Communication Service project, or a network plug-in only project. For more information on setting up the Eclipse Plug-in and running the Wizard, see "Using the Eclipse Wizard" To see an example of a generated project, see "Description of a Generated Project" To get an understanding of the Oracle Communications Services Gatekeeper features with which your Communication Service will interact, see "Using Request Context Parameters in SLAs" "Container Services""Aspects, Annotations, EDRs, Alarms, and CDRs" and "Making Communication Services Manageable"

Example Communication Service

To give you a concrete sense of the task of generating a new Communication Service, the Platform Development Studio contains an entire example Communication Service, which is buildable and runnable. Based on a very simple Web Service interface and an equally simple model of an underlying network protocol, this Communication Service demonstrates the entire range of tasks that you will encounter in creating your own Communication Service. For more information, see "Communication Service Example"

As an example a network protocol plug-in that uses the SIP Servlet container is provided in "Service Enabler Example with SIP plug-in"

The Platform Test Environment

To simplify the testing of your Communication Service, the Platform Development Studio includes the Platform Test Environment, which provides an extensible suite of tools for testing Communication Services and the Unit Test Framework, which supplies an abstract base class, WlngBaseTestCase, which includes mechanisms for connecting to the Platform Test Environment. As well, there is a complete set of sample tools created to interact with the example Communication Service. For more information, see Platform Test Environment, a separate document in this set.

Integration and Customization

New Communication Services are not the only aspect of Oracle Communications Services Gatekeeper that can handled using the Platform Development Studio. To help integrate Oracle Communications Services Gatekeeper into the installation environment, three other aspects of customization are supported:

• Service Interceptors

• Subscriber-centric Policy

• Integration with External Systems

Service Interceptors

Service interceptors provide Oracle Communications Services Gatekeeper with a mechanism for intercepting and manipulating a request as it flows through any arbitrary Communication Service. They offer an easy way to modify the request flow, simplify routing mechanisms for plug-ins, and centralize policy and SLA enforcement. Out of the box, Oracle Communications Services Gatekeeper uses these modules as part of its internal functioning, but operators can also choose to create new interceptors, or to rearrange the order in which the interceptors are used, in order to customize their functionality. "Service Interceptors" describes the request flow through interceptors, lists the standard interceptors and explains how to rearrange interceptors or to create new custom versions.

Subscriber-centric Policy

Out of the box the Oracle Communications Services Gatekeeper administration model allows operators to manage application service provider access to the network at increasingly granular levels of control. Using the Platform Development Studio, operators can extend that model to encompass their subscribers, giving the operator the ability to offer those subscribers a highly personalized experience while protecting their privacy and keeping their subscriber data safe within the operator's domain.

Operators 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 the operator or integrator using the provided Profile Provider SPI then associate those service classes with subscriber URIs, forming subscriber contracts. These contracts are used to evaluate requests and to generate subscriber budgets, which are used by the normal request traffic policy evaluation flow. A single subscriber can be covered by multiple subscriber contracts, based on that individual subscriber's desires. "Subscriber-centric Policy" covers the process for setting this up.

Integration with External Systems

Finally, the Platform Development Studio provides mechanisms to support the integration of Oracle Communications Services Gatekeeper with external network systems, including:

• EDR listeners, covered in "Creating an EDR Listener and Generating SNMP MIBs"

• Alarm monitoring using SNMP, covered in "Creating an EDR Listener and Generating SNMP MIBs"

Additional integration points, not covered in the PDS, are provided by:

• The Partner Relationship Management interfaces, for creating Partner Management portals, covered in Integration Guidelines for Partner Relationship Management, a separate document in this set

• JMX for Management, for non-console based management, covered by these WLS documents: Oracle Fusion Middleware Developing Custom Management Utilities With JMX for Oracle WebLogic Server at:

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

  and Oracle Fusion Middleware Developing Manageable Applications With JMX for Oracle WebLogic Server at:

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

Tips for Creating Extensions

This section contains tips to consider when you are creating extensions to Oracle Communications Services Gatekeeper:

• When creating the management interface, consider if the management operations and attributes should be cluster-wide or local.

• Make sure to follow the plug-in naming convention: Plugin_web service interface part_network protocol.

• Make sure to implement customMatch of the PluginInstance (or ManagedPluginInstance) to be sure that requests end up in the correct plug-in. This is important when there are multiple plug-ins for the same communication service.

• Create exception types that are very specific to various error scenarios. This will allow fine grain control of the alarms that are generated.

• Have a clean separation between the north and the south side of the plug-in.

• Make sure to return all north interfaces (callback included) and souths interfaces when implementing the getNorthInterfaces() and getSouthInterfaces() of PluginInstance.

• Make sure to implement the resolveAppInstanceGroupdId() method for each PluginSouth instance (if applicable).

• Annotate each parameter in the south object methods that you need to have when aspect calls back the resolveAppInstanceGroupId() or the prepareRequestContext() methods.

• Consider what additional EDR fields you need to add. Annotate all the methods you want to be woven using the @Edr annotation.

• Annotate the specific arguments you want to see in the EDR for each annotated methods. Use either @ContextKey or @ContextTranslate depending on the kind of argument.

• Add all the EDRs you are triggering to the EDR descriptor.