Developer's Guide for Extended Web Services
Get Adobe Reader |
The following sections introduce the development workflow for developing Extended Web Services:
WebLogic Network Gatekeeper Web Services applications are services offering their users access to telecom functionality. The applications can access the telecom functionality through two different Web services APIs. Which API to use depends on the application's needs for network functionality and means of access.
For applications that will provide standardized basic telecom functionality, it is recommended to use the Parlay X APIs.
For applications with a need for more granular control, the Extended Web Services interfaces can be used.
This guide describes how to develop Extended Web Services applications that connects to WebLogic Network Gatekeeper. WebLogic Network Gatekeeper acts as a gateway to the underlying telecom network.
Using the Extended Web Services Interfaces you can quickly develop powerful telecom-enabled applications using any programming environment supporting Web Services.
Figure 2-2, Extended Web Services interfaces and JS2SE applications, on page 2-4 illustrates different ways of using the Web Services APIs as provided by WebLogic Network Gatekeeper, as well as examples of different execution environments for applications.
There are two flavours of Web Services; XML-based RPC and WS-I.
Web services applications executes in an environment capable of handling Web Services.
The Web Services applications communicates with WebLogic Network Gatekeeper using SOAP/HTTP.
An Extended Web Services application
Below is a description of an example development environment. Integrated programming environments, like Visual Studio .Net can be used for development of Web Services applications, but this guide uses a minimalistic approach. For the purpose of this guide, the following will do:
The following files from the Axis distribution are used:
The following JavaMail files are used:
Before an application is developed, the application developer and the service provider must exchange information regarding resources.
The first step for the application developer is to define which resources to use, call, messaging, location, status, payment etc. and to map these requirements to an APIs that corresponds to these resources.
The next step is to exchange the information according to Information exchange between application developer and WebLogic Network Gatekeeper operator.
The WebLogic Network Gatekeeper operator must also communicate which services and methods that are supported by the deployment.
In addition to this information, other information related to commercial, security, and privacy regulations must also be exchanged. Examples includes:
Below you find overall workflows for development of Web Services applications based on the Extended Web Services interfaces.
Two main scenarios are identified:
Often, an application acts as both server and client.
The methods that the application invokes on WebLogic Network Gatekeeper are defined in WSDL files, one for each service capability, where the name of the file reflects the capability. Likewise are the methods that WebLogic Network Gatekeeper invokes on the application defined in WSDL files, one for each service capability. The names of these files ends with "Listener".
The method invocations are SOAP requests over HTTP, which means that the server part of the application must be capable of handling SOAP requests.
When using Axis, the Simple Axis Server can be used as a SOAP engine during test. In a production system can, for example, Axis in combination with Tomcat be used.
Below is an overall work sequence for developing telecom enabled Web Services using XML-based RPC:
Below is an overall work sequence for developing telecom enabled Web Services using XML-based RPC:
The example below shows how to define a web service that takes care of notifications on new SMS:es from to the applications' server side. The web service is the Messaging Listener interface, containing the method newMessageAvailable(...).
The Simple Axis Server is used as deployment environment for the application.
Below is an outline on the procedure:
In the example, the class is named MessagingListenerSoapBindingImpl.
When generating skeletons using WSDL2Java, the empty interface implementations are named <Name of API>BindingImpl
.
Figure 2-4, Application test flow, on page 2-13 shows the application test flow, from the application developers' functional test to deployment in a live network. An application developer can perform functional tests using Weblogic Network Gatekeeper Application Test Environment. The other tests in the flow are performed in cooperation between the application provider and the service provider.
When an application shall be tested using Weblogic Network Gatekeeper Application Test Environment (ATE), the application is connected to ATE, which emulates WebLogic Network Gatekeeper. Before testing in a test telephony network, a network simulator can be used.
An overview of the relation between Weblogic Network Gatekeeper Application Test Environment and WebLogic Network Gatekeeper is shown in Figure 2-5, Weblogic Network Gatekeeper Application Test Environment (ATE) in relation to WebLogic Network Gatekeeper, on page 2-14.
For a applications based on Web Services, the applications uses the endpoints provided by Weblogic Network Gatekeeper Application Test Environment during test. After successful verification, the application uses endpoints provided by WebLogic Network Gatekeeper.