RE: Semantics of WSDL vs. semantics of service

Kunal,

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,

http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl
http://arcweb.esri.com/services/v2/AddressFinder.wsdl

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

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,

Xuan
 

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

Xuan,

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

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
different
> ways. Address geocoding is a typical example. All service providers
share
> the same service semantics: if the requester sends an address to
provider,
> then provider will return latitude and longitude of the input address
back
> to requester.
>
> Fact 2: requesters don't care about how provider process their request
but
> just want to get an answer.
>
> Fact 3: different service providers can create the same service in
different
> 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
process?
>
> By targeting at the address geocoding Web services which can be
identified
> 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
are
> worthy to have semantic annotations or pointers (internal or external)
and
> which ones are not? Supposed, as Bijan said, we can create a rich
service
> 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
Web
> Service Architecture" in which the so-called OSRR approach was
originally
> proposed, discussed and demonstrated. This paper can be accessed at:
>
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-140/paper1
.pdf
>
> 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
building
> blocks for each service, then you can understand how to deploy the
service
> 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
information.

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:
http://www.w3.org/TR/wsdl20-bindings/


As an exercise, you can create a sercie description for the your wsdl.
http://www.arcwebservices.com/services/v2006/AddressFinder.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:
>
> http://157.182.136.76/xshi/disst/discovery/Webform3.aspx
>
> 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
POST
> message as service request.
>
> Both service (WSDL) URL and server URL can be identified in the
attached
> 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
just
> 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
variables,
> i.e. the information to compose your address (street, city, state,
zip)
>
> 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
service.

> 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)
URL
> into the text box for WSDL URL. Or, if you want to use REST Web
service,
> then copy the server URL into the text box for REST URL. Then click
the
> "Send Request" button, you can get the result which should exactly
follow
> the format specified in the <ResponseTemplate> section of the
description
> document.
>
> If anyone want to try the data conversion function and service, just
follow
> the same steps as mentioned above. You can use exactly the same
service
> 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
the
> world that can consume such kind of services? However, for
programmers,
> don't you think it's so easy for them to process such an XML document?
Most
> importantly, since the service semantics keep the same when the
interfaces
> keep changing as demonstrated by the three versions of ESRI's
services, for
> service requesters, the programmers do NOT need to change anything if
they
> just process such an XML document of semantic service request, which
can be
> used by all three versions of the same service with different
interfaces.

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
kind
> of programming languages. They just need a text editor to compose an
XML
> document for service request. The composition process is almost just a
> cut-copy-paste process. They do not need to know any details about
service
> aggregation or mediation processon the server side (my paper published
by
> IBM already demonstrated that ALL kind of composite services can be
> transformed into an atomic one). In OSRR, there is no process, just
one
> 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
service
> request can be used to invoke either SOAP or REST service. If further
you
> want me to demonstrate how the same service request can be used to
invoke
> 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
be
> deployed by REST service, why do we need the
serialization/deserialization
> process, which means, WSDL can be deprecated, although many people are
not
> 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
can
> 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