Tutorial for using Web Services in Avaya Dialog

Designer Applications

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

1 of 37
DDWeb_Services

Contents
About this Tutorial ............................................................................................................................ 3
Intended Audience .............................................................................................................. 3
Prerequisites ....................................................................................................................... 3
Chapter 1:

Introduction ............................................................................................................ 4

1.1

Web Service Architecture ...................................................................................... 4

1.2

Web Service Description Language (WSDL)......................................................... 5

Chapter 2:

Consuming Web Services...................................................................................... 8

2.1

Consuming Web Services using Standard Java tools ........................................... 8

2.2

Consuming a Web Service in Dialog Designer Applications ............................... 17

2.3

Summary.............................................................................................................. 22

Chapter 3:

Creating a Web Service Operation File ............................................................... 23

3.1

Web Services Information.................................................................................... 24

3.2

Input and Output Parameters............................................................................... 25

3.3

Authentication ...................................................................................................... 26

3.4

Headers................................................................................................................ 26

Chapter 4:

Troubleshooting Dialog Designer Web Services ................................................. 27

4.1

Tracing SOAP requests using Wireshark.......................................................... 27

4.2

Network monitoring using TCPMonitor ................................................................ 31

References..................................................................................................................................... 36

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

2 of 37
DDWeb_Services

About this Tutorial

This tutorial explains the steps for consuming Web Services from Avaya Dialog Designer applications.
The tutorial is organized into the following sections:

An Introduction describing the fundamental components of Web Services and Web Services
Description Language (WSDL).
The procedure for consuming Web Services using standard Java tools as well as Avaya
Dialog Designer.
An overview of the Web Services Operation (WSOP) File.
A method of tracing Web Service calls.

The tutorial presents an overview of Web Services and the elements contained in a Web Service
document. The steps involved in consuming a Web Service within an application using standard Java
tools are then described and this approach is then contrasted with the ease of consuming the same Web
Service using the built in Dialog Designer Web Services connector. The structure of a Dialog Designer
WSOP file and its features are discussed. The process of tracing Web Service calls is also described.
After completing this tutorial, the developer will be familiar with:

The elements in a Web Service document.

The details on the format, features and advantages of using a Dialog Designer Web Services
connector for consuming Web Services in application call flows.
The steps involved in using a standard tool to trace Web Service calls.

Intended Audience
This document is intended for developers developing Web Service applications using Avaya Dialog
Designer.

Prerequisites
A basic understanding of the Web Services model and familiarity with Java programming and telephony
application call flows are required. This tutorial is primarily intended for application developers and
managers familiar with the technical aspects of self service application design.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

3 of 37
DDWeb_Services

Chapter 1: Introduction
A Web Service is a software system designed to support interoperable machine to machine interaction
over a network. Web Services are Web APIs that can be accessed over a network, such as the Internet,
and executed on a remote system hosting the requested services.
In common usage, the term Web Service refers to clients and servers that communicate using XML
messages that follow a standard, such as Simple Object Access Protocol (SOAP). A Web Service
provider is an application which provides functionality to be accessed over the network. A Web Service
consumer locates this functionality and invokes the operations provided by the Web Service.
A Web Service makes software application resources available over networks using standard
technologies. Being based on standard interfaces, Web Services provide an implementation-independent
way for applications to communicate with each other.

1.1 Web Service Architecture

Figure 1:

Architecture of a Web Service

Figure 1 above shows the relationship between a Web Service (in the center), its client software
applications (on the left), and the resources it uses, including databases, other Web Services, and so on

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

4 of 37
DDWeb_Services

(on the right). A Web Service communicates with clients and resources using standard protocols, such as
HTTP, by exchanging XML messages. The application server on which the Web Service is deployed is
responsible for routing incoming XML messages to the Web Service code. The Web Service exports a
WSDL file to describe its interface, which other developers may use to write components to access the
service.

1.2 Web Service Description Language (WSDL)

As communications protocols and message formats are standardized in the web community, it becomes
increasingly possible and important to be able to describe the communications in some structured way.
WSDL addresses this need by defining an XML grammar for describing network services as collections of
communication endpoints capable of exchanging messages. WSDL service definitions provide
documentation for distributed systems and serve as a recipe for automating the details involved in
applications communication.
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract
definition of endpoints and messages is separated from their concrete network deployment or data format
bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the
data being exchanged, and port types which are abstract collections of operations. The concrete protocol
and data format specifications for a particular port type constitute a reusable binding. A port is defined by
associating a network address with a reusable binding, and a collection of ports define a service. Hence,
a WSDL document uses elements such as types, message, operation, portType, binding, port
and service in the definition of network services. These element types are described in the following
sections along with sample code demonstrating their use.
In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or
data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract
definitions.
For more information on the fundamentals of WSDL, refer [3].
A brief description of the elements is discussed, along with sample code showing the implementation of
each element. The WSDL file discussed below is provided by Google and can be accessed at
http://api.google.com/GoogleSearch.wsdl.
Note: The URL above for Google web services may change over time. If the above URL does not work,
then go to www.google.com and look for an updated URL pointing to GoogleSearch.wsdl.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

5 of 37
DDWeb_Services

types: The WSDL types element is a container for XML Schema type definitions. The type
definitions placed here are referenced from higher-level message definitions in order to define the
structural details of the message. The following example code shows a typical implementation of the
types element:

<definitions name="GoogleSearch"
<types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:GoogleSearch">
<xsd:complexType name="GoogleSearchResult">
<xsd:all>
<xsd:element name="documentFiltering"
type= "xsd:boolean"/>
</xsd:all>
</xsd:complexType>
</types>
</definitions>

message: The WSDL message element defines an abstract message that can serve as the input or
output of an operation. Messages consist of one or more part elements, where each part is
associated with either an element (when using document style) or a type (when using RPC style).
The following example code shows a typical implementation of the message element:
<definitions name="GoogleSearch"
<message name="doGetCachedPage">
<part name="url" type="xsd:string"/>
</message>
</definitions>

portType: The WSDL portType element defines a group of operations, also known as an
interface in most environments. A portType element contains zero or more operation elements. The
following example code shows a typical implementation of the portType element:
<definitions name="GoogleSearch"
<portType name="GoogleSearchPort">
<operation name="doGetCachedPage">
<input message="typens:doGetCachedPage"/>
<output message="typens:doGetCachedPageResponse"/>
</operation>
</portType>
</definitions>

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

6 of 37
DDWeb_Services

binding: The WSDL binding element describes the concrete details of using a particular
portType with a given protocol. The binding element contains several extensibility elements as well
as a WSDL operation element for each operation in the portType it's describing. The following
example code shows a typical implementation of the binding element:
<definitions name="GoogleSearch"
<binding name="GoogleSearchBinding" type="typens:GoogleSearchPort">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="doGetCachedPage">
<soap:operation soapAction="urn:GoogleSearchAction"/>
<input>
<soap:body use="encoded"
namespace="urn:GoogleSearch"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:GoogleSearch"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding
</definitions>

service: The WSDL service element defines a collection of ports, or endpoints, that expose a
particular binding. The sample code below shows a typical implementation of the service element:
<definitions name="GoogleSearch"
<service name="GoogleSearchService">
<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
<soap:address location="http://api.google.com/search/beta2"/>
</port>
</service>
</definitions>

Each port must be given a name and a binding assigned to it. Within the port element, an extensibility
element then has to be used to define the address details specific to the binding.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

7 of 37
DDWeb_Services

Chapter 2: Consuming Web Services

This chapter lists the various methods available to consume a Web Service using standard Java tools
and then describes the procedure to do the same using one of the tools in detail.

2.1 Consuming Web Services using Standard Java tools

This Tutorial describes the procedure for consuming Web Services using the Axis tool. The procedure for
consuming a Web Service using Axis mainly consists of following three steps:
1. Locating the WSDL file for the desired Web Service.
2. Creating the stubs.
3. Writing the Java client application using the Dialog Designer servlet node.
These steps are elaborated in the following paragraphs.
Step 1.

Locating the WSDL file for the desired Web Service.

Open the example WSDL file shown below by entering the following URL in any standard
web browser:
http://www.webservicex.net/CurrencyConvertor.asmx?WSDL

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

8 of 37
DDWeb_Services

Step 2.

Creating the stubs.

This tutorial uses the WSDL2Java utility provided by Axis to create the stubs. Axis
installation is a pre-requisite to perform this step. The steps outlining the installation of
Axis are described below:
1. Obtaining and installing Axis: The latest version of Axis can be downloaded from
http://ws.apache.org/axis and clicking on the Source Code link under the Downloads
section-header link on the left-hand side of the page, as shown below:

Post installation, the hierarchy of the webapps directory is as shown below:

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

9 of 37
DDWeb_Services

2. Setting Classpath:
a. To set the Classpath from the command line:
For this tutorial, JDK 1.5.0 must be installed and the path to the bin directory must
be set as shown in the figure. The other .JAR files in the classpath can be located
under the <Axis installfolder>/web-inf/lib> directory. Refer the
screenshot below:

b. The following steps show an alternative procedure that may be followed to set the
Classpath. The screenshots show the parameters to be configured to set the
Classpath.
i. Locate and right click on the My Computer icon on the desktop and select
Properties from the dropdown menu, as shown below:

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

10 of 37
DDWeb_Services

ii. Click on the Advanced tab. Click Environment Variables on the Advanced
tab to set the Environment Variables parameters as shown below.

iii. Click the New button shown below to add a System Variable.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

11 of 37
DDWeb_Services

iv. In the New System Variable edit box enter CLASSPATH in the Variable name
field and complete path to all the JAR files (in the
<Axis installfolder>/web-inf/lib> directory) under the
Variable value field as shown below

3. Creating stubs using WSDL2Java utility:

The WSDL2Java utility is provided with the Apache Axis SOAP engine. The utility can be
used from the command line to build java proxies from a given WSDL file.
Perform the following steps before running this utility:
1. The JAVA_HOME environment variable must be set to the root java install
directory before running this utility.
2. The CLASSPATH variable should be set to include the path to the following
jar files located in the CATALINA_HOME/lib Tomcat directory: axis.jar,
jaxrpc.jar, saaj.jar, commons-logging.jar, commons-discovery.jar and
wsdl4j.jar.
With the Classpath now set, invoke WSDL2Java as follows:
java org.apache.axis.wsdl.WSDL2Java <WSDL URI>
As an example, the following command will create the required stubs:
java org.apache.axis.wsdl.WSDL2Java
http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
If the t option is specified on the command line, the test case is also created along with
the required stubs.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

12 of 37
DDWeb_Services

Step 3.

Writing the Java client application in the servlet node in Dialog Designer.
The tutorial uses Eclipse based Dialog Designer environment to demonstrate the
interaction between a Java client application and Web Service. However, the steps
involved in invoking a Web Service from a Java client application built using other
environments/platforms are similar.
1. Open a new Dialog Designer speech project called webservices in Dialog Designer (an
Eclipse plug-in). Create a call flow as per the requirements of the desired application.
As shown in the screenshot below, in this application, two announce nodes (welcome
and result) along with the Java servlet node are used.
The first announce node plays a welcome greeting to the caller. The Java servlet node
(shown below) acts as the client to access the required Web Service and the result
fetched from the Web Service is announced in the result node. In the example call flow
shown below, insert a Java servlet node (currencyconvertor) as shown below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

13 of 37
DDWeb_Services

2. Right-click on the Java servlet node and select the Edit currencyconvertor.java
option from the drop-down menu as shown below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

14 of 37
DDWeb_Services

3. Edit the servlet file to add the client side code which consists of the required URL to
access the WSDL file.
Note: If the application is executed from within a firewall, proxy settings may be required
to be configured. To configure proxy settings, ensure that the following code snippet is
included in the client servlet:
System.getProperties().put("http.proxyHost", "10.111.14.14");
System.getProperties().put("http.proxyPort", "8080");
System.getProperties().put("http.proxyUser", "username");
System.getProperties().put("http.proxyPassword", "password");

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

15 of 37
DDWeb_Services

4. Run the Speech project from the Eclipse IDE to get the output result. This output result
can then be announced using an announce node as shown below. Refer to Avaya
Dialog Designer Getting Started with Dialog Designer 4.0 ([1]) for help on running the
application.
This application can also be deployed on Avaya Voice Portal and Avaya Interactive
Response. For deployment procedures, refer to tutorial Deployment of Speech and
Call Control Applications on Avaya Voice Portal and Avaya Interactive Response
available on the DevConnect portal
(https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=446)

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

16 of 37
DDWeb_Services

2.2 Consuming a Web Service in Dialog Designer

Applications
This section describes how to access Web Services using the Web Service Operation Wizard provided by
Dialog Designer. The following steps provide an outline of the same (more information on this topic is
provided by reference [2]):
Step 1.

Create a new Speech project. Right click on the project and select New. Choose Web
Service Operation File as shown below. If Web Service Operation File is not visible,
select Other and then select Web Service Operation File from the Avaya Speech
Development option.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

17 of 37
DDWeb_Services

Step 2.

Enter an appropriate name in the File Name column and enter the Web Service URL in the
WSDL URL column as shown below. In the Authentication drop down, select No
Authentication. Click on the Load button; if the load is successful, a drop down list
containing the operation supported by the Web Service is displayed. Select
ConversionRate (currency, currency) operation. Click the Next button.

Step 3.

Create variables FromCurrency and ToCurrency by dragging a variable in the

flow/project.variables pane. The corresponding variables can then be selected from the
Variable Name drop down list as shown below. Click on Use Java Object, since these
variables are of object type Currency and not of any built-in data type. Click Next to
proceed.
In most of the cases, where variable names can be directly mapped to simple variables,
Auto Create is recommended. For more details on this, refer to Section 3.2.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

18 of 37
DDWeb_Services

Step 4.

The screen shown below is for mapping output parameters. Click Auto Create to
automatically create the variable ConverseRateResult and click Finish.

NOTE: Changes to creating and mapping of variables can also be done by editing the
WSOP file as shown in the screenshot below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

19 of 37
DDWeb_Services

Step 5.

Select the Application Flow view and drag the Data node from the Application Items
section in the palette as shown below. Rename the node.

Step 6.

Double click the Data node to open it. Drag the Web Service node from the palette and
select the WSOP file that was created earlier from the drop down list in the properties
window as shown below. Save the settings.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

20 of 37
DDWeb_Services

Step 7.

Make the changes in the webservices.java file. Include the code that follows to access
the Java object variables by over-riding the requestBegin (mySession) method as
shown below.

Currency src = Currency.INR;

Currency des = Currency.USD;
mySession.getVariable(IProjectVariables.FROM_CURRENCY).
getSimpleVariable().setValue(src,IVariableField.VarDataType.OBJECT);
mySession.getVariable(IProjectVariables.TO_CURRENCY).
getSimpleVariable().setValue (des,IVariableField.VarDataType.OBJECT);

NOTE: This is an optional step. The Web Service referenced in this tutorial needs input
variable types other than built-in data types. Hence, the application needs to map the DD
variables to the appropriate type required by the Web Service. This step is required only in
such cases. If the Web Service parameters are directly mapped to the input or output
variables, then this step is not required.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

21 of 37
DDWeb_Services

2.3 Summary
Consuming Web Services using standard Java tools demands an in-depth understanding of Web
Services and generating stubs using the WSDL2Java tool. Developers need to take care of correctly
passing values to Web Services and retrieving data from the responses. They are also responsible for
setting the desired header values.
In contrast to this, Dialog Designer provides a GUI interface known as Web Services Operation File
(WSOP) wizard for accessing Web Services. This wizard creates stubs, generates the client code and
also maps the variables used by the speech applications to the appropriate input/output variables.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

22 of 37
DDWeb_Services

Chapter 3: Creating a Web Service Operation

File
Web Service operation files, used within a speech application project to access and use Web Services,
are created using the Web Service Operation wizard. Refer to the above section for creating a Dialog
Designer Web Services Operation (WSOP) file. Existing WSOP files can be accessed as shown below.
Selecting connectivity > wsoperations > WSOP_file in the Navigator view.

The WSOP consists mainly of the following four sections:

1.
2.
3.
4.

Web Services Information.

Input and Output Parameters.
Authentication.
Headers.

These sections are explained in the following paragraphs.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

23 of 37
DDWeb_Services

3.1 Web Services Information

This section mainly consists of the WSDL URL and the timeout value for fetching the URL.
WSDL URL: WSDL URL is the URL of the WSDL file for the Web Service in standard HTTP or HTTPS
format. All Web Services have an associated WSDL file that describes what services the Web Service
provides. Dialog Designer uses this WSDL information to populate the Operation field list.
Note: Dialog Designer supports only WSDL files that contain unique method signatures. Dialog Designer
does not support operation overloading, or the use of methods with the same name but different
parameters.
Tip: If a Web Service has been previously created, Dialog Designer remembers the URL. For future Web
Service creations, Dialog Designer automatically populates this field with the URL. Dialog Designer keeps
track of the last twenty Web Services URLs used in operations.
Timeout: Sets the maximum time, in seconds, for fetching and parsing the WSDL file.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

24 of 37
DDWeb_Services

3.2 Input and Output Parameters

The Input and Output parameters signify the mapping of input/output parameters expected by the Web
Service to the values of variables in Dialog Designer. For example, for a Web Service that provides a
weather report, the expected input might be the name of a city; the expected output would be the weather
report string (mapped to the appropriate variable).
There are two options associated with Input/Output parameters:
1. Auto Create: If this option is selected for a parameter then Dialog Designer automatically
creates and names a variable and maps it to the corresponding parameter. If selected, Dialog
Designer clears the Variable Name and Variable Field values.
2. Use Java object: Indicates whether the content of the variable should be treated as a Java
object to prevent Dialog Designer from mapping it. Use this option when the structure of the
data to be sent to the Web Service is more complex than what can be contained within a
normal variable. When using this option, the following steps must be taken:
a. Create the Java object and store it in the variable, if sending the object to the Web Service.
b. Write the required Java code by overriding an existing method, such as the
requestBegin (SCESession mySession) method.
c. Retrieve the Java object from the variable, if receiving the object from the Web Service.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

25 of 37
DDWeb_Services

3.3 Authentication
Authentication selects how Dialog Designer should authenticate with the Web Service host. The
available options are:
a. No Authentication Username/password are not required for authentication.
b. Basic - Transmits the username/password pair in an unencrypted form from browser to server
in the HTTP header.
c. Digest - Transmits the username/password pair in an encrypted from the browser to server in
the HTTP header.
The username and password fields are displayed only when Basic or Digest authentication is selected.
Enter a username and optionally a password for authentication.

3.4 Headers
When the Web Service request is sent to the server, two types of headers can be included with the
request; headers included in the HTTP header section or SOAP headers. Both are configured in this
section. Each header must be given a unique name and the value for the header is taken from a Dialog
Designer variable.
The direction of the header can be set to IN, OUT or both IN and OUT. If the direction is set to IN, the
value of the header is taken from the Web Service response and stored in the selected DD variable. If the
direction is set to OUT, the value of the DD variable is added to a header sent with the Web Service
request. The screenshots for Headers are shown below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

26 of 37
DDWeb_Services

Chapter 4: Troubleshooting Dialog Designer

Web Services
Web Services are usually utilized with an http request and response based on SOAP. These requests
and responses need to be monitored during troubleshooting. Various tools can be used for this analysis.
The two tools mainly used for this are Wireshark and TCPMonitor. The usage of both these tools is
described in the following section.

4.1 Tracing SOAP requests using Wireshark

Wireshark is an open-source GUI based network protocol analyzer. It lets the user interactively browse
packet data from a live network or from a previously saved capture file. Wiresharks native capture file
format is the libpcap format, which is also the format used by tcpdump and various other tools. By
reading the file, Wireshark automatically determines the file format.
To capture the data using Wireshark, follow the steps described below.
Step 1.

Clicking on Capture > Options on the main menu in Wireshark opens the Capture Options
window shown in Step 2. The Capture Options dialog lets the user specify various
parameters for capturing live packet data.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

27 of 37
DDWeb_Services

Step 2.

The Capture Options window shown below contains the Interface field, which lets the user
specify the interface (source) from which to capture packet data or a command from which
to get the packet data via a pipe. Select the systems Ethernet (LAN) card from the
Interface drop-down list and click Start.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

28 of 37
DDWeb_Services

Step 3.

After clicking Start, run the application related with the Web Service to check the logs in
Wireshark and then click Stop as shown below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

29 of 37
DDWeb_Services

Step 4.

Like other protocol analyzers, Wireshark's main window shows three views of a packet. It
shows a summary line, briefly describing what the packet is. A packets detailed display is
also shown, allowing the user to narrow down the exact the protocol or field that he or she is
interested in (shown below).

Step 5.

Check the SOAP request and response and ensure that the correct values are passed
during the SOAP requests and responses.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

30 of 37
DDWeb_Services

4.2 Network monitoring using TCPMonitor

TCPMonitor is a utility that allows the user to monitor the messages passed along in TCP based
conversation. It is based on a swing user interface and works on almost all platforms that Java supports.
The steps to capture data using TCPMonitor are described next.
Step 1.

Starting the TCPMon (TCPMonitor is also referred to as TCPMon) utility. There are two
ways to accomplish this:
a. Open a command prompt (either by clicking Start -> Run and typing
cmd.exe or via Start -> Programs -> Accessories -> Command Prompt)
and change the directory to the Tomcat Lib directory. Make sure that the
Axis.jar file is present under this directory. An example path to
<Tomcat Home>/Lib directory is shown in the screenshot below. To open
TCPMonitor, type:
java cp axis.jar org.apache.axis.utils.TCPMonitor
as shown below.

b. Browse to the TCPMON build folder and run the tcpmon.bat file. The
TCPMonitor screen with the default settings should be displayed as shown
below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

31 of 37
DDWeb_Services

Step 2.

Open a Dialog Designer based Web Service application as shown below. Select a WSOP
file in the Navigator view under wsoperations folder and open it in the editor as shown
below.

Step 3.

Replace a section of the Endpoint URL as shown below to enable debugging using
TCPMonitor. The example describes the same using Currency Convertor Web Service.
Displayed URL: http://www.webservicex.net/CurrencyConvertor.asmx
New URL: http://localhost:9999/CurrencyConvertor.asmx
Save the WSOP file when done.

Note:
a. Any valid port that is currently not in use by another application can be used instead of
9999. Port 8080 should not be used as it currently used by Apache Tomcat.
b. Since a Web Service port is not specified in the existing URL, the default HTTP port 80
is used by this Web Service.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

32 of 37
DDWeb_Services

Step 4.

Change the TCPMonitor settings as shown below to reflect the changes made to the
Dialog Designer application.
Specify the Listen Port # as 9999.
Select the Listener radio button under the Act as a... option.
Specify the Target Hostname as www.webservicex.net
Specify the Target Port # as 80.
Click on the Add button to finalize the changes.

Note:
The Listen Port field value must match the value entered for the port on which the Web
Service end point is set.
The Target Hostname field value should be set to point to the Web Services server
(name/IP).
The Target Port value is the port number on which the Web Service operates.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

33 of 37
DDWeb_Services

Step 5.

Verify that a tab indicating the listener port is displayed as shown below.

Step 6.

Click on the tab and verify the port numbers. A waiting for connection message
should also be displayed as shown below.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

34 of 37
DDWeb_Services

Step 7.

View the Web Service details in the TCPMonitor display as shown below. Click on the
Save button to save the information displayed to a file. The top pane in the screenshot
shows Web Service SOAP header information and the bottom pane displays the SOAP
message body.

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

35 of 37
DDWeb_Services

References
[1]

Getting started with Dialog Designer.

Available at:
- Dialog Designer 4.1 CD-ROM (which includes the software).
- Dialog Designer 4.1 as CD-ROM image downloadable from the Avaya DevConnect web site
at: http://www.avaya.com/devconnect.

[2]

Avaya Dialog Designer Developers Guide.

The guide is included as part of Dialog Designer software install.
In Eclipse, click Help (menu) > Help Contents > Dialog Designer documentation.

[3]

Web Services Description Language (WSDL) 1.0.

http://xml.coverpages.org/wsdl20000929.html

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

36 of 37
DDWeb_Services

2008 Avaya Inc. All Rights Reserved.

Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are
registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of
their respective owners. The information provided in this tutorial is subject to change without notice. The
configurations, technical data, and recommendations provided in this tutorial is believed to be accurate
and dependable, but is presented without express or implied warranty. Users are responsible for their
application of any products specified in this tutorial.
Please e-mail any questions or comments pertaining to this tutorial along with the full title name and
filename, located in the lower right corner, directly to the Avaya DevConnect Program at
[email protected].

AS; Reviewed:
SPOC 6/3/2008

Solution & Interoperability Test Lab Tutorial

2008 Avaya Inc. All Rights Reserved.

37 of 37
DDWeb_Services