(no subject)

Carine,

here are just some brief comments in a hurry:

1. Glad to see you said that service semantics "can be provided and used
by multiple parties." Then we have two options for semantic
interoperabilities among multiple parties: either we reach an agreement
on the meaning of the service or we guess the meaning each other in
different cases. I prefer the first option-we have to negotiate and
reach an agreement/standard/protocol to share the same semantics - we
know we talk about the same thing in different ways, then why do we need
to guess different things and finally see that we really talk about the
same thing?

2. The primary question/problem for this IG is how to define the service
semantics, not how to use the non-existing semantics by assumption. Show
us a real horse first.

3. I used WSDL provider to differentiate it from a Web-based service
provider that has been confused people all the time.

4. As a programmer, I know how to write code/program to invoke services.
Can you tell me how your legacy applications can invoke different WSs
that do the same thing but have different APIs without ANY
reprogramming?

Have a nice day,

Xuan



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

On Thu, Jul 27, 2006 at 04:25:50PM -0400, Xuan Shi wrote:
> 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? 

I think it is a wrong assumption to say that semantics only refers to 
information given by the service provider or the service requester.
It can be provided and used by multiple parties. 

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

It is not the way it should be done. The primary question is
"what problem do you want to solve that you cannot solve with the
current
technologies", not "what additional info could I express" nor "how could
I use more info". There is a real need for requirements analysis, that
an IG can't do.

> 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

There is no such thing as a "WSDL provider". WSDL descriptions are
completely
optional in WS deployments. I suppose you mean service provider but I
still
think that "provider" is under-defined in this discussion.

The "buy book service" in my example could be a service, a composition
of several services, a service that calls another service (e.g. the book

search). It is used by a client.

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

(I suppose WSDL provider = service in the paragraph above)
Absolutely not. The goal is precisely to have services compositions
or choreographies NOT encapsulated in atomic services and NOT a black
box. 

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

There is no contradiction there. The legacy applications have different
APIs, and offering them as Web services with a WSDL description means 
offering a way to send the right thing and invoke the services without 
having to code a special client.

Received on Thursday, 27 July 2006 21:34:06 UTC