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

To me it seems like we are mixing different views of a "service" in our
quest to define a web service.  I think that generally you could attempt to
define these services based on technology and functionality (kind-of).  So
according to this, when we try to define a web service based on transports
and description standards (a service that is described in WSDL and can
exchange input/output messages) over SOAP, we are classifying a service
based on technology.  However, when we try to declare a service, web service
or not, based on whether it provides discrete services or orchestrations, we
are trying to classify a service based on its functionality (kind-of).

So my question to the group is which of the two dimensions or views
(technology/functionality) are the correct one to consider in defining a web
service.  If I had to make a guess here, I would say the technology view is
more important for us to consider in defining a web service because the jury
is still out on the functional view.

Thanks,



___________________________________________
Waqar Sadiq

EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, TX 75024

phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
___________________________________________


-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com] 
Sent: Friday, February 22, 2002 10: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:33:11 UTC