Re: Generic WSDL Question

Discussion in 'XML' started by Andy Dingley, Nov 19, 2003.

  1. Andy Dingley

    Andy Dingley Guest

    On 17 Nov 2003 14:01:45 -0800, (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
    them.

    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
     
    Andy Dingley, Nov 19, 2003
    #1
    1. Advertising

  2. Andy Dingley

    Rob Tweed Guest


    >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 (www.mgateway.com/extc.htm), and our online WSDL
    validator (www.mgateway.com/wsdlClient.htm) 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
    method.

    - 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
    functions.






    ---
    Rob Tweed
    M/Gateway Developments Ltd

    Global DOMination with eXtc : http://www.mgateway.tzo.com
    ---
     
    Rob Tweed, Nov 20, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dark
    Replies:
    1
    Views:
    4,634
    milfar
    Nov 14, 2008
  2. Chris Bedford
    Replies:
    0
    Views:
    586
    Chris Bedford
    Aug 21, 2003
  3. Sandy Dunlop

    Re: Generic WSDL Question

    Sandy Dunlop, Nov 18, 2003, in forum: XML
    Replies:
    1
    Views:
    401
  4. Stephen Edgecombe

    WSDL.EXE: WSDL Import Directive

    Stephen Edgecombe, Aug 13, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    240
    Stephen Edgecombe
    Aug 13, 2003
  5. RH
    Replies:
    1
    Views:
    265
    Dino Chiesa [Microsoft]
    May 27, 2004
Loading...

Share This Page