(no subject)

Charlie,

Sometimes I criticized that W3C limits the concept of Web service with a
single stress on SOAP/WSDL based service, excluding the REST ones. But
to answer your questions, I think I have to use W3C's definition: here a
service provider provides a WSDL interface, a requester consumes the
service through this interface, not generate a new interface. 

So in your scenario of person B, this developer, a *service* provider as
you called, is NOT a WSDL service (interface) provider, because it
allows the user to "make hotel reservations and also choose to reserve a
city tour over the web" - here the key term is "over the Web", but in
Web service terminology, we are talking about communication through WSDL
interface (not Web interface) between a service provider and service
requester. If anyone consumes a "Web"-based service through Web
interface, this "service provider" is not the same as defined by the
W3C, but rather, it's a WSDL service requester, not WSDL service
provider.

And that's why I asked Terry yesterday to clarify the meaning of
"service" provider in his case - whether it's a WSDL Web service
provider, or a just Web-based service provider, the latter is obviously
not within the discussion for this group. 

We may wish to find the SWS tutorial @:
http://www.wsmo.org/TR/d17/resources/200507-ICWS/SWStutorial-iswc05.ppt
then you can see your scenario of person B is just the VTA in this
tutorial (slide #63), a service requester (not provider) who integrates
the other two REAL WSDL WSs for its end user (via the Web, maybe). 

This tutorial has little about the *semantics*, or the meaning, of these
two real WSs, FlightBooking, and HotelBooking, exactly the same as your
use case, but all about service integation, aggregation, mediation, etc.
Do you see the problems for them and this SWS-IG? Nobody care about the
horse but has been eager at the saddles.

As for what you mentioned that service semantics refer to some
definition that "are machine readable", that's another old debate but
obviously you can tell whether XML, WSDL, or even a text file, is
"machine readable" or not. Actually, the key is not "machine readable"
as machine can read all of them based on your design. Their focus is
again, logic modeling, not really *semantics*, if you check the previous
posts.

Also, I may agree with you that probably "aggregation/mediation are
important when it comes to automating the discovery, composition and
execution of services", but you added a prerequisite yourself as that
"when" they are used by the requesters, not the service providers,
right? But we need a horse first.

By the way, many people keep telling me that they are talking about
*agent*, tools, or whatever, other than people. It is strange for such
correction many times as when I talk about service provider, service
requester, they are ALL *agents* within W3C Web service definition. On
the other hand, you and others may talk about people other than *agent*
yourself as your Web-based service requesters are probably people, not
the agent. There are too many semantic confusions in this IG, just as
what W3C said in 2004 @
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/:

--- "There are many things that might be called "Web services" in the
world at large." - by W3C

When people are talking about *service provider*, we have to examine
what they are talking about really by W3C definition (WSDL interface
based Web service or Web interface based service) . At this moment, I do
appreciate the value of such a limited definition of Web services,
otherwise, we just engage in a headless and endless confusion.

Regards,

Xuan



>>> Charlie Abela <charl_abela@yahoo.co.uk> 07/27/06 1:09 PM >>>
Please see my comments inline below.

----- Original Message ----
From: Xuan Shi <Xuan.Shi@mail.wvu.edu>
To: public-sws-ig@w3.org; charl_abela@yahoo.co.uk
Sent: Thursday, 27 July, 2006 4:50:53 PM
Subject: Re:

 How about you can tell me and the others the role of service
provider in this case? 

Answer: in the scenario I depicted, person A is the pure requester, but
person B starts as being a requester (i.e. wants to discover some
service) and then uses this for his own needs (i.e. creates a new
service description which includes both the hotel and the city-tour
services) after which he advertises this new service with a service
registry, thus he now becomes a service provider.

More specifically, please tell us:

Why WS developer for Hilton (hotel) can handle WS development of
American Airline? and why Hilton needs a composite service process.owl
for American Airline, and vice versa?

Answer: Looking at the scenario again: person B who is a developer, was
commissioned to create a service for Fast_Travelling_Agency which
required a way in which web agents (roaming for travelling services)
could make hotel reservations and also choose to reserve a city tour
over the web, i.e. without the clients coming over to the
Fast_Travelling_Agency offices (it could also be the case that this
agency does not actually have any offices where clients could go over
and discuss travelling plans).

With an emphasis on service requester, we lose the focus on defining the
*semantics* of Web services. As McCool said in his paper published by
IEEE Internet Computing in the last issue of 2005 that until now, there
is no real service and there is no service semantics. Or you want to
tell me what's the *semantics* of a hotel reservation service in this
SEMANTIC Web services interest group?

Answer: I might not be understanding you completely here, as I said I am
not an expert in the field, but am working on discovering and using new
technologies to possibly make things easier for a software agent to
identify some web functionality. Sorry I did not read that paper, but I
think that when we say service semantics (someone can correct me if I'm
wrong), we refer to some definition, in some language such as OWL-S or
WSMO, which are machine readable. If we consider the hotel_reservation
service, the inputs and outputs together with URI's to concepts in some
ontology may help the agent to reason about the type of inputs that this
service requires and thus whether the agent could supply them or not. In
this manner the agent may or may not present this service to person A or
B. For example if, for the sake of this argument, the person A does not
have a visa-card which is one information that the hotel_reservation
requires, then it is useless for  A's agent to present
 this service to him. 

If you read W3C documentation about OWL-S and WSMO, you may find that
only 1/4 of them is about service (provider) while the other 3/4 is
about service integration/aggregation/mediation. That's why I said it's
a mixture with a focus or stress on requester-side activities. But I am
interested in the *semantics* of service more than requester-side
modeling. So why I cannot indulge in this group because I have some
different ideas that challenge the faulties in the existing frameworks -
do you mean this SWS-IG is not for research on service *semantics*? 

Answer:Well, as I depicted the role of person B, he is both a requester
and a provider (or else works for a provider: Fast_Travelling_Agency).
And as I see it, a service provider, or the developer who is creating
the service on his behalf is more interested in defining how his service
will function. Now if the Fast_travelling_Agency, does not want to make
the service machine readable (as in semantically enabled) then WSDL
would suffice, but if the target of this agancy is to make it available
for agents then it commissions person B to enrich the service with OWL-S
or WSMO or the like.
I still don't understand which ideas you are making reference to. Can u
perhaps use the scenario or else create one and make your ideas clearer?

Such existing frameworks look like that these people are developing
saddles (handling service semantics) before they have a horse (service
semantics). That's why I keep asking them questions and debating with
them for a long time, especially, why service provider can imagine and
handle service requesters' activities? For service providers, they just
have the following roles:

1. develop service
2. define service and share the service semantics
3. wait for service request
4. response for service request

Answer: I would say that develop and define are step 1. In which case
the developer (who could or could not be the provider) has the option to
create from scratch a service or to reuse one after submitting a request
to some service registry.
Step 2 is advertise and share semantics.
I agree with 3 and 4.

Where is the place for integration/aggregation/mediation to the service
provider, i.e. varied modelings in OWL-S/WSMO? 

Answer: I think (again pls, someone correct me if I'm wrong) that
aggregation/mediation are important when it comes to automating the
discovery, composition and execution of services.

You and many others said that SWS are "all about associating the work
related with the Semantic Web to that of Web Services", I just wonder
when SW people develop the framework (RDF/OWL) to define the *semantics*
of the *concepts*, is there anything in this framework that describes
how to handle the processing of such *concept*? Can you and anyone tell
me how RDF/OWL defines a model to process the
integration/aggregation/mediation issues for people (requesters) who
process the concepts defined on the semantic Web?

I don't think that the requesters in this case are people but as I said
earlier, these are mainly tools for agents. 

If RDF/OWL in SW is just a framework to *_define_* the semantics of the
concepts, why SWS framework like OWL-S/WSMO includes client-side
integration/aggregation/mediation modelings that are NOT for service
providers? As I asked Terry yesterday, if they are not based on
assumption, then where is the design from?

As for myself, I already proposed a new approach and framework for SWS
and it first emphasizes on the *semantics* of the service, 

what is your idea of the service semantics?

NOT about
client-side service integration - as a service provider, this is NOT my
business. As a service provider, I need to consider HOW to enable my
requesters to understand the service - this should be the focus of SWS
research as I think, and this has been the reason why I keep debating
with people in this group: the focus of SWS research - service semantics
(provider-side) vs. modeling integration process (requester-side). 

can you clarify your idea of provider and requester?

And obviously, we should have a horse first before we build saddles. It
is
such a simple lesson but I just wonder why people just ignore it.

Unfortunately, my proposed approach is not good to too many people and
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.

Answer: I cannot actually understand this argument, again can you supply
a practical example of how your approach can make away with the
complexity (cause defining services with OWL-S and WSMO is rather
complex unless suitable tools are used) of the proposals submitted to
W3C?



Regards

Charlie

Received on Thursday, 27 July 2006 18:27:52 UTC