W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

RE: Proposed text for section 1.6.2 and 1.6.3

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Wed, 7 May 2003 19:20:43 -0400
To: "David Orchard" <dorchard@bea.com>
Cc: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org, www-ws-arch-request@w3.org
Message-ID: <OF2817858A.AE44DBA4-ON85256D1F.00803818-85256D1F.00803B55@us.ibm.com>
+1

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 05/07/2003 05:33:18 PM:

> 
> Indeed, I had rebutted this point earlier.  REST has better visibility 
only
> for single protocol solutions, where visibility is defined to be the 
ability
> to determine the method.  I actually think that this property is 
redundant,
> as it is devolves to either the performance of the intermediary or the
> simplicity of the configuration of the intermediary.  Which are covered 
in
> the perf and simplicity properties.
> 
> Speaking of the simplicity property...  Given a multi-protocol situation 
and
> complex interactions, it is typically easier to deploy "RESTless" SOAs 
than
> RESTful SOAs.  I can create 1 xpath/xquery to do the match on the soap
> representation, rather than figuring out which of the combination of
> application methods are required.  As in, check for "getFareQuote as the
> SOAP body's first child" rather than check for HTTP GET and SMTP ... and 
FTP
> ... and JMS vendor 1 method foo and JMS vendor 2 method bar and .... 
Which
> scales well to doing things like "updateFareQuote" instead of HTTP PUT 
or
> some magic thing inside a SOAP POST.
> 
> I can achieve all the samples of visibility by using either dynamic 
queries
> against the content or by standardizing where the method is in the soap
> body.
> 
> I believe that in most cases, simplicity of development and deployment
> outweighs the performance property.
> 
> Cheers,
> Dave
> 
> > >
> > > I thought we had agreed that REST had superior visibility than
> > > SOAs?  And while I agree that XML improves visibility, I strongly
> > > disagree that the visibility of SOAs is "good"; on the
> > contrary, it's
> > > *very* poor.  I suppose this isn't the right time for that
> > discussion,
> > > so I'll just raise an issue when it's published.
> >
> > I've never agreed with you on that issue; I think you thought
> > that Roy had
> > convinced Dave Orchard of this point at one time, but that's
> > for him to
> > speak to.  I'm happy to accept "friendly amendments" to the
> > way I stated the
> > visibility benefits of XML, but I truly believe that XML *is*
> > the secret
> > sauce that extends visibility to the entire message, not just
> > the protocol
> > metadata that classic firewalls/proxies use.   I would be happy to say
> > something like "as a practical matter, HTTP headers are more
> > visible to
> > *today's* widely deployed intermediaries than XML is," but I
> > think you have
> > something more profound in mind. And yes, I would *much*
> > prefer for you to
> > raise an issue and let the Powers that Be sort it out than
> > continue to argue
> > the point, because I think neither of us is likely to
> > convince the other.
> >
> >
> 
Received on Wednesday, 7 May 2003 19:21:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:18 GMT