There is no spoon Neo

So, I think we are close to walking into a big rathole, perhaps the biggest
rathole of all.  To be matrix like (I'm getting quite excited about
reloaded), there is no spoon, ie there is no agent.  Or, you think that's
air you're breathing?  All that a client can see of a service are from the
externally visible aspects that it percieves.  If enough of us see spoons at
the same time, we assume there's a spoon there.  It could be a really good
graphics chip though.
 
This is exactly why the web architecture says precious little about what a
resource is that is identifed by a resource identifier.  All web arch can
really talk about are the bags of bits, which are either identifiers or
representations.  The same limitations hold true for WS.  
 
However, Web services have this problem of needing to talk about equivalence
of endpoints with different bindings.  The web didn't really have this
problem as we rarely create two different URIs, like smtp:foo and http:bar,
that are equivalent endpoints.  
 
Now we want to talk about the ultimatereceiver, so that we can say that
endpoints are equivalent interfaces to the ultimatereceiver, yet we know
that we can't say really anything about the ultimatereceiver as it's not
visible.
 
This problem is exactly why I wanted the WSD group to change some of the
definitions.  I suggested endpoint -> web service and service -> web service
collection.  So a web service is an individual endpoint identified by a URI,
ie a Web service=Resource.  Now we've got this wierd situation where a web
service is this collection of resources, so how do we say what a web service
is without getting abstract?
 
Cheers,
Dave

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Newcomer, Eric
Sent: Wednesday, April 23, 2003 5:13 PM
To: Anne Thomas Manes; Katia Sycara; Christopher B Ferris
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y


Yes, this is very close to the concern.  To clarify a bit more, it's not
just the object model, it's the fact that Web services also can be mapped to
any executable environment.

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Sunday, April 20, 2003 12:40 PM
To: Katia Sycara; Newcomer, Eric; Christopher B Ferris
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y


+1 -- from the client's perspective, the Web service did not change.
 
I think Eric's concern is that the Web services framework doesn't define the
object model of the agent that implements the service. Hence I think we need
to clearly articulate that we intentionally don't define the object model. 
 
This is a major feature of the Web services framework. By not defining the
object model, we ensure that any application, regardless of its object
model, can use the Web services framework. We're talking about clean
separation of interface from implementation. The interface completely hides
the details of the implementation. It is up to the runtime system that
implements the Web services framework to map the interface to the
implementation. ne
 
An

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Katia Sycara
Sent: Sunday, April 20, 2003 11:59 AM
To: Anne Thomas Manes; Newcomer, Eric; Christopher B Ferris
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y


I support the view articulated by Anne. 
The question that is then raised is the following: for the same service
description, one could change the implementation of the "underlying" agent.
If the results of agent execution remain the same under the two agent
implementations, do we say the service did not change?
  I would favor this view.
 --Katia

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Anne Thomas Manes
Sent: Sunday, April 20, 2003 8:31 AM
To: Newcomer, Eric; Christopher B Ferris
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y


But it's still inappropriate to say that the Web service is only the
interface. The interface doesn't perform the service. If you only have an
interface and not an agent, then the service cannot be performed. You must
have both for it to be a working Web service.
 
Anne

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Newcomer, Eric
Sent: Sunday, April 20, 2003 7:50 AM
To: Christopher B Ferris
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y


Yes, the agent performs the service.  But what we are defining in Web
services specifications, and therefore in the Web services architecture, is
not the agent but the *description* of the service.  This is very different
from CORBA for example where the "agent" was defined.

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Saturday, April 19, 2003 8:59 PM
To: Newcomer, Eric
Cc: www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the call
toda y



I agree that there's nothing in the WSDL or SOAP that necessarily says 
what the agent has to be, but nonetheless, it is the agent that performs the

service. 

Cheers, 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624 

"Newcomer, Eric" <Eric.Newcomer@iona.com> wrote on 04/19/2003 03:12:45 PM:

> I still have the problem with defining the agent as the service.  The
service is mapped or 
> transformed onto the agent.  Saying that a Web service is an interface to
an agent, a 
> representation of an agent, or a description of an agent are all ok with
me, but I can't (for 
> example) see anything in SOAP, WSDL, etc. that defines what the agent is
or has to be. 
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Friday, April 18, 2003 8:00 AM
> To: www-ws-arch@w3.org
> Subject: Re: Some proposed definitions of "web service" based on the call
toda y

> 
> I would prefer that we not include references to version numbers in the
definition, as these will 
> change over time. I think that the acronyms should suffice. Secondly, I
thinn that qualifying SOAP by 
> calling out the XML Infoset and processing model suggests that other
aspects of SOAP are either 
> not used, or not allowed, or who knows what. I think that it is sufficient
to say just SOAP. Finally, since 
> we have spent some time discussing the various types of ways in which
people have been using the term, 
> I felt that it is probably worthwhile that we share some of these
alternate uses with the readers of the 
> WSA and give them a little more background. 
> 
> How 'bout this: 
> ------------------------------------------------------------------------- 
> The term "Web service" has been used to refer to a wide variety of things,

> and it is clear that not all people share the same understanding and
definition. 
> For some, it has meant simply the exchange of XML over the Web, typically
using HTTP. 
> For others, it has meant simply the exchange of SOAP messages, typically
using HTTP, 
> or some software component that has been described using WSDL. In a sense,
all of these 
> things might be considered to be "Web services", and the Working Group
does not 
> preclude the use of the term to describe these sorts of things.
Nevertheless, for 
> the purposes of this document, we will define the term Web services as
follows: 
> 
> [Definition: Web service - an executable software agent that is identified
by 
> a URI and whose interface and binding(s) are described using WSDL. Other
software agents 
> interact with a Web service in a manner prescribed by its WSDL
description, using SOAP.] 
> 
>
----------------------------------------------------------------------------
-----------------------------------------------------------------------
> 
> Now, this definition probably deserves some further explanation in order
to say things like  
> "there's nothing 
> to preclude the use of other protocols (than SOAP) to interact with a Web
service... for the 
> purposes of this document, we simply 
> aren't going to go there" and "while the definition requires the use of
WSDL, it does not preclude
> the use of 
> other technologies or XML vocabularies for its description. however, for
the purposes of this document, we 
> aren't going to go there..." 
> 
> Again, it might be nice to solve the equation for all possible solutions
to WS = U + Xd + Xm (a 
> web service is identified 
> by a URI and described using XML and interacted with using XML messages)
IMO this represents a daunting 
> task. We should be focused on defining an architecture that leverages the
technologies being developed 
> in our sibling WGs in the Web Services Activity in its realization. 
> 
> Cheers, 
> 
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624 
> 
> www-ws-arch-request@w3.org wrote on 04/17/2003 05:36:27 PM:
> 
> > 
> > Whew, that was fun :-(  Although it got better when we stumbled on the
> > "instant straw poll in IRC" idea; we should do that more often.  I'd say
> > that in general, anyone who has the "floor" in the speaker queue may
propose
> > one of those by typing the question into IRC; those not on IRC can ask
to
> > have their vote recorded by someone who is.
> > 
> > Let me throw out some proposals that reflect the various opinions I
heard
> > today; without my co-chair hat on, I could live with either of them:
> > 
> >
===========================================================================
> > The term "web service" is used in a wide variety of ways by different
> > people, and we will not presume that the definition used here is
consistent
> > with all of them.  Nevertheless, for the purposes of this document, we
will
> > use the term to mean the following: A Web service is [an interface to ?]
an
> > executable software agent that is designed to be used by another
software
> > agent.  A Web service is
> > identified by a URI, and MUST be [capable of being ?] formally defined
in
> > WSDL 1.2.  A software agent interacts with an  Web service in the manner
> > prescribed by the formal definition, using the XML Infoset and
processing
> > model defined by SOAP 1.2.
> > 
> > [Chris said some things about SOAP being general enough to describe any
> > reasonable "web service" interaction that I didn't capture very well ...
> > maybe he can refresh my memory.]
> > 
> >
==========================================================================
> > 
> > The term "web service" is used in a wide variety of ways by different
> > people, but there is a rough consensus along the following lines: A Web
> > service is an interface to an executable software agent that is designed
to
> > be used by another software agent.  A Web service is identified by a
URI,
> > and has a definition in a language sufficient to describe the interface
to
> > developers of client agents. A software agent interacts with a Web
service
> > in the manner that is consistent with the description, using standard
> > protocols. 
> > 
> > That definition of "web service" is not sufficiently precise or rigorous
for
> > architectural purposes, however.  We will use a more restrictive term to
> > describe the scope of the architecture described here: "Extensible XML
Web
> > Services", abbreviated XWS.   the purposes of this document, we will use
the
> > term to mean the following: An XWS is an interface to an executable
software
> > agent that is designed to be used by another software agent.  An XWS is
> > identified by a URI, and MUST be capable of being formally defined in
WSDL
> > 1.2.  A software agent interacts with an  Web service in the manner
> > prescribed by the formal definition, using the XML Infoset and
processing
> > model defined by SOAP 1.2."
> > 
> > ["XWS" is essentially a placeholder for some term ... I don't care what
it
> > is, but it must specifically describe the "MUST" constraints specified
by
> > the WSA.]
> > 
> >
==========================================================================
> > Of course, improved definitions are solicited.
> >