![]() ![]() ![]() ![]() ![]() ![]() |
WebLogic Network 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 Network 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. It consists of two main sections:
Networks change. Existing functionality is parsed in new ways to support new features. New nodes with new or modified abilities are added. Because of WebLogic Network 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
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 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 Network Gatekeeper features with which your Communication Service will interact, see Policy, Container Services,Annotations, EDRs, Alarms, and CDRs, and Making Communication Services Manageable.
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.
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 Using the Platform Test Environment.
New Communication Services are not the only aspect of Network Gatekeeper that can handled using the Platform Development Studio. To help integrate Network Gatekeeper into the installation environment, three other aspects of customization are supported:
Service interceptors provide Network 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, Network 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.
Out of the box the Network 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.
Finally, the Platform Development Studio provides mechanisms to support the integration of Network Gatekeeper with external network systems, including:
Additional integration points, not covered in the PDS, are provided by:
![]() ![]() ![]() |