Creating Applications for WebLogic Network Gatekeeper

As the worlds of Internet applications and of telephony-based functionality continue to converge, many application developers have become frustrated by the unfamiliar and often complex telecom interfaces that they need to master to add even simple telephony-based features to their programs. By using WebLogic Network Gatekeeper, telecom operators can instead offer developers a secure, easy-to-develop-for single point of contact with their networks, made up of simple Web Service interfaces that can easily be accessed from the Internet using a wide range of tools and languages.

The following chapter presents an overview of Network Gatekeeper's functionality, and the ways that application developers can use this functionality to simplify their development projects, including:

Basic Concepts

There are a few basic concepts you need to understand to create applications that can interact with WebLogic Network Gatekeeper:

Management Structures

Traffic Paths

The basic functional unit in WebLogic Network Gatekeeper is the traffic path. A traffic path consists of a service type (Short Messaging, User Location, etc.), an application-facing interface (also called a "north" interface), and a network-facing interface (also called a "south" interface). A request for service enters through one interface, is subjected to internal processing, including evaluation for policy and protocol translation, and is then sent on using the other interface.

Traffic Types

In some Network Gatekeeper traffic paths, request traffic can travel in two directions - from the application to the underlying network and from the underlying network to the application - and in others traffic flows in one direction only.

Application-initiated Traffic

In application-initiated traffic, the application sends a request to Network Gatekeeper, the request is processed, and a response of some kind is returned synchronously. So, for example, an application could use the Third Party Call interface to set up a call. The initial operation, MakeCall, is sent to Network Gatekeeper (which sends it on to the network) and a string, the CallIdentifier, is returned to the application synchronously. To find out the status of the call, the application makes a new request, GetCallInformation, using the CallIdentifier to identify the specific call, and then receives the requested information back from Network Gatekeeper synchronously.

Network-triggered Traffic

In many cases, application-initiated traffic provides all the functionality necessary to accomplish the desired tasks. But there are certain situations in which useful information may not be immediately available for return to the application. For example, the application might send an SMS to a mobile phone that the user has turned off. The network won't deliver the message until the user turns the phone back on, which might be hours or even days later. The application can poll to find out whether or not the message has been delivered, using GetSmsDeliveryStatus, which functions much like GetCallInformation described above. But given the possibly extended period of time involved, it would be convenient simply to have the network notify the application once delivery to the mobile phone has been accomplished. To do this, two things must happen:

The application must inform Network Gatekeeper that it wishes to receive information that originates from the network. It does this by subscribing or registering for notifications via an application-initiated request. (In certain cases, this can also be accomplished by the operator, using OAM procedures.) Often this subscription includes filtering criteria that describes exactly what kinds of traffic it wishes to receive. Depending on the underlying network configuration, Network Gatekeeper itself, or the operator using manual steps, informs the underlying network about the kind of data that is requested. These notifications may be status updates, as described above, or, in some instances, may even include short or multimedia messages from a terminal on the telecom network.
The application must arrange to receive the network-triggered information, either by implementing a Web Service endpoint on its own site to which Network Gatekeeper dispatches the notifications, or by polling Network Gatekeeper to retrieve them. Notifications are kept in Network Gatekeeper for retrieval for only limited amounts of time.

Management Structures

In order to help telecom operators organize their relationships with application providers, Network Gatekeeper uses a hierarchical system of accounts. Each application is assigned a unique username (same as application instance group ID) and that username is tied to an Application Account. All the Application Accounts that belong to a single entity are assigned to a Service Provider Account. Application Accounts with similar requirements are put into Application Groups and Service Providers with similar requirements are put into Service Provider Groups. Each Application Group is associated with an Application Group Service Level Agreement (SLA) and each Service Provider Group are associated with Service Provider Group SLAs. See Figure 2-1 for more information. These Service Level Agreements define and regulate the contractual agreements between the telecom operator and the application provider, and cover such things as which services the application may access, the maximum bandwidth available for use, and the number of concurrent sessions that are supported.

Functional Overview

Network Gatekeeper provides eleven different types of traffic paths. The application-facing interfaces of these traffic paths are largely based on the Parlay X 2.1 specifications. The functionality supported by these traffic paths includes:

Using this traffic path, an application can set up and end notifications on call events, such as the callee in a third party call attempt is busy. In addition, in some cases the application can then reroute the call to another party.

Using this traffic path, an application can establish rules that will automatically handle calls that meet certain criteria. These rules might establish, for example, that calls from a particular number are always blocked, or are always forwarded if the initial callee is busy. In addition, the application can retrieve rules that are currently in place.

Using this traffic path, an application can send SMS text messages, ringtones, or logos to one or multiple addresses, set up and receive notifications for final delivery receipts of those sent items, and arrange to receive SMSes meeting particular criteria from the network.

Multimedia Messaging

Using this traffic path, an application can send Multimedia Messages to one or multiple addresses, set up and receive notifications for final delivery receipts of those sent items, and arrange to receive MMSes meeting particular criteria from the network.

Using this traffic path, an application can request the position of one or more terminals or the distance between a given position and a terminal. It can also set up and receive notifications based on geographic location or time intervals.

Using this traffic path, an application can be a watcher for presence information published by a presentity, an end user who has agreed to have certain data, such as current activity, available communication means, and contact addresses made available to others. So a presentity might say that at this moment he is in the office and prefers to be contacted by SMS at this number. Before the watcher can receive this information, it must subscribe and be approved by the presentity. Once this is done, the watcher can either poll for specific presentity information, or set up status notifications based on a wide range of criteria published by the presentity.

Using this traffic path, an application can communicate charging information to an operator in situations where the cost of the service is based on the nature of the content delivered and not on connect time. For example, an end user could request the download of a music video, which costs a specific amount. The application can notify the operator that the user should be charged a particular amount or be refunded a particular amount. In the case of pre-paid accounts, it can also reserve a certain amount of the user's available funds and then charge or release the reservation depending, say, on whether or not the download was successful.

The application-facing interface of this traffic path, unlike the previous ten, is not based on the Parlay X 2.1 specification. Many elements within it, however, are based on widely distributed standards. Using this traffic path, an application can send a WAP Push message, send a replacement WAP Push message, or set up status notifications about previously sent messages.

Application Testing Workflow

Application testing in a telecom environment is usually conducted in a stepwise manner. For the first step, applications are run against simulators like the optional WebLogic Network Gatekeeper Simulator. The Network Gatekeeper Simulator emulates both the Network Gatekeeper and the underlying network, and allows developers to sort out basic functional issues without having to be connected to a network or network simulator. Once basic functional issues are sorted through, the application is connected to an instance of the Network Gatekeeper attached to a network simulator for non-functional testing. Next the application is tested against a test network, to eliminate any network related issues. Finally, the application can be placed into production on a live network. Figure 2-2 shows the complete application test flow, from the developer's functional tests to deployment in a live network. While Simulator-based tests may be performed in-house by an Application Service Provider, the other tests require the cooperation of the target network operator.

Application Development Guide