- From: David Orchard <dorchard@bea.com>
- Date: Tue, 28 May 2002 12:38:48 -0700
- To: <www-ws-arch@w3.org>
Why do firewalls break with SOAP being used as an application protocol? My guess is that you will say because the method name is inside the message. And that parsing the message to get the method name does not scale. So if I can (again) talk about requirements and scenarios (why is this so hard?). FWIW, I'm getting increasingly frustrated with vague and grandiose claims that lack detail. This is probably my last attempt to initiate a meaningful discussion on the subject of SOAP vs Web architecture. Sample Application: A StockQuote service has 2 different methods, getStockQuote for retrieving a quote and a setStockQuote for setting the price. There are different security ACLs for each of the methods. Requirements: An intermediary, typically a security intermediary such as a firewall, should be able to determine the whether to allow or deny access based upon the methods message in a timely manner. Quote updates must have higher priority than gets, as the information must be as current as possible according to SLAs. Design: 1. Using a SOAP HTTP POST binding to a single URI for both of these, a security intermediary must scan the SOAP message to find the first child of the body in order to determine which ACL to apply. The time to scan thus varies linearly with the number of headers. In typical applications however, there will be few headers. The admin of the security intermediary must know which SOAP method to configure the ACLs for. 2. Using HTTP GET and HTTP PUT for each of these, a security intermediary can use the HTTP method to determine which ACL is applicable. The admin must know which HTTP method to configure the ACLs for. 3. Two different URIs are used with SOAP HTTP POST. The security intermediary applies the different ACLs to the different URIs, rather than URI/method tuples. The admin applies the ACL to any and all operations at the URI. We would probably partition the application in different clusters for the prioritization. Further, we'd probably do some kind of session affinity for the "writes", as there is probably only one "writer" though many readers. In all cases, the intermediary scans the message for the security credentials. Benefits of each design: 1. The service could be deployed to additional protocols and the admin does not have to know any additional method information, ie use the same method/ACL binding for SMTP. Easier deployment - there's only 1 resource that is deployed. 2. Scanning time to find method name. Easier deployment - there's only 1 resource that is deployed. 3. Handles node scalability better as it's easier to cluster services by URI than by method on a URI. Also simpler for the admin to do security. This is also standard web practice today - higher security messages are typically done using SSL on a completely different URI space and set of servers. Further, because the method does not have to be determined, this is the highest performant security model. Finally, this model is more consistent with current security firewalls which are typically at the URI level. Most web firewalls have a default mode that lumps GET and POST together into the same ACL. Firewalls do typically offer HTTP method distinction, but it's not used as often as URI/any method style. The choice of application design is dependent upon the trade-offs between Service RAS (what #3 optimizes for), run-time performance (#2) and ease of deployment across multiple protocols(#1). Summary: This sample application, requirements and designs provide no compelling evidence that SOAP as an application protocol is broken. While I'm reluctant to bring Roy's thesis into the discussion, his thesis does specifically talk about which functions REST is optimized for. And that's the level of what our discussions should be at. Maybe web services applications require different optimizations that browser applications. Further, this example shows the notion and design of resources and representations of resources are application specific. The web certainly optimized for certain types of resources (html pages, images) and applications (browsers). The optimizations may not be appropriate for application to application communication such as stock quotes. Finally, the alleged problem of having to look inside the message for the method was solved in SOAP 1.1 with the HTTP SOAPAction Header. If this was such a crisis issue, why was this dropped from SOAP 1.2 and why isn't there a number of people (like yourself) lying in the road requiring SOAPAction? Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Mark Baker > Sent: Tuesday, May 28, 2002 4:41 AM > To: Champion, Mike > Cc: www-ws-arch@w3.org > Subject: Re: SOAP and transfer/transport protocols > > > On Mon, May 27, 2002 at 10:58:36PM -0400, Champion, Mike wrote: > > OK, what requirements and usage scenarios are not met when SOAP > > is treated as the application protocol, and HTTP is a transport > > protocol rather than an application protocol? > > Off the top of my head; > > - inability to reuse established agreement that permits a priori > communication > - inability to work over firewalls in the long run > - inability to properly leverage the value-add of intermediaries > developed for that application protocol (such as firewalls) > > It is a complete non-starter for an Internet scale architecture to do > what you and David are suggesting. On the other hand, if you > only want > Web services to work behind the firewall, then this would be > the easiest > way to ensure that, because there's no pesky trust boundaries to worry > about - i.e. you can safely assume a single administrator; > > http://java.sun.com/people/jag/Fallacies.html > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@acm.org > http://www.markbaker.ca http://www.idokorro.com > >
Received on Tuesday, 28 May 2002 17:53:40 UTC