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

Well, are you SURE that number 8 is "a" web service, not an orchestration of
two web services?  It seems to me that if you allow 8 as a web service you
are sliding down the slippery slope of including all orchestrations or
choreographies -- and as I understood it that is not considered desirable.

I have another (hopefully) clarifying set of questions:

Is IRC a web service?  Is Yahoo Messenger?  If not, why not?  Could they be
made web services by incremental changes in how they work or what they do?
If these, or some derivatives, are indeed web services do the definitions of
web services we are considering need to be expanded or generalized to
include them?

I do not have suggested answers to these questions -- I honestly don't know
and I'd like to find out.

Opinions:  

1 - I would like to see web services defined pretty broadly so, for example,
one can build useful orchestrations out of web services components.  If web
service is defined so narrowly that all you can make is RPC's I think that
people will curse us.

2 - If web services are defined pretty broadly I think it might be useful to
define subclasses like "simple web service".

3 - I strongly favor functional definition of web service within a broad
technical framework.  That is, I like saying that web services have to use
URI's and XML, I don't like saying they have to use WSDL and/or UDDI.

4 - I think that if we have a definition of web services that works we
should be able to make a list of things that are and are not web services
and in the latter case identify specifically what part of the definition is
violated.  I think that we should, in fact, make such a list and that if we
do it well people will bless us.

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com] 
Sent: Friday, February 22, 2002 3:54 PM
To: 'Cutler, Roger (RogerCutler)'; 'David Orchard'; www-ws-arch@w3.org
Subject: 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 Saturday, 23 February 2002 13:31:44 UTC