Академический Документы
Профессиональный Документы
Культура Документы
Designer Applications
Prerequisites ....................................................................................................................... 3
2.3 Summary.............................................................................................................. 22
3.4 Headers................................................................................................................ 26
References..................................................................................................................................... 36
• 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.
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.
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.
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
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.
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.
<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>
<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.
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
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:
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:
iii. Click the New button shown below to add a System Variable.
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.
If the –t option is specified on the command line, the test case is also created along with
the required stubs.
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.
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");
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)
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.
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.
NOTE: Changes to creating and mapping of variables can also be done by editing the
WSOP file as shown in the screenshot below.
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.
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.
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.
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.
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.
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.
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.
Step 5. Check the SOAP request and response and ensure that the correct values are passed
during the SOAP requests and responses.
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.
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.
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.
Step 6. Click on the tab and verify the port numbers. A waiting for connection… message
should also be displayed as shown below.
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
devconnect@avaya.com.