RE: Web Service Definition [Was "Some Thoughts ..."]

Now you're cooking!  However, I think that the coupling to the web should a
little explicit.  How about:

"A web component is a component accessed over HTTP or other messaging
protocol, identified by a URI, and producing a markup result"

"A web service is a web component that:

 is invoked using an XML message such as a SOAP message, via a
 well-defined message exchange pattern;

 and is defined by a description of the data required
 to invoke the service, such as a WSDL document;
"

So we refine the web component into a web service by mentioning SOAP and
WSDL.  I took some of your web service text and refactored it into the web
component definition

I'm not too keen on the addition of "usefully processed by conventional
software without human intervention." because I can't figure out how to
define "conventional software" nor "usefully" processed".  I got rid of the
term "unambiguous".

This does beg the question of how to differentiate web services from xhtml,
xslt, SVG - certainly HTTP is a well-defined MEP ;-)

It seems to me that if you don't use SOAP AND you don't use WSDL, you
probably don't have a web service.  One criteria that I tend to like is that
a Web service must have at least one of SOAP or WSDL.  If somebody creates a
non-soap XML document and ships it over HTTP to a URI that doesn't have a
WSDL, that's just a web document/component.

Question: Is anything describable by WSDL, like an XHTML page described by
WSDL, a web service?  I tend to think not, but it does fit in the WSDL
definition.  An xhtml document could go from a web page to a web service by
simply being described in WSDL if this is the case - note the runtime
messages didn't change at all.

I thought about trying to differentiate soap/xml-rpc etc. from
xhtml/xslt/svg, by saying that soap/xml-rpc are frameworks that "verticals"
define.  W3C defines xhtml/xslt/svg, whereas the contents of soap messages
are defined outside the W3C.  That is there is a separate namespace name
that is required for the message to be meaningful.  But this fails with the
SOAP because a complete message could use just SOAP encodings.  So the
closest I could get on the "vocabulary" axis is that the XML exchanged is
defined by SOAP or defined by a non-w3c xml vocabulary.  This would exclude
xhtml, svg, xslt and allow xml-rpc, ebXML, others.  A bit tortuous, and I'm
sure there are some xml vocabularies that people wouldn't think are web
services.

Maybe we should come up with a spreadsheet listing different xml
vocabs/definitions and see if people think they are in scope of web services
or not, like:
xhtml, nowsdl: web
xhtml, wsdl: web or web service?
soap: web service
myvocab, smtp, nowsdl: web or web service?
myvocab, http, nowsdl: web or web service?
myvocab, wsdl: web service.

Then we do the karnaugh map for our web service definition.

Cheers,
Dave



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Thursday, February 21, 2002 2:09 PM
> To: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
>
>
>
> Starting with the strawman proposal, and then applying some
> comments that
> came up in email and the teleconference.
>
> > "A web service is is  a software application or component
> that can be
> > accessed over the Internet using  a
> vendor/platform/language-neutral data
> > interchange format to invoke the service  and supply the
> > response, using a rigorously defined message exchange pattern,  and
> producing a
> > result that is sufficiently well-defined to be processed by
> a  software
> > application."
>
> Comments (sorry, I'm in brain dump mode and won't cross-reference the
> archives):
>
> First, how do we distinguish Web services from "the web" itself?  A
> sufficiently generic definition would imply that an
> arbirtrary web page is a
> "web service" that supplies an HTML document.  That is too broad to be
> useful, IMHO.  I just noticed that Microsoft has a "Global
> XML Web Services
> Architecture" that they refer to.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/dngxa/html/
> gloxmlws500.asp
> I'm not sure that this is meant as a definition, but this
> says "XML Web
> services are built on XML, ... (SOAP),... (WSDL), and ...(UDDI)
> specifications."  We should probably discuss each point
> individually.  I'm
> willing to say that we are talking about *XML* web services
> in which the
> service is identified by some combination of URIs and XML,
> and the result is
> an XML instance.  On the other hand, I'm reluctant to say
> that "web services
> *require* SOAP, WSDL, or UDDI, although each obviously is an
> *example* of
> role that might be critical to our definition.
>
> Is SOAP critical to the definition of a Web Service?  There
> are two very
> distinct positions on this question, as far as I know.  One
> is the SOAP-RPC
> approach, which says that a URI identifies a fairly generic "endpoint"
> (sortof like a function library) and the contents of the SOAP envelope
> identify the specific function to be invoked and the parameters to be
> passed. The other is the REST approach, which says that the
> web service is a
> "resource" as understood in the Web Architecture and the URI should
> completely identify the service, the function, and the
> parameters. SOAP
> might be useful in a REST-ful web service (especially since
> it is defined on
> the InfoSet and not XML syntax, so could be encoded in URI
> syntax ... and
> could obviously be used to package up the result, but it is
> not critical to
> the *identification* of a REST web service.  Do we want to
> take sides in
> this? I hope not ... we'll lose the W3C Director if we insist
> on one, and
> half the vendors if we insist on the other! <grin>  So, I'd
> say that a web
> service is "unambiguously identified using Web technologies,
> including a URI
> and optionally an XML description such as a SOAP message".
>
> Next, WSDL is integral to IBM's definition, and an official
> W3C WG now, so
> some imply we should explicitly reference it.  This is a show-stopper
> politically, in my humble opinion.  The scripting people,
> most notably Dave
> Winer [a co-author of the original SOAP spec] are adamant
> that an informal
> document describing how to access a web service is
> sufficient.  I'd amend
> the strawman to say that a web service must have a "clear
> description of the
> data required to invoke the service, such as a WSDL document."
>
> Someone mentioned that a machine-processable result (as
> opposed to a human
> or an artificial intelligence) is integral to the definition.
>  The strawman
> says "producing a result that is sufficiently well-defined to
> be processed
> by a  software application."  How about saying that a web
> service must, by
> definition, "produce a result that can be processed by  conventional
> software without human intervention."
>
> We talked about "orchestration" on the call.  I got
> distracted for a couple
> of minutes, but it appeared that we think this is not integral to the
> definition of a web service, although potentially a topic that the
> architecture should cover.
>
> So, here's the "son of strawman" definition (stickman?):
>
> "A web service is is  a software application or component that:
>
> Is accessed over the Web (broadly defined) using  HTTP or
> another standard
> messaging protocol;
>
> Is identified and invoked using using Web technologies,
> including a URI and
> optionally an XML description such as a SOAP messagem, via a
> well-defined
> message exchange pattern;
>
> Is defined by an unambiguous description of the data required
> to invoke the
> service, such as a WSDL document;
>
> and Produces an XML result that can be usefully processed by
> conventional
> software without human intervention."
>
>
>
>
>
>
>

Received on Thursday, 21 February 2002 18:05:59 UTC