(no subject)

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:07:33 UTC