Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > XML > Re: Generic WSDL Question

Thread Tools

Re: Generic WSDL Question

Andy Dingley
Posts: n/a
On 17 Nov 2003 14:01:45 -0800, Removed) (jm) wrote:

>What I am trying to find out is when an introduction to WSDL says
>"after building a web service, one publishes a WSDL to tell users how
>to get to the service..."

WSDL doesn't "tell users how to get to the service". That bit is the
job of UDDI (how to find a service that does what you want, such as
"Show me bookshops that offer on-line ordering").

When they've got there, WSDL then tells them how to call it. If you
want to buy a book on-line from Amazon, it tells you how to structure
the request with the book's ISBN and your account or shipping details.
It also tells you what to expect as a response.

An intermediate step is "choreography" (how to use services). This
describes the steps of "We offer services from this site to search for
books and find the ISBN of anything we stock, services to find
recommendations of similar books, or services to order a book by ISBN
alone. We do not support ordering by title - please search the ISBN
first, then use that"

At present, WSDL is commonplace, but more is generated than it's
actually used. If WSDL is used, it's imported into an editor
environment used to author a client more or less by hand, but with
automatic support.

It's also still rare to have automatic agents that can use WSDL "on
the fly" (perhaps it buys books from Amazon, but can automatically
find how to use Abe's services if it's out of print).

>how does one create a web service?

You read books about SOAP, then write some code for any dynamic web
server, in any language you like.

If you want an easier life, you use a middleware product like
WebLogic, WebSphere, or many others. Most of a web service's coding
effort is in binding the "web service bit" to the "back-end code" bit.
There's no need to write this each time, so use a middleware layer.

ASP .NET can also create web services.

>If I use
>WSDL, does that mean I don't have ASP .NET pages anymore and do it in
>something else?

The first "web services" scraped HTML from an existing site, then
re-formattted that with horrible great pieces of unstable hand-written
code. They were enormously useful, but evil to code and especially so
to maintain.

So the idea was a good one, but it needed a stable basis. Standards
were thus developed (SOAP, WSDL, etc.) to allow this in a well-ordered
cross-platform way. Then the middleware products appeared to support

Any "service" on the "web" is a web service. But a _useful_ web
service now means one that complies with the common standards, and so
is easily used by other tools. Remember the guiding principle of the
web - you've never met your users, and you have no idea what tools
_they_ use. If you stick with the standards, then all works out well.

Most web services are built from Java and commercial middleware, but
that's for convenience more than anything else. Being standards based,
they also communicate well. You can then use any tool to build clients
for them (I often use client-side JavaScript directly on a browser).

If you turn to the dark side of .NEt though, things are less
influenced by standards and more by the evils of M$oft. They would
_love_ to build services that don't co-operate with other platforms,
and so flawed ideas like BizTalk keep re-surfacing. Although you can
write .NET without knowing anything of SOAP or WSDL, you ought to, to
ensure that you're still playing by the world's rules, not Seattle.

Welcome to Seattle - Twinned with Dis

Reply With Quote
Rob Tweed
Posts: n/a

>At present, WSDL is commonplace, but more is generated than it's
>actually used. If WSDL is used, it's imported into an editor
>environment used to author a client more or less by hand, but with
>automatic support.
> It's also still rare to have automatic agents that can use WSDL "on
>the fly" (perhaps it buys books from Amazon, but can automatically
>find how to use Abe's services if it's out of print).

As Andrew points out, the idea of WSDL is to formally describe the
SOAP (or other) method in terms of things like its request and
response structure and where to send the request. There's enough
information in a WSDL document to automatically create the request,
send it and break down the response, but again as Andrew says, there's
not much software out there that can do this today.

One example of software that does provide an automated client agent is
our eXtc product (, and our online WSDL
validator ( uses this technology to
automatically build and interface to and run any web service for which
a WSDL exists. Give it a go and it may help you to "get" what Web
Services are all about and why they are so cool - and important.

The way I describe the layers that make up web services is as follows:

- at the bottom of the stack are the methods that you want to make
available - perhaps legacy business logic that you'd like to expose to
a wider audience.

- to make this available by Remote Procedure Calling (RPC) you need a
wire protocol and a syntax for describing the method request and
response. In Web Services, most people use HTTP as the wire protocol,
and SOAP (a specific use of XML) is the syntax that is used to
formally describe the RPC request and response.

- the client system that wants to invoke your method expresses the
request to run it, and the run-time parameter values, in terms of XML
- a SOAP request. This is shipped as the payload of an HTTP request
to your system - actually to your web server.

- your web server passes the XML/SOAP request to your back end system
where it is parsed, recognised as a request to run your method and the
run-time parameters extracted so your system can now run that legacy

- the results of your method are then packaged up as XML - a SOAP
response - and sent back, via HTTP to the awaiting client system. It
then uses the WSDL document to work out how to extract the response
values from the SOAP response it received.

- all this stuff should end up being hidden behind the scenes. The
client system will probably actually just run some method or function
that appears, to all intents and purposes, to be a local method, but
behind the scenes has done all the stuff above and actually run your
method remotely.

- WSDL is used to describe your SOAP method(s). In order for someone
to know what methods you have and how to run them, all someone needs
is the URL to fetch your WSDL document. You don't need to provide any
other documentation or send emails or spend time on the phone to
programmers to explain how your SOAP methods can be run. The WSDL
gives them all the information they (or ideally their software) needs.

- UDDI may be used so that people can discover that you have
particular services available - essentially a searchable directory of
services. Typically this will provide the URL to your WSDL which in
turn describes your SOAP methods which in turn wrapper your business

Rob Tweed
M/Gateway Developments Ltd

Global DOMination with eXtc :
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
webservices, wsdl & xsd (schema-2-wsdl) Dark Java 1 11-14-2008 07:58 PM
WSDL file produces useless class when imported with WSDL.exe RH ASP .Net Web Services 1 05-27-2004 09:40 PM
Re: Generic WSDL Question Sandy Dunlop XML 1 11-18-2003 08:07 PM
is the w3c's schema for wsdl and wsdl/soap binding possibly buggy ? _clb_ Chris Bedford XML 0 08-20-2003 11:52 PM
WSDL.EXE: WSDL Import Directive Stephen Edgecombe ASP .Net Web Services 0 08-13-2003 06:38 AM