This post originated from an RSS feed registered with Java Buzz
by Nick Lothian.
Original Post: Re: More on "XML over HTTP"
Feed Title: BadMagicNumber
Feed URL: http://feeds.feedburner.com/Badmagicnumber
Feed Description: Java, Development and Me
I can't be as good a writter as Ted is, because he's totally missed the point of my original post. I'm not recommending using Webservices over HTTPS because of the transport security benefits (although these exist) but because it stops tampering by well intentioned but badly designed intermediaries. Ted later points out that
An "intermediary" that wants to act on the payload isn't really an intermediary anymore, but a processing node in its own right that participates in a workflow chain. An intermediary certainly has the right and responsibility to affect the message headers, but not the payload itself. To say that SSL provides the "benefit" of preventing well-meaning intermediaries from doing this is to hide the ill-behaved nature of the intermediary itself, and doesn't properly address the problem.
This is true of course. Unfortunately in the real world clients have a habit of doing things like (as a totally imaginary example) installing badly behaved firewalls and then insisting that software that breaks because of them be "fixed" even AFTER Checkpoint admits the faults in their hardware.
Ted also says:
I'm sorry you got sold the bill of goods that said that "XML over HTTP" was supposed to be easy--it's only easy so long as you did simple things with it.
Actually that's the point. This was pretty much as simple as it could possibly be: .NET calling a RPC style Java based web service.
It really should have "just worked". The only complexity in the system (.NET <-> Java type mappings) wasn't what caused it to break.
I'm convinced that this failure mode (people doing stupid things) breaks more enterprise systems than things that are typically planned for (hardware failure etc).
Previous Topic
