RE: A Modest Proposal (was RE: Binding)

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Monday, January 06, 2003 11:38 AM
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: A Modest Proposal (was RE: Binding)
> 
> 
> > - The most useful thing I can think of for the document would
> > be to take one
> > or more simple but realistic use cases and describe a RESTful and a
> > conventional SOAP/WSDL approach to the problem, then assess their
> > strengths/weaknesses.
> >
> 
> Mike, I originally did this - even picked a 3rd approach - in May, in
> 
> http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0401.html
> 

Great! sorry I forgot about it :-) 

> 
> I will volunteer to update the document that I wrote.  I will 
> make changes ONLY if I see message content that clearly describes changes 
> proposed.  


OK, I'll propose some changes:

Don't use the hoary old getStockQuote example.  Something equally simple,
fine, but that one annoys people (as we've seen here!).  Getting and setting
the bid price in an online auction?  

Would it be sensible to reference SAML instead of "security ACLs", just to
be a bit more concrete?

I agree with the suggestion to use specific URIs, and to sketch out the
operations going on behind the scenes a bit more.  Again, making the example
more concrete will "grab" the reader.

I didn't follow the Benefits section very well.  Maybe it just needs some
verbiage, e.g. "The POST of a SOAP message approach has the advantage that
it could be deployed using different protocols (such as SMTP) with very
little additional work, because the system administrator has already mapped
the method information in the message onto the back-end code." You were
probably going to do that anyway :-)

It doesn't seem like the Benefits section hits very many of the points we've
discussed (and discussed ... and discussed ...) over the months.  Saying
something about the ease of discovery (aka "a priori understanding") for the
HTTP GET/PUT scenario, the fact that you can hyperlink to and cache the
results of the GET, etc. seems like a good idea.  Likewise, mentioning that
the POST/SOAP approach is supported "out of the box" by vast numbers of
programming toolkits is worth mentioning, as are the various reasons WHY
it's easier for an IDE to support the POST/SOAP approach than to figure out
when to use GET, PUT, or POST and to figure out how to encode the necessary
information in URI syntax. Also, there's the point I raised in the thread
that it's generally easier to map the POST/SOAP style to legacy code being
integrated. I'd also mention as an advantage of #1 that VASTLY more web
servers deployed in the real world support POST than support PUT.  

Finally, mentioning the recent developments in firewall technology to
"understand" SOAP messages by parsing the XML (perhaps with hardware
acceleration to make this less of a bottleneck) would be useful.  See (for
example, this just happens to be on XML.org today, it's not a great summary)
http://www.ecommercetimes.com/perl/story/20374.html   That would also
address several of Mark Baker's followup comments.

As for Mark's other comments, I agree that elaborating on why Approach #3 is
more scalable would be a good idea, and that the limitations of SSL in this
kind of application need to be clarified.  I agree with his points about the
Web infrastructure being optimized for GET, but that was presumably covered
under "you can cache the results of a GET" (unless there are some other ways
in which the Web is optimized for GET I'm not thinking of).  Finally, I
would not touch the "application protocol" business with a 10-ft pole; as
someone recently mentioned, the mapping of the OSI layers to Internet/Web
practice is a bit of a rathole, and the OSI stuff is not a  normative input
to this WG anyway!

Received on Monday, 6 January 2003 19:24:24 UTC