Web Services Technology Stack

(WSDL and UDDI)

Shahram Esmaeilsabzali
(sesmaeil@mail.student.math.uwaterloo.ca)

What we will cover

WSDL and its elements
UDDI registries and APIs
A Web service using ASP.NET and C#

Web services conceptual stack

Other business rules
Web Services Flow Language (WSFL, XLANG and )
Universal Description, Discovery and Integration (UDDI)
Web Services Description Language (WDSL)
Simple Object Access Protocol (SOAP)
Extensible Markup Language (XML)
Common Internet Protocols (TCP/IP, HTTP, )

Core

Emerging

WSDL
Defined in a joint effort by Ariba, IBM and
Microsoft
An XML format for describing Web Services
interfaces as collection of ports
WSDL = IDL + Binding + Service location
IDL: types and operations
Binding: how to access via protocol (E.g. SOAP, HTTP POST
or HTTP GET)
Location: Where to connect to the Web service

WSDL works over multiple protocols and

technologies using extensibility elements

WSDL Elements
Abstract Elements:
Types: Data type Definition
Messages: Format of Data being communicated
Operations: Description of an action
Port types: set of operations

Concrete Elements:
Bindings: a concrete protocol and data format
specification for a particular port type
Ports: a single endpoint defined as combination of
Binding+ Network address
Services: a collection of related ports (endpoints)

WSDL Elements Relationship

Abstract Reusable Elements

Concrete Elements

Types
Encloses data type definitions that are building blocks
of exchanged messages
W3C XML Schema as canonical type system
Also allows type systems other than XML Schema to be
added via extensibility elements
<wsdl:types> ?
<wsdl:documentation .... />?
<xsd:schema .... />*
<-- extensibility element --> *
</wsdl:types>

Messages
Messages consist of one or more logical parts
part name is a unique name among all other parts
of a message
Each part is associated with a type or Element
Parts are a flexible mechanism for describing the
logical abstract content of a message
Using XML Schema as type system, WSDL uses:
Element: Refers to an XML Schema element
Type: Refers to an XML Schema simple or complex type
<wsdl:message name="nmtoken"> *
<wsdl:documentation .... />?
<part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>

Example
ExchangeRate C# class is exposed as an ASP.NET
Web Service by simply Placing the below C# code in
a .asmx file. This file is then put in a directory of an
ASP.NET web application (Simple scenario)
<%@ WebService Language="C#" Class="ExchangeRate" %>
using system
using system.web.services
[WebService(Namespace=http://www.example.com/services)]
public class ExchangeRate
{
[WebMethod]
public float ExchangeRateRequest (string SourceCurrencySymbol,
string TargetCurrencySymbol)
{
return 0.7;
// real application makes a database call to retrieve exchange rate
}

Example
<types>
<schema targetNamespace= "http://example.com/exchangerate.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="ExchangeRateRequest">
<complexType>
<sequence>
<element name="SourceCurrencySymbol" type="string"/>
<element name="TargetCurrencySymbol" type="string"/>
</sequence>
</complexType>
</element>
<element name="ExchangeRateRequestResponse">
<complexType>
<all>
<element name="ExchangeRateRequestResult" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="ExchangeRateRequestSoapIn">
<part name="body" element="ExchangeRateRequest"/>
</message>
<message name="ExchangeRateRequestSoapOut">
<part name="body" element= "ExchangeRateRequestResponse"/>
</message>

PortType
Port Types are set of operations and the messages
involved
WSDL has four transmission primitives
(operations):
One-way
Request-response
Solicit-response
Notification

One-way Operation
The endpoint receives a message
They are the simplest mechanism, and it is
supported only by MIME protocol (HTTP
based protocols are two-way)
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

Request-response
The endpoint receives a message, and sends
a correlated message
input element: abstract request message
output element: abstract response message
fault element: optional abstract error message
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault
name="nmtoken" message="qname"/>*
name="nmtoken">
<wsdl:portType
</wsdl:operation>
<wsdl:operation
name="nmtoken" .... /> *
</wsdl:portType >
</wsdl:portType>
</wsdl:definitions>

Solicit-response operation
The endpoint sends a message, and receives
a correlated message
Output: Abstract solicit request message
Input: Abstract response message
fault element: optional abstract error message
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
name="nmtoken">
<wsdl:portType
</wsdl:operation>
<wsdl:operation>name="nmtoken" .... /> *
</wsdl:portType
</wsdl:portType>
</wsdl:definitions>

Notification Operation
The endpoint receives a message
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:output name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

WSDL Elements Relationship

Abstract Reusable Elements

Concrete Elements

Binding

A binding defines message format and protocol

details for operations and messages defined by
a particular portType
<wsdl:definitions .... >
<wsdl:binding name="nmtoken" type="qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name="nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name="nmtoken"? > ?
<-- extensibility element (3) -->
</wsdl:input>
<wsdl:output name="nmtoken"? > ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name="nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

Ports
A port defines an individual endpoint by
specifying a single address for a binding.
Ports are building blocks of Web services
Within a Service they have the following
relationships:
None of ports communicate with each other (WSDL
specification requirement)
Several ports could implement a single portType
ports can be examined by consumer for checking their
desired operations
<wsdl:port name="nmtoken" binding="qname">*
<wsdl:documentation .... /> ?
<-- extensibility element -->
</wsdl:port>

Service
A service groups a set of related ports
together
<wsdl:service name="nmtoken"> *
<wsdl:documentation .... />?
<wsdl:port name="nmtoken" binding="qname"> *
<wsdl:documentation .... /> ?
<-- extensibility element -->
</wsdl:port>
<-- extensibility element -->
</wsdl:service>

Example

<portType name="ExchangeRateSoapPort">
<operation name="ExchangeRateRequest">
<input message="ExchangeRateRequestSoapIn"/>
<output message="ExchangeRateRequestSoapOut"/>
</operation>
</portType>
<binding name="ExchangeRateSoapBinding" type="ExchangeRateSoapPort">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ExchangeRateRequest">
<soap:operation soapAction="http://example.com/services/ExchangeRateRequest"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="ExchangeRate">
<port name="ExchangeRateSoap" binding="ExchangeRateSoapBinding">
<soap:address location="http://example.com/services/exchangerate.asmx"/>
</port>
</service>

Import element
Import element allows the separation of elements
in a WSDL document
It is a good practice to have at least two separate
WSDL documents: Service interface definition
and Service implementation definition
Using Import, introduces features for reusability
and abstract interface definitions like object
oriented programming
Multiple businesses may implement and advertise
the same WSDL interface and service requesters
could effectively search for their desired service

Web services conceptual stack

Other business rules
Web Services Flow Language (WSFL, XLANG and )
Universal Description, Discovery and Integration (UDDI)
Web Services Description Language (WDSL)
Simple Object Access Protocol (SOAP)
Extensible Markup Language (XML)
Common Internet Protocols (TCP/IP, HTTP, )

Core

Emerging

What is UDDI?
UDDI defines a set of services supporting the
description and discovery of:
Businesses, organizations, and other Web services
providers (White Pages)
Web services which businesses make available
(Yellow Pages)
Technical interfaces which may be used to access
those Web services (Green Pages)

UDDI is based on a set of web standards including

HTTP, XML, XML Schema, WSDL and SOAP,
and is supported by many companies (HP, IBM,
Microsoft and )

What is UDDI?
UDDI specification provides a platformindependent way of describing, discovering and
integrating Web services using Internet
UDDI Infrastructure is appropriate for both public
and private Web Services-based environments
UDDI data is hosted by nodes which could be
collected, using replication mechanism, to form
UDDI registries
UDDI provides a set of APIs for inquiring and
manipulating UDDI elements

UDDI core data structures

All Data structures are

XML based

Many UDDI data

structures including
the four core data
structures are accessed
via unique identifiers
that are either
generated by registries
or by the publisher
itself

UDDI core data

structures support
mechanisms for
electronic signatures
( XML-Signature
syntax )

UDDI tModel

Technical models or tModels are

essential UDDI elements used to
represent unique concepts,
constructs or metadata

tModels are represented by their

unique keys

tModels are extensibility means for

UDDI

tModels are reusable entities which

can be referenced by other entities
like bindingTemplates

The bindingTemplates referencing

the same tModels are said to have
the same technical fingerprints

Their typical applications are in

WSDL definition, dynamic
categorization and search systems
(identifierBags and CategoryBags)

tModels can be used to extend

existing categorization and search
systems for entities

UDDI businessEntity structure

Each businessEntity contains

descriptive information
about a business or
organization and, through its
contained businessService
entities, information about
the services that it offers.

identifierBag element allows

businessEntity structures to
be identified according to
published identifier systems
(E.g. DUNS numbers), the
systems themselves are
registered tModels elements

The categoryBag contains a

predefined list of business
categorization that each
describes a specific business
aspect of the businessEntity.
Examples of categories are
industry, product category or
geographic regions

UDDI businessServices structure

The businessService
structure represents a
logical service and
contains descriptive
information in business
terms.
A
businessService is the
logical child of a single
businessEntity

A businessService may be
projected to other
businessEntities by
reference instead of
containment.
Projections to the same
service can be made in any
number of business
entities.

bindingTemplates is a list
of technical descriptions
for the Web services.

UDDI bindingTemplate Structure

Technical descriptions of Web

services are provided by
bindingTemplate entities.

The accessPoint element is an URI,

typically a URL, representing the
network address of the Web service
being described. There are four types
of accesspoints:

endpoint (Network address of Web

service)

bindingTemplate

hostingDirector

WSDL Deployment

tModelInstanceDetails element
contains the technical fingerprint of
the Web service.
During an inquiry, interested
parties can use this information to
look for bindingTemplate entities that
contain a specific fingerprint or partial
fingerprint.

UDDI APIs
UDDI APIs are programmatic tools for querying
and manipulating UDDI registry data
UDDI APIs are exposed as SOAP messages over
HTTP or HTTPS
UDDI APIs are categorized to six groups:
Inquiry APIs: Locates and obtains details of UDDI data
Publishing APIs: Publishes and updates UDDI data
Security APIs: Requests and discards authentication data
Custody transfer APIs: Transfers ownership of elements
Subscription APIs: provides clients with information about
changes in UDDI data
Value set APIs: Checks the validity of referenced tModels

Some UDDI APIs

Inquiry API
Find things

find_business
find_service
find_binding
find_tModel
find_relatedBusinesses

Get Details about things

get_businessDetail
get_serviceDetail
get_bindingDetail
get_tModelDetail
get_operationalInfo

Publishers API
Save things

add_publisherAssertions
set_publisherAssertions
save_business
save_service
save_binding
save_tModel

Delete things

delete_business
delete_service
delete_binding
delete_tModel
delete_publisherAssertion

Query things
get_assertionStatusReport
get_publisherAssertions
get_registeredInfo

Example
<businessService
businessKey="uddi:example.com:ExchangeRateCo"
serviceKey="uddi:example.com:service">
<name>ExchangeRate </name>
<description> This Service Exchanges rates </description>
<bindingTemplates>
<bindingTemplate servicekey=uddi:example.com:service
bindingKey="uddi:example.com:binding">
<description xml:lang="en">
This is a Binding for ExchangeRateService
</description>
<accessPoint useType=wsdlDeployment>
http://www.example.com/services/exchangerate.wsdl
</accessPoint>
<tModelnstanceDetails>
<tModelnstanceInfo
tModelKey="uddi:example.com:serviceInterface">
</tModelnstanceInfo>
</tModelnstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>

How does it work?

Service
Provider

(5) Execute Service

(SOAP)

(1) Publish (WSDL)

(3) Retrieve Service
Description (WSDL)

UDDI

(0) Create the

Web Service

Service
Requester

(2) Find Service and

Retrieve its address (UDDI)

(4) Create Proxy class

Web services and Proxy classes

Proxy classes are generated according to WSDL
information to call the Web services on behalf of
the service requesters
Proxy classes hide the complexity of dealing with
SOAP, XML and network protocols
Once Proxy classes are generated, they are
compiled (in this case to a .NET DLL file) and can
be used by other programs
Some proxy classes settings can be modified at
run-time; so for example, if the location of a Web
service is changed proxy class is not required to be
regenerated

Accessing a Web Service with ASP.NET page

<%@ Page Language = C# Debug=true %>
<%@ Import namespace = CurrencyExchange %>
<script Language=C# runat=server>
void GetExchangeRate (System.Object sender, System.EventArgs e)
{
ExchangeRate ws = new ExchangeRate();
lbvalue.Text = ws.ExchangeRateRequest (txtsource.Text, txtdest.Text);
}
</script>
<html>
<body>
<form id=Form1 method=post runat=server>
<strong> Enter the source and destination currency symbols</strong> <br />
<asp:TextBox id = txtsource runat=server> </asp:TextBox> <br />
<asp:TextBox id = txtdest runat=server> </asp:TextBox> <br />
<asp:Button id= Button1
runat=server
Text=Submit
onClick=GetExchangeRate > <br />
....
</html>

Web Services future

While Web services have

focused on technological
foundations for
implementing simple Web
services, they are not
sufficient for using Web
services in critical business
application, the following
are important areas of
research in Web services :
Web Services
Composition
mechanisms for Web
Services work flow
and coordination
comprehensive
security solutions
Web services
transactions

Other business rules

Web Services Flow Language (WSFL, XLANG and )
Universal Description, Discovery and Integration (UDDI)
Web Services Description Language (WDSL)
Simple Object Access Protocol (SOAP)
Extensible Markup Language (XML)
Common Internet Protocols (TCP/IP, HTTP, )

Core

Emerging

A comparison
CBD technologies
No standard format for data
exchange and encoding
RPC mechanisms
IDL
Registry information
Partly platform independent
and usually extremely tightlycoupled
Complex transfer and
conversation protocols
CDB paradigm Provides
solutions for wide area of
applications

WS technologies
Uniform encoding mechanism
XML
SOAP
WSDL
UDDI
Platform neutral, highly
loose-coupled and crossplatform technology
Using easy open-standard
protocols
Existing WS technology is
suitable for rather simple
applications