Skip navigation.

eDocs Home > BEA WebLogic Network Gatekeeper 1.0 Documentation > Developer's Guide for Extended Web Services > Introduction and Overall Workflow

Developer's Guide for Extended Web Services

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF  
Get
Adobe Reader

Introduction and Overall Workflow

The following sections introduce the development workflow for developing Extended Web Services:

 

About WebLogic Network Gatekeeper Web Services applications

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.

 

Architecture

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

Web services applications executes in an environment capable of handling Web Services.

The Web Services applications communicates with WebLogic Network Gatekeeper using SOAP/HTTP.

Extended Web Services based applications

An Extended Web Services application

 

Development environment

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:

 

Information exchange with the service provider

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.

Table 2-1 Information exchange between application developer and WebLogic Network Gatekeeper operator

Module

Information to be provided by the

Application developer

Service provider

Access


Application ID.

Service provider ID.

Application Instance Group ID.

Password for the Application Instance Group.

Call Control


For application initiated calls:
Any eventual restrictions on allowed numbers.

For network initiated calls:
Access number to the application. Can be a range of numbers.

Call User Interaction


Details about IVRs, such as access number, announcement IDs, input capabilities and so on.

Content Based Charging


Currencies allowed, any restrictions on allowed maximum or minimum values.

Messaging


Access number to the application.

Mailbox ID and corresponding password.

Message User Interaction


User information codes to be used. Language codes. User Interaction Codes for network-initaed user interaction sessions.

Subscriber Profile


Properties that can be set of get.

User Location


Supported uncertainty shapes.

User Status


-

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:

 

Overall development workflows

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.

Client-side Web Services using XML based RPC

Below is an overall work sequence for developing telecom enabled Web Services using XML-based RPC:

  1. Make sure to retrieve the necessary IDs for the resources the application will use from the service provider. Examples are mailbox IDs, short numbers for network triggered applications and so on.
  2. Retrieve the WSDL file that handles user login.
  3. Retrieve WSDL files for the telecom services to use.
  4. Generate stubs/proxy classes for the language to implement the application in. Use a tool that converts the WSDL into stubs for the preferred language. Examples of such tools are WSDL2Java and Soap Toolkit.
  5. Compile and create Jar-files from the Java stubs.
  6. Use the generated APIs to add telecom functionality to the application.
  7. Compile the application.
  8. Test the application in a test environment, for example WebLogic Network Gatekeeper Application Test Environment.
  9. Connect the application to a WebLogic Network Gatekeeper with a connection to a live telecom network.

Server-side Web Services using XML based RPC

Below is an overall work sequence for developing telecom enabled Web Services using XML-based RPC:

  1. Make sure to retrieve the necessary IDs for the resources the application will use from the service provider. Examples are mailbox IDs, short numbers for network triggered applications and so on.
  2. Retrieve WSDL files for the telecom services to use.
  3. Generate skeleton classes for the language to implement the application in. Use a tool that converts the WSDL into stubs for the preferred language. Examples of such tools are WSDL2Java and Soap Toolkit.
  4. Compile and create Jar-files from the Java stubs.
  5. Implement the generated interfaces and add telecom functionality to the application.
  6. Adapt the generated WSDD file to bind the SOAP requests to the appropriate class.
  7. Compile the application.
  8. Deploy the application in an environment capable of decoding HTTP/SOAP messages. Examples of such environments includes Axis.
  9. Test the application in a test environment, for example WebLogic Network Gatekeeper Application Test Environment.
  10. Connect the application to a WebLogic Network Gatekeeper with a connection to a live telecom network.

Example: Server-side Web Service

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:

  1. Generate Java skeletons from the WSDL files:

    2. %java org.apache.axis.wsdl.WSDL2Java --server-side
    --skeletonDeploy true     MessagingListener.wsdl

    Note: The Axis files must be in the classpath.

  2. Compile and create Jar-files from the skeletons.
  3. Move the empty implementation of the generated interfaces to the source directory of the application.

    4. In the example, the class is named MessagingListenerSoapBindingImpl. When generating skeletons using WSDL2Java, the empty interface implementations are named <Name of API>BindingImpl.

  4. Adapt the generated Web Service Deployment Descriptor (WSDD) files to bind the SOAP request to the appropriate class.

    5. The WSDD files are used when deploying and undeploying services. Two files are generated: deploy.wsdd and undeploy.wsdd.

    In the example, the tag

    <parameter name="className" value="MessagingListenerSoapBindingSkeleton"/>

    is replaced with

    <parameter name="className" value="com.acme.apps.getmessageapp.MessageNotificationHandler"/>

    in order to bind to the appropriate class.

  5. Compile the application.
  6. Verify that the application is deployed correctly by using a Web browser and point it to the URL of the web service. In the case of Simple Axis Server, the deployed Web Services can be found at the URL http://<host>:<port>/axis/services
  7. Run the application. The adapted file deploy.wsdd is used when instantiating the Simple Axis Server.

 

Testing an application

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.

 

Skip navigation bar  Back to Top Previous Next