- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Wed, 19 Feb 2003 16:47:25 -0700
- To: www-ws-arch@w3.org
> > > -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Wednesday, February 19, 2003 6:26 PM > To: dorchard@bea > Cc: www-ws-arch@w3.org > > On Wed, Feb 12, 2003 at 10:01:31PM -0800, dorchard@bea wrote: > > The RESTful SOA has the advantage better visibility, as the > firewall > > can simply examine the generic interface to determine the > action being > > performed. Intermediaries, such as HTTP routers or > caches, can simply look > > at the method. An example is that a cache can look at the > GET and the > > identifier, and return a cached representation. This is much more > > difficult if the method is in arbitrary places in the POST. > > Re-usability can be higher as the service may be available > on the Web > > as a URI may be transferable. > > I agree with him completely. The only part I disagree with is "much" in "much more difficult." Sure it's easier to write a firewall that only looks at HTTP headers and not the SOAP content of a message, but it's do-able to build XML/SOAP-aware firewalls, it's being done, and this is practical mainly because XML and SOAP provide a framework that is flexible enough to be useful for most anything but "visible" via standard XML toolkits. Obviously this extends to routers as well; SOAP-aware routers would work with any protocol -- FTP, SMTP, BEEP, TCP/IP, MQ -- as well as HTTP. XML standards (e.g. Xpath) allow routing based on message content as well as the headers. I think of this as a feature to be valued, e.g. in spam filters. So again, I agree that "visibility" is an important property, but what powers it is *standards*, not just HTTP.
Received on Wednesday, 19 February 2003 18:48:22 UTC