- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Sun, 21 Jul 2002 14:59:11 -0400
- To: www-ws-arch@w3.org
+1
Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
"David W. Levine"
<dwl@watson.ibm.c To: "Newcomer, Eric" <Eric.Newcomer@iona.com>, "Jeff Mischkinsky"
om> <jeff.mischkinsky@oracle.com>, "Champion, Mike"
Sent by: <Mike.Champion@softwareag-usa.com>, <www-ws-arch@w3.org>
www-ws-arch-reque cc:
st@w3.org Subject: RE: REST, Conversations and Reliability
07/21/2002 11:33
AM
At 10:23 AM 7/21/2002 -0400, Newcomer, Eric wrote:
>Hi,
>
>At the risk of flooding everyone's inboxes yet again on this topic, I want
>to say that this is one of the best summaries of the problem I've seen,
>and I agree with the suggestions within it on how best to proceed.
>
>I have often heard it said that Web services are "CORBA for the Web." As
>a representative of the "CORBA company" this is a tempting concept to
>fully endorse. I also expect that someone from a "REST company" (if there
>is such a thing) is tempted to fully endorse the concept that Web services
>are best implemented using existing Web technologies. The truth, as I've
>been saying for a while now, seems clearly in the middle.
>
>For example, CORBA over the Web doesn't work because IIOP doesn't exist
>over the Internet. There are reasons for this, having to do with the REST
>concepts that drove the success of HTTP. Fundamentally, CORBA concepts
>have to be re-designed to work with HTTP. At least that's one way of
>looking at things, from the CORBA perspective. The Web doesn't have IIOP,
>it does have HTTP, so OMA has to be adapted and changed to reflect this
>reality.
>
>Similarly, REST doesn't include many of the concepts and services defined
>within OMA, and SOAP and WSDL already exist. REST has to be adapted and
>changed to reflect this reality.
>
>Using a GET to obtain a WSDL file on which to base a SOAP message sent via
>POST is a convention that many Web services toolkits successfully use. It
>doesn't matter whether or not this violates REST, except to the extent
>that it becomes a practical matter.
>
>Many of the REST folks correctly point out that Web services as defined
>won't scale as well as current Web hypertext usage. However, this avoids
>the very real question of whether they have to. Web services are based on
>a different usage model, and it might very well be the case that private
>agreement among Web services publishers and consumers is sufficient -- Web
>services may not have to scale to the entire Web to be successful, as Web
>page publication does.
>
>These are the things we need to figure out to create a successful Web
>services architecture, which in my mind also is one of the most important
>next steps in Web services evolution.
>
>As a last point, I'd say that Web services are still evolving. The market
>is in a bit of a backlash against them at the moment, since they were
>over-hyped. And it's therefore not entirely clear where Web services are
>going, or how they will evolve. The "killer app" has yet to appear. So I
>believe we have to be open to change as well as to compromise as our work
>progresses. In this spirit I think it will help us to get a draft out
>soon, even if it might be controversial, and even if everyone on the WG is
>not able to completely agree.
>
>Eric
A couple of comments here, specifically on the GET to WSDL to SOAP
path. as Eric observes, it's a common use
pattern. It is a common use pattern, because it is useful to people. Now it
is certainly possible that REST can offer
a equally usable pattern which satisfies the same basic need. That's the
kind of synthesis that strikes me a likely to be
constructive.
Second, the observation was made that the WSDL contains design time
information. That's not necessarily true.
It depends on your usage pattern. In *some* (and I stress *some*) scenarios
and environments, its possible to do
run-time discovery of bindings and use that information to build a valid
SOAP call. This is much easier when theres
a common vocabulary (dare I say semantics and ontology) in place, and the
environment supports a service
directory which permits you to locate possible services you wish to use.
Perhaps even more importantly, WSDL descriptions
of current bindings permit run-time validation of bindings at the time of
use. I don't believe there is anything that requires
web services to be though of as having static bindings (in some sense of
the word) The trick is doing things in ways
which permits safe use of such flexability.
One important thing to keep in mind when looking at this stuff is that
people have a very broad range of things they
want to do with "web services." Some people are focused on stuff that
follows up on the basic REST model. Others
people want to do something much closer to OMA. Within reason, we should
aspire to meet both sets of goals, along
with as many other models for how people want to make this stuff work as we
can. The within reason part is important.
At the end of the day, we need a coherent, usable architecture, and
coherence will end up forcing some hard choices.
Being everything to everyone isn't coherent. At the same time, coherence
without sufficient breadth, and in particular
breadth that spans into the space where many of the corporate, commercial
efforts live, is a recipe for failure.
- David
David W. Levine
IBM Thomas J. Watson Research Center
Autonomic Computing Tooling and Standards
Received on Sunday, 21 July 2002 15:17:35 UTC