After many years of relative success CORBA gave way to Web Services. Showing my age, I was at the first OMG meeting where SOAP was introduced and at the time it was generally accepted as a cool way of getting past the firewall and not a lot more. There was no Web Services architecture and certainly no grand plans along the lines of the CORBA architecture. At that time most people were worried about CORBA versus DCOM or CORBA versus J2EE, and not whether XML over HTTP would become a serious challenger in the EAI space.
However, over the years SOA has become more widely accepted and Web Services as the preferred implementation choice. The loosely coupled, long duration nature of inter-organisation interactions suits SOA well and the amount of vendor support for Web Services (as well as using HTTP) makes them a natural fit. The weaknesses of the CORBA and DCOM distributed object models have been well reported over the years (and firewall vendors didn't help) and both SOA and Web Services proponents have talked about not falling into the same pitfalls.
So it is with some surprise thatI came across this from the W3C TAG. I don't have a problem with defining state in Web applications, but it's got to be done right or we will revert to the closely-coupled nature of the past. It's nice to see Dave saying that his company's application server uses WS-Addressing and yet is scalable and fault tolerant, but that doesn't address the point we've been making: the general notion of context is a better approach. It is more scalable and much better suited to loosely coupled interactions. That's why JBossESB has had the notion of context at its core from the start.
Sure, you can use a tightly coupled interaction pattern like object keys in your favourite application server or ESB, but that doesn't necessarily make it right. What it does do is make it more complex from implementation, management, scalability, fault tolerance and flexibility perspectives. You may be convinced by your favourite sales person today, but without a suitable loosely coupled architecture at the heart of your SOA infrastructure or ESB, you may repent at leisure!