(no subject)

On Thu, Jul 27, 2006 at 10:50:53AM -0400, Xuan Shi wrote:
> 
> 
> If you read W3C documentation about OWL-S and WSMO, you may find that

There's no such thing at W3C. You must be referring to the submissions.

> different ideas that challenge the faulties in the existing frameworks -
> do you mean this SWS-IG is not for research on service *semantics*? 

It is not, actually. It is about the use of semantics in Web Services.

[...]
> parties in this world. By the new approach, even there is no need for
> WSDL but we can do the exactly same thing in a much easy and simple way
> - WSDL people are unhappy as Dr. Haas told me even WSDL is still under
> development. Also by the new approach, service provider communicates
> with service requester through semantic interface or document, other
> than programming interface (APIs) - then you know how many people are
> unhappy about it (all existing approaches deal with the semantics of
> APIs, other than the semantics of service). In the new approach, there
> is no composite service - service providers have to encapsulate and
> transform all kinds of composite services into atomic one. In this way,
> it enables dynamic invocation as defined by Dr. Burstein, which means,
> if a service requester can indentify multiple services that performs
> exactly the same service (through service discovery, matchmaking and
> composition), the service requester can send exactly the same request to
> ANY of these providers without considering the APIs differentiations on
> the server-side. But unfortunately, you can understand how many people
> are unhappy again to such a new approach, at least for OWL-S, there
> won't be more space for modeling.

What you propose seems to be a definition of "wrappers" that would be
universal descriptions of some "standard" services, and would receive
a unique kind of message and encapsulate all the processing (*).
It has multiple problems: who defines how the request is constructed?
how do you distinguish services (URIs)? how is a service able to provide a
service to a client and at the same time asking a service to another
provider (e.g. a buy book service would have to send a request to a book 
search service before sending a reply to the client)?
How will you tell the client where the services are located?
Currently, WSDL aims at solving many those problems.


(*) There are lots of "Web services" deployed at a unique URI and with
all real services hidden behind that URI in a big black box. Usually,
they are designed to receive anything in an HTTP POST request.
This is just bad practice (violating the WWW Arch and not RESTful services)
and should not be used as an example of a good WS design.

Received on Thursday, 27 July 2006 17:37:14 UTC