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

Roger,
1 - 8 are indeed web services.

You might want to separate the public interface of the web service
(contrat that B exposes to A) and the private implementation of the web
service (how B implements A's service request).

Through that angle, the exchange between A and B is a conversation:
A sends initial request document to B
B can send back N notifications back to A
B can throw an exception back to A
B send result of request back to A

This conversation can be seen as a long lived request and described
through WSDL. Please not that the conversation is atomic and not
re-entrant.

Once the notion of conversation is defined, all the use cases described
can be decomposed into sets of conversations.

The way B composes multiple private conversations in order to fullfil
A's request is called orchestration (aka. Private business process) and
can be modeled using WSFL for example.

In my opinion, one of the key aspects of web services should allow to
make conversation interoperability simple, non-ambigous and
easy-to-manage.

It is also very important to separate the public face of the
conversation and the private implementation....All standards that have
tried to model private implementation over the last 20 years have failed
or become niche!

Edwin

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Friday, February 22, 2002 8:11 AM
To: 'David Orchard'; www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


I'm a little concerned here about the "a" in "a markup result".  I think
it should say something like that it produces one or more responses
directed to one or more recipients.  I think that it might be useful to
say that all participants in the transaction (requestor, responder and
all recipients of
responses) are identified by URI's and that all information flows are
addressed via these URI's.

Could you please tell me whether the following are web services?
(Unless otherwise stated information flows are via XML addressed via
URI's and all participants are identified by URI's).  All scenarios
start with "A sends a request to B".  Then ...

1 - B sends a single response back to A.

2 - B sends an immediate response back to A, then another response two
weeks later.

3 - B sends a request to C, receives a response from C and on the basis
of that information sends a response to A.

4 - B does something but does not send a response to anyone.

5 - B sends responses to A and D.

6 - B sends multiple reponses to D and nothing back to A.

7 - B makes a telephone call to C and on the basis of that information
sends a response to A.

8 - B sends a request to C, C sends a response back to A.

9 - B telephones C, C sends a response to A.

My answer, and I really hope that we will agree on this, is that 1-7 are
web services, 8 is an orchestration composed of two web services and 9
is a work flow outside the scope of web services.

If we are agreed on this, it seems to me that it might be useful to call
#1 a "simple web service", since a lot of the time I think that's what
people are thinking of and there might be some designs, architectures or
techniques that will only apply to that case.  I would be very unhappy,
however, if cases 2-7 were excluded without some really good reason.

-----Original Message-----
From: David Orchard [mailto:david.orchard@bea.com] 
Sent: Thursday, February 21, 2002 5:05 PM
To: www-ws-arch@w3.org
Subject: 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 Friday, 22 February 2002 16:54:28 UTC