RE: What DO we agree on? (was RE: The stack diagram (was RE: Discuss ion topic for tomorrow's call)

I think that while what you say mey be true, we do need to focus our 
attention
on the aspects that relate to the technology we are talking about. Yes, 
you could
convey a description of a Web service over the phone, but is that 
necessarily what
we are striving to achieve? I would hope that we would in fact want to 
have the
description machine processable, that's what makes it more broadly useful 
IMO.

I for one DO think that we want to have an architecture that requires that 
the description
be in XML... at the very least, XML Infoset... its on-the-wire 
representation might not
necessarily be required to be pointy brackets (XML1.0 second edition 
serialization).

My $0,02,

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/16/2003 01:16:28 PM:

> 
> I am a little nervous about Number 3, but maybe it's a matter of
> interpretation.  You will recall that some of David Booth's scenarios
> have the description of the WS interface being transferred via
> "semantics", which can include things like telephone calls,
> collaborative development, email and so on.  I think it is important
> that the interface be well defined and stable, but I do not think that
> it is necessary for it actually to have an XML description that can be
> late bound.  I am willing to yell awfully hard to preserve early bound
> scenarios, since they are very common in business applications.
> 
> Actually, I doubt that this was your intention, but I want to be careful
> about this.
> 
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
> Sent: Wednesday, April 16, 2003 8:20 AM
> To: www-ws-arch@w3.org
> Subject: What DO we agree on? (was RE: The stack diagram (was RE:
> Discuss ion topic for tomorrow's call)
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Wednesday, April 16, 2003 1:27 AM
> > To: 'Mario Jeckle'; www-ws-arch@w3.org
> > Cc: 'George Blanck'; Savas.Parastatidis@newcastle.ac.uk;
> > Eric.Newcomer@iona.com
> > Subject: RE: The stack diagram (was RE: Discussion topic for
> > tomorrow's
> > call
> > 
> 
> [not speaking with co-chair hat on!!!!]
> 
> > We do not have agreement on what is REQUIRED for something to be
> > a Web service.
> > What are the constraints?  All we have so far is that it's 
> > gotta have a URI. If it's not SOAP, not WSDL, not even XML, then there
> really 
> > isn't much else there there.  Great, a URI.  But what next?  Our
> architecture 
> > won't provide anything that is of use to developers, as the URI isn't
> > nearly sufficient to do something with. 
> 
> Dave raises the awfully good point that these definitions have to
> actually provide use to someone if this effort is to be worthwhile.  On
> the other hand, I think there's more agreement than meets the eye, at
> least more than just "it's gotta have a URI."
> 
> I'll guess that there is rough agreement on the following constraints on
> what WE mean by "Web service": [The stuff in brackets is commentary /
> clarification, not proposed text for a definition.]  Please YELL if you
> can't live with any of these points, and please suggest wording
> improvements to clarify them.
> 
> 1. A Web service is designed and deployed to provide information to or
> perform some action on behalf of some software agent. [As opposed to a
> human agent; it's got to be invokeable / understandable by conventional
> software without necessarily involving AI or Semantic Web techniques.
> Also, I've been thinking that something like "designed and deployed" is
> needed to distinguish a "Web service" from "screen scraping information
> meant for humans"]
> 
> 2. A Web service is a resource and has identity, thus can be uniquely
> identified by a URI. [This is the minimal sense in which a service is a
> "Web" service, IHMO. ]
> 
> 3. A Web service MUST have its interface defined in a sufficiently
> explicit and rigorous manner such that it can be invoked by a software
> agent without human intervention.  [I'm not happy with the wording here,
> but I want to accept the basic "IBM" position that some sort of "web
> services description language" is necessary for something to be a Web
> service, but don't want to restrict that language to WSDL .... it could
> be a BNF description of a legal URL + the DTD/schema of the returned
> data, or some RDF-based language/ontology, or perhaps even a SOAP
> message template.  I think we need to work the hardest to find a
> consensus in this area.]
> 
> 4. Software agents communicate with Web services using a standard
> protocol that directly or indirectly uses URIs to identify the
> commuicating parties. [ I'm not happy with this wording, but most
> definitions of "Web service" say something about standard protocols ...
> but there are also clear use cases where proprietary protocols are
> involved. I *think* this definition would cover all uses of HTTP/FTP as
> well as SOAP on top of proprietary protocols or -- the SOAP layer
> understands the URI, and the protocol binding maps that into whatever
> the underlying protocol understands].
> 
> 5. The Web Services Architecture constrains itself to those Web services
> description languages and invocation protocols that employ XML.  [I
> would like us to somehow say that *we* are focusing only on "XML Web
> services" but don't wish to make the point that if it ain't got XML, it
> ain't a Web service. Perhaps in deference to the RESTifarians and
> Roger's example of a software agent retrieving a JPEG image identified
> by a URI, we could tweak this to "protocols that employ URIs and XML".]
> 
> ========================================================================
> 
> For reference, here are a couple of existing definitions
> 
> Classic: "A Web service is a software system identified by a URI, whose
> public interfaces and bindings are defined and described using XML. Its
> definition can be discovered by other software systems. These systems
> may then interact with the Web service in a manner prescribed by its
> definition, using XML based messages conveyed by internet protocols."
> 
> This fits the constraints mentioned here ... but doesn't mention my
> constraint #1 that a Web service is designed to be used by a software
> agent, and I think it's a bit fuzzy on the "formal description language"
> constraint.
> 
> Eric's: "A Web service is an XML interface to an executable software
> agent that is accessible using Web technologies.  A Web service has a
> description, identified and published using a URI.  The agent has a
> network address, also identified and published using a URI.  A Web
> service description defines the set of one or more XML messages that can
> be sent to and/or received from a
> Web service.   A Web service description may be discovered using a
> registry,
> directory, or other mechanism that associates human readable keywords
> with descriptions."
> 
> This seems a bit more stringent than my proposed constraints ... it
> doesn't mention that a Web service can simply retrieve information as
> well as invoking an executable software agent, and seems to require XML
> a bit more explicitly than some might be comfortable with.
> 
> ======================================================================
> 
> I'll make a concrete proposal, taking bits from both definitions and
> making sure to cover all the constraints identified above:
> 
> "A Web service is a standardized interface to an information system or
> executable software agent that is designed and deployed to be used by a
> software agent without human intervention.  A Web service is identified
> by a URI, and has a formal definition in a language that employs URI and
> XML. Its definition can be discovered by other software systems.
> Software agents interact with a Web service in the manner prescribed by
> the formal definition, using XML based messages conveyed by standard
> protocols that directly or indirectly use URIs to deliver messages
> between the agents."
> 
> Thoughts?
> 
> 
> 
> 
>