Re: Some proposed definitions of "web service" based on the call toda y

Walden,

I see no reason to call out SOAP RPC explicitly. I think it is implied.

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/18/2003 09:24:07 AM:

> Christopher,
> 
> Would you want to include SOAP-based RPC in that first paragraph,
> or is it better to leave it out?  Or is it implied by the broader 
"exchange
> of SOAP messages"?
> 
> Walden
> ----- Original Message ----- 
> From: Christopher B Ferris 
> To: www-ws-arch@w3.org 
> Sent: Friday, April 18, 2003 8:00 AM
> 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.
> >