RE: Semantics of WSDL vs. semantics of service

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

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>

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.

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.

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

-----Original Message-----
From: Carine Bournez
To: Battle, Steven
Cc: public-sws-ig@w3.org
Sent: 3/15/06 5:50 PM
Subject: Re: Semantics of WSDL vs. semantics of service


On Wed, Mar 15, 2006 at 05:08:50PM -0000, Battle, Steven wrote:
> > Clarification about semantic annotation for wsdl:
> > The *meaning* is actually in a separate document (or several 
> > ones). The annotation in the WSDL is supposed to *point* to 
> > *external information*.
> >
> 
> Has this been decided already? The charter says, "The Semantic
> Annotations for WSDL Working Group is chartered to define one or more
> properties of WSDL 2.0 components to point to additional semantics to
> concepts represented by those components, e.g. interface, operation,
> endpoint."

The charter also says "Additionally, the Working Group may define 
annotations to the schema structure to point to external semantics."
The examples given by Xuan Shi fall in the typing category and my 
first thought is to use annotations on the schema structure of the
WS description. I have not worked (and will not) on his particular
cases though.

> Nothing in the charter restricts this additional semantics being
> embedded in the WSDL document itself. Indeed if it is, the likelihood
is
> that tools will simply ignore the additional semantic components.

These issues will certainly be discussed in the group, keep your
scenarios for the future debates :)