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 16:26:57 UTC