- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 19 Feb 2003 19:09:58 -0500
- To: www-ws-arch@w3.org
- Message-ID: <OFDCF4C95C.7AF96D82-ON85256CD3.00009ABF-85256CD3.0000E897@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 02/19/2003 06:47:25 PM: > > > > > > > -----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 19:10:34 UTC