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

Mike, David,

It seems that the goal of web services is to allow one application to
easily integrate functionality exposed by another application. Therefore
I think that having a strong logical contract between those 2
applications seems to be important and something that should not be
ambiguous and there should not be 2 ways to express that contracts
semantic.

It seems that WSDL is the candidate for describing that contrat and that
unless necessary it should be the only mechanism.

The nice thing about WSDL is that it separates the logical contract
(portType) and the physical contract (binding). All the various flavors
of web services should be done at the binding level rather that the
logical.

One of the advantages of this approach is that the developer that
consumes a web services only works against the logical binding and
solution providers can hide the plumbing.

Regarding the definition of what the architecture address, I think that
it would be valuable to define a set of key values ("the bank")
associated with this architecture. These key values will help prioritize
and compromise.

Key Value Candidates:
1) Simplify Integration
2) Promote Interoperability
3) Remove Ambiguity

It would also be very useful to have a set of real world use cases of
applications that would best be build on top of a service-oriented
architecture.

Finally, I personaly think that one of the key strenght of the web is
that it focused on defining on-the-wire interoperability rather than
focusing on how HTTP, HTML were reflected into an application model
(ie...JSP and servlets came much later. At first, you really did not
care how a request was actually handled). It this an important lesson
for web services or should we have to care about how J2EE and .NET will
implement web services architecture (and get in the level of reference
sharing, distributed garbage collection, etc...)?

Thank you,

Edwin

Edwin

-----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 5:22 PM
To: www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]




> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Thursday, February 21, 2002 6:05 PM
> To: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
I'm happy with the changes, generally ...

> 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 don't disagree.  It would seem that we somehow have to address the
issue that almost all informal definitions of a web service talk about
how "the web as we know it today" requires a human reader or
form-filler-outer to do anything useful, and "web services" will allow
this to be automated.  Can we do anything with that idea without getting
into philosophical black holes? I don't like "conventional software"
either ... it was a crude attempt to say "a program that does not have
the capabilities associated with an
Artificial Intelligence or require the facilities of the Semantic Web."


 
> 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.

Well, I think the REST people disagree.  Paul Prescod's recent XML.com
articles explain that point of view quite well. The SOAP message to
retrieve a stock quote is everyone's favorite (or least favorite!)
example of a web service.  If that was triggered with a URI that could
be generated according to instructions in a simple text document,  e.g
 
http://qs.money.cnn.com/apps/stockquote?symbols=ibm&submit3.x=8&submit3.
y=9
and the result came back in XML, or in some well-documented HTML format
that a program could process, wouldn't be a "web service"?  Likewise,
isn't a site that documents how you can use XML-RPC to get some specific
information back a "web service." 

SOAP and WSDL can certainly add value, e.g. if you wanted to define how
to get a series of quotes for a number of stocks during some historical
period, it would be a LOT more programmer-friendly to describe the
interface in WSDL and generate the SOAP request automatically.  But the
selling point should be that "SOAP/WSDL make it easier for non-web geeks
to build and access web services" not "if it ain't got SOAP or WSDL, it
ain't a web service".  

Thinking about this a bit, I think the key differentiator for a "web
service" is the notion that it adheres to a well-specified "contract" to
deliver specific machine-processable information in response to a
specific invocation.  Obviously WSDL is one way of specifying the
contract, and SOAP is a flexible way of making the invocation and
getting the result.  But if the invocation is specified via a documented
URI syntax, and the result is informally documented XML (e.g., RSS
0.91), then it's a "web service" too. Google is a "web service" in my
book, or could be when they have some way of returning the results in
XML, or a well-documented XHTML format whose essentials won't change
every time the marketing people hear from a focus group that it should
look spiffier. 
 
> 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.

Hmm, I like the idea.  It would definitely be worth seeing if we could
come up with acceptable, unambiguous definitions!  I suspect that we'll
have to accept some fuzziness, "degrees of webness" and "degree of
service-ness". For example, I'd say:

html forms + undefined html result = 100 %web, 0% service
well-documented URI + well-documented html result = 100% web,  75%
service well-documented URI + informally specified SOAP result = 50%
web, 90% service SOAP + WSDL  = 0% web, 100% service

I guess a hypothetical web page that accepted a URI-encoded SOAP message
rigorously defined by WSDL and returned a SOAP result that used a
stylesheet to render it in a human-friendly format could be 100% web,
100% service.

Received on Friday, 22 February 2002 16:10:07 UTC