W3C home > Mailing lists > Public > public-sws-ig@w3.org > March 2006

RE: Semantics of WSDL vs. semantics of service

From: Shi, Xuan <xshi@GEO.WVU.edu>
Date: Thu, 16 Mar 2006 12:18:39 -0500
Message-ID: <D81F456794C18B4DA3E2ABC47DBBEEF2094FC0@www.geo.wvu.edu>
To: "'Kunal Verma '" <verma@cs.uga.edu>, "'public-sws-ig@w3.org '" <public-sws-ig@w3.org>
Cc: "Shi, Xuan" <xshi@GEO.WVU.edu>


Thanks very much for your kind information. I know it may be a long story to
describe the whole process about OSRR but I'd like to explain it and why it
is much easier and simpler for use.

First, let's see WSDL/SOAP. WSDL is the product of Object Oriented
Programming thus it contains the abstract interfaces that we designed in the
program. When we deploy the service, computers on the requester side will
automatically generate SOAP message through the process of serialization.
When computers on the provider side receives the SOAP message, it will
deserialize the SOAP message into proprietary programming language to
process the request, and then send the response back to the request via the
serialzation/deserialization process.

Given the following examples as you know,


those complex types are just the corresponding parts in OOP. I have detailed
explanation on how to derive the x,y coordinates from OOP in the article
http://www-128.ibm.com/developerworks/library/ws-semantic/ once you get a
LocationInfo object in OOP and complexType in WSDL.

However, OSRR gets rid of ALL such kind of complexType in the service
request and response document. So your comments is not correct as I do not
capture the same information within a WSDL document, but rather, only those
information relevant to the service request and response.

In this case, when you tell me your address, I will send you back the
longitude and latitude of your address as well as the information about the
datum of the survey to locate your address.

However, in WSDL or OOP, before you get the longitude and latitude of your
address, you may wish to check if it is true that you at least have to go
through more than a dozen varied types or complexTypes in WSDL or
corresponding objects in OOP once you invoke the service and get back a
locationInfo object in version 2 or GeocodeInfo object in version 2006.

For now, can you see the value of OSRR? In OSRR, I just have one function
interface for ALL operations that can be identified in WSDL. As you see, I
use the same service (WSDL) URL and the same function interface to invoke
different functions and services (geocoding or data conversion). How I
process the request is based on the request XML document sent to me.

As for geocoding service, you just need to type such a request document and
you will get the answer explicitly without worrying about how to deal with
more than a dozen types and complexTypes in WSDL and further the same
corresponding objects in OOP-actually you do not need to write a single

By WSDL approach, you have to figure out the relationship among those
complex types, operations, etc. and you have to write a program to consume
the service. In OSRR, you can ignore everything but just "compose" a service
request document and invoke the service in either SOAP or REST approach.

So if you agree that OSRR is more easier, simpler, understandable to ALL
users, then you can see the value of it. 

One key issue here is that, I just focus on the messages within SOAP that
are relevant to the *meaning* of the service. I ONLY pick up such relevant
message as the base to compose a request and response document. Finally, I
can get rid of WSDL/SOAP and send such message directly over HTTP-that's the
core for OSRR.

Best wishes,


-----Original Message-----
From: Kunal Verma
To: public-sws-ig@w3.org
Cc: xshi@GEO.WVU.edu
Sent: 3/16/06 11:26 AM
Subject: Re: Semantics of WSDL vs. semantics of service


I read your paper and saw the WSDL files posted in your message. I was
not able to understand your point with respect to semantics or ease of
use. Others have already replied about your notion of semantics, so
this message pertains to your claim that your approach is easier to

See comments inline.

>  <<GeocodingConversionServiceDescription.xml>>
> Carine, Bijan, colleagues,
> I read those recent messages under this thread, and want to reply to
all of
> them in this email. I hope we can discuss relevant issues rationally.
> Fact 1: many service providers provide the same kind of service in
> ways. Address geocoding is a typical example. All service providers
> the same service semantics: if the requester sends an address to
> then provider will return latitude and longitude of the input address
> to requester.
> Fact 2: requesters don't care about how provider process their request
> just want to get an answer.
> Fact 3: different service providers can create the same service in
> ways, either by SOAP/WSDL or REST, with different business logics. For
> example, ESRI, geocoder.us, google maps, etc.
> Based on such facts, can we draw conclusion that service semantics are
> neutral and independent from the service development framework and
> By targeting at the address geocoding Web services which can be
> in the WSDL documents listed below,
> http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl
> http://arcweb.esri.com/services/v2/AddressFinder.wsdl
> I wonder if Bijan can tell us which elements in these WSDL documents
> worthy to have semantic annotations or pointers (internal or external)
> which ones are not? Supposed, as Bijan said, we can create a rich
> description document with detailed content about the service, then why
do we
> need to associate such rich semantic description document with WSDL?
We can
> invoke the service directly over HTTP based on such rich service
> description.
> It seems Bijan does not believe that I can use the same service
request to
> invoke either a SOAP/WSDL service or a REST service. Please forgive me
if I
> need to repeat something that had been repeated before.
> Also Carine has a concern in her reply message
> http://lists.w3.org/Archives/Public/public-sws-ig/2006Mar/0048.html
> All such concerns were covered in the paper "Rebuilding the Semantic
> Service Architecture" in which the so-called OSRR approach was
> proposed, discussed and demonstrated. This paper can be accessed at:
> The five building blocks can answer all Carine's questions. Attached
is a
> service description document for demonstration and discussion. In this
> document, it contains two different service domains, one is geocoding
> service, the other is data conversion service. If you read the five
> blocks for each service, then you can understand how to deploy the
> since everything is self-describing.

It seems to me that you capture exactly the same information in your
service description as a WSDL file. You can probably write code or
XSLT even mappings to convert to WSDL to your format. It is not clear
to me what the value of doing that, since it is almost the same

Since, WSDL is flexible to support mutiple binding, you lose a lot of
information in your service desription. You can look see WSDL
bindings, which includes HTTP binding at:

As an exercise, you can create a sercie description for the your wsdl.

Please make sure that you create it for all the operations and keep
the complex types as they are, not take a snippet of the data. Then
compare them and try to see if a non programmer can understand that
easier than WSDL.

> I also designed a Web interface for demonstration, especially for
Bijan so
> that Bijan can believe OSRR is not just an assertion. The Web
interface can
> be accessed for now at:
> In this example, for ALL SOAP-based Web services, they just have ONE
> standardized interface:
> Function getService(String request):String response
> For REST service, I developed a HTTP server which is waiting for a
> message as service request.
> Both service (WSDL) URL and server URL can be identified in the
> document.
> To deploy the service, you have to compose an XML document as service
> request. First, write the following line in any text editor:
> <?xml version="1.0" encoding="utf-8"?>
> Then, copy and cut the whole section of <ServiceRequest> section
within the
> <RequestTemplate> of a specific service and function described in the
> document, and then paste it into your text editor under the line you
> typed, then now it should be:
> <?xml version="1.0" encoding="utf-8"?>
> <ServiceRequest>
>        <Service Name="Geocoding">
>                <Function Name="Geocoding">
>                        <InputVariables>
>                                <Address>
>                                      <Street></Street>
>                                      <City></City>
>                                      <State></State>
>                                      <ZipCode></ZipCode>
>                                </Address>
>                        </InputVariables>
>                </Function>
>        </Service>
> </ServiceRequest>

If a Web service always had to interact with a person, one could
always generate a form from the WSDL, which would be easier than the
XML based template.

> The last thing you have to do is assign the value of the input
> i.e. the information to compose your address (street, city, state,
> This is the service composition process, easy, simple, understandable,
> right? People don't need to write a single code.

This is not service composition. All you are doing is invoking a

> Once you compose a service request, put it within the "Request" text
box on
> the Web interface.
> If you want to use SOAP/WSDL Web service, then copy the service (WSDL)
> into the text box for WSDL URL. Or, if you want to use REST Web
> then copy the server URL into the text box for REST URL. Then click
> "Send Request" button, you can get the result which should exactly
> the format specified in the <ResponseTemplate> section of the
> document.
> If anyone want to try the data conversion function and service, just
> the same steps as mentioned above. You can use exactly the same
> interface and URL to invoke another kind of service.
> Since SOAP/WSDL service in this case just has ONE function interface,
it is
> so easy to create a dynamic service invocation.
> SOAP/WSDL are only for programmers. How many programmers are there in
> world that can consume such kind of services? However, for
> don't you think it's so easy for them to process such an XML document?
> importantly, since the service semantics keep the same when the
> keep changing as demonstrated by the three versions of ESRI's
services, for
> service requesters, the programmers do NOT need to change anything if
> just process such an XML document of semantic service request, which
can be
> used by all three versions of the same service with different

See point about creating a complete service description for a complex
WSDL above.

> OSRR is for all users. As demonstrated, people do not need to know any
> of programming languages. They just need a text editor to compose an
> document for service request. The composition process is almost just a
> cut-copy-paste process. They do not need to know any details about
> aggregation or mediation processon the server side (my paper published
> IBM already demonstrated that ALL kind of composite services can be
> transformed into an atomic one). In OSRR, there is no process, just
> service request and one service response. Actually, if I don't tell
you, how
> do you know which geocoding server and which server for data
conversion I
> wrapped in my applications-they are not in my machine?
> By now I hope Bijan can believe such an assertion that the same
> request can be used to invoke either SOAP or REST service. If further
> want me to demonstrate how the same service request can be used to
> the same service offered be different service providers with different
> business logics, I'd be happy to do that.
> At last, my question then is, since the same service and function can
> deployed by REST service, why do we need the
> process, which means, WSDL can be deprecated, although many people are
> happy to see such a conclusion.
> As for service semantics, we need more standards and agreements on
> describing the meaning of the service. If we can describe it, then we
> invoke it directly over HTTP without SOAP/WSDL. It is not an
assertion, but
> now a demonstrated fact.

> Best wishes,
> Xuan

Kunal Verma,
LSDIS Lab, Dept. of Computer Science,
University of Georgia.
URI: http://lsdis.cs.uga.edu/~kunal
Cell: 706 254 3330
Received on Thursday, 16 March 2006 17:19:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:52 UTC