RE: Loose coupling is like pornography

Assaf,

Using concrete use cases help! I think that you are making a point: HTTP
+ XML is not enough! Another proof of that is that, although XML and
HTTP are pevasive technology, there are not a lot of web based
application to application integration deployed out there.

The question then is: can we extend HTTP + XML in a less intrusive way
than the RPC-style SOAP allows to? Do we care?

Edwin

> 
> So I have a message with two parts and I want to encrypt one 
> using key A and one using key B, and I want to carry my 
> transaction identifier (like it or not, I need to talk to a 
> system that expects it), and I want to put an expiration time 
> that is calculated from my clock + time-to-live.
> 
> So I have a bunch of message handlers that do all that for 
> me. And because there's a uniform way to represent where the 
> body goes and where the headers go, they can do that for any 
> SOAP message I sent. And at the other hand I have handlers 
> that can extract that information from the message without 
> having to understand the contents (the consumer does, though).
> 
> Now I want to do that without SOAP. Plain XML over HTTP. But 
> these handlers don't have a place where to put all the 
> information. HTTP headers work, but they're not XML. So I 
> have to do a lot of binary coding there, just like we do with cookies?
> 
> That's the value proposition of SOAP. It's a carrier 
> mechanism just like HTTP, but as opposed to HTTP the headers 
> are XML and the parts are XML, and they are all wrapped in an 
> XML envelope. Otherwise, quid pro quo.
> 
> I just think SOAP is more XML-ized than plain XML over HTTP, 
> that's all. It costs a little, but we were discussing the 
> loosely coupled proposition and I think SOAP makes a better 
> loosely coupled proposition as far as message handlers are 
> concerned. (Plus some other benefits)
>