(no subject)

Carine,

Thanks for your correction. Yes, I refer to those submissions.

If this IG "is about the use of semantics in Web Services", then how do
you think McCool's conclusion (and I believe) that there is no service
semantics yet? Do you mean that you also just care about
service-requesters activity and ignore service-providers role in SWS? Or
do you mean service semantics can be defined by the requesters, other
than the providers? 

As for those multiple problems you mentioned, I think it's a good
starting point to discuss the *semantics* of a service before you can
use it (I just wonder again how can you use the semantics that are not
in existence).

As for your question and example, "a buy book service would have to send
a request to a book search service before sending a reply to the
client", could you please tell me if this "buy book service" is a WSDL
provider or it request other WSDLs? Since "There are many things that
might be called "Web services" in the world at large" as W3C said, you
have to clarify yourself also.

If it requests other WSDLs, then you are talking about a requester for
service integration, then that's not the business for the real WSDL
providers at the backside.

If this "buy book service" is a WSDL provider but also it requests other
WSDLs to accomplish the tasks, my suggestion is that you encapsulate all
composite services into an atomic one before you release your WSDL
interface to the requester (I think I already posted a message in this
list about how to do it and it seems you understand it). You are
providing a service, not a road map to your requester and say, hey, here
is my subconctractors and you can contact them in this order to get your
result. So, when your requester sends you a request to buy a book, you
have to send the request to the other WSDL providers to search the book
, wait for the reply, get and result, and send it back to your
requester. How you process the request is all hidden/encapsulated in the
black box as your requester is waiting for the result. Aren't you
providing a consulting service to your requesters and telling them where
and how to buy books?

As for WSDL, it is just a document about service APIs with little
semantics (otherwise why do we need extra description about the service
semantics). Let's again examine Dr. Burstein's discussion about dynamic
invocation of Web services, one of the final goal for SWS. In his
article "Dynamic Invocation of Semantic Web Services that Use Unfamiliar
Ontologies" published by IEEE Intelligent Systems. July/August, 2004. he
said the dynamic invocation of Web services is characterized as "without
any reprogramming, a software system could have the flexibility to use
various services that do the same kind of job but have different APIs". 

First let's focus on this section: -- various services that do the same
kind of job but have different APIs -- this means, various services can
have exactly the same service semantics (do the same kind of job) but
have different APIs - WSDL documents.

If we focus on the service semantics, for example, hotel reservation
service, buy book service, etc. we all know the details of such kind of
services that can be limited within a certain semantic scope. What we
don't know, however, is just WSDL APIs, as people can do the same thing
in different ways.

Supposed we eventually get service composition result, and know that,
the output of all kinds of service As can be used in all kinds of
service Bs, then we get the deadlock in SWS - dynamic service invocation
- without ANY reprogramming, how can you invoke service As and Bs that
all have different APIs (in case any of them may not functions
correctly, you may have to try other services to get the result) e.g.
two different objects GeocodeInfo vs. LocationInfo as the outcome of two
different services that performs the same function as I mentioned
before?

Since various services can have exactly the same service semantics, then
to enable dynamic invocation, my proposed approach as you know, is just
to standardize APIs. Once there is no differentiation in APIs, we can
communicate easily without any obstacles and then we can focus on
specifications for service semantics, not service interfaces. All
communication is based on semantic interface, not programming interface
- just a channel for exchanging request and response. At this moment, we
do not have any horse to ride/use. 

One last thing I have to mention is, Internet computing is based on
protocols. It's the same for SWS. I found such definition on
dictionary.com that protocol is - :

A set of formal rules describing how to transmit data,
especially across a network. Low level protocols define the
electrical and physical standards to be observed, bit- and
byte-ordering and the transmission and error detection and
correction of the bit stream. High level protocols deal with
the data formatting, including the syntax of messages, the
terminal to computer dialogue, character sets, sequencing of
messages etc.

As for SWS, we need more rules, standards, agreements, formats, to
define and share service semantics to handle semantic interoperability
issues, after we have a standardized API. 

Regards,

Xuan


>>> Carine Bournez <carine@w3.org> 07/27/06 1:35 PM >>>

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 20:27:47 UTC