[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP and Firewalls
> From: Paul Prescod [mailto:paul@p...] <snip/> > Buried among the various debates was one point that I'd like > to bring to > the forefront. Firewall avoidance is either part of SOAP's > mission or it > isn't. Maybe SOAP uses HTTP as if it were a transport protocol merely > because it's "easier" to plug into HTTP-centric architectures than to > talk sockets (arguable, but anyhow). In that case firewall avoidance > would be an accident. It isn't part of SOAP's mission, IMO. I think you'll find many in the SOAP community taking exception to the characterizations of SOAP trying to subvert the firewall and SOAP developers as trying to sneak past their firewall administrators. I think those who make such characterizations lose the entire SOAP developer audience when they make such assertions. Focusing more on how SOAP can be improved, in this regard, without such characterizations is likely to get a wider hearing. > So here's a simple test we can do. If we can all come to > consensus that > firewall avoidance is a BAD THING then we can put together a petition > that SOAP should use HTTP but simply on a different port. The SOAP > specification should say: "Applications of SOAP MUST NOT use port 80 > unless they adhere to all of the semantics of HTTP.*" <snip/> > * Semantics of HTTP: The addresses of all resources being manipulated > should be expressed in the end-point URI, not the SOAP body. > POST should > not be used for safe, idempotent fetching of information. I think the impact of this last point is too great to expect everyone to drop what they are doing and retool overnight. I think a "cold turkey" approach like this is a lost cause, at this point. I think you'd have better luck convincing the web service community to start thinking about REST and making incremental accommodations toward it, rather than thinking you are going to stop the current juggernaut in its tracks and get it to radically change course. But I doubt there is any real resistance to visibility at the firewall within the SOAP community. Developers just want something that works and is as easy as it reasonably can be. Punching through HTTP is easy. That's the only reason we are doing it. There's no subterfuge intended, here. I'm certainly open-minded on this. Yet, I also have timelines to meet and budgets to contend with. I can't drop the way I'm doing things to comply with REST. All I can do is think about REST as I embark on new work, and think about how it can guide me in doing things better. But honestly, there will be corners cut and compromises made. Ultimately, I'm paid to make it work, not to comply with REST. But I will probably be making incremental changes in the approaches I adopt and thinking about how REST can help. And I would have no objections to seeing SOAP 1.2 make some explicit accomodations to REST. As long as it doesn't stop me from getting my work done.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|