Stamp out HTTP. This continues to be interesting. Some people are looking to layer asynchronous and reliable delivery over HTTP, while others are advocating that we start over and re-solve the problems already addressed by SSL, keep-alive, session state, communication through firewalls etc.
Both are points on a spectrum. From one perspective, HTTP is a transport which can support multiple protocols. From another perspective, SOAP is a protocol which can be delivered over multiple transports. Both are true statements, but depending on which one you focus on, you get different answers to real live engineering problems. For example, should any authorization or state information be placed inside the SOAP envelope (i.e., in SOAP headers), or outside the envelope (e.g., as HTTP headers). One thing is for sure, if I do it one way and you expect it another, we won't interoperate.
Personally, I'm torn. As a software developer, I do feel the real itch to start over with a clean slate. One can always find "justifications" for such an approach. As an engineer, I see the pragmatic need to work with what we've got. My guess is that we are in a transistion period that will last longer than any of us will like. Back in the days when IPX, NetBEUI, Banyan IPC, and SNA were in vogue we had all sorts of gateways. Ultimately, we said "the heck with that", and pretty much universally adopted TCP/IP.
I am a big believer in SOAP, but I suspect it will be some time before it displaces all other protocols. Until then we will all have to stretch the protocols we have got well beyond what they were originally designed for. Cockroaches indeed.
11:21:40 PM 
|
|
