Just Because You Can

In a subsequent post to the one I mentioned below, Steve Loughran writes...

The only place SOAP survives is in the enterprise, because if you can control both ends of the conversation, you can use the same toolkit and eliminate interop. The key selling point of most SOAP stacks -reverse generation of WSDL from your classes- is actually viable in this context...

He goes on to provide his own hypothetical position statement if he were to attend the aforementioned "Oh Really?" conference...

1. How to provide a client programming model that accesses REST endpoints with the same ease of use as same-stack-SOAP-development?

2. How to integrate Atom feeds and APP into the enterprise as an alternate communications pattern; polling over posting?

3. What is the best programming paradigm for this. Ruby on Rails shows how a dynamic language with continuations and the ActiveRecord database binding makes server-side web development easy. What can we do with clients?

4. How to keep Web 2.0 style applications providing a back end 'service' architecture that meets the needs and business models of providers and consumers.

5. How best to transition legacy middleware -including SOAP systems- to the new world

So what is so great about #1 even within the enterprise? (I've not seen much evidence in a small number of data centers I've seen). There is always a community of IT people fascinated by shiny code generators. IDE support for SOAP is just that. There is no more "architecture" built around these code generators than the CASE tools of the past.

Still on #1, from what I've seen of the SOAP/WSDL approach to using HTTP is total ruin. HTTP is a dynamic, duck-typed approach to "messaging" (ok, "resource transfer" -- HTTP says some things about what's been transferred but that's independent of this point).

Figuring out how to place a code generator for a static language in between the HTTP client and server will likely just gum up the whole works. Better to figure out how to develop HTTP applications in various languages and libraries as simply and *dynamically* as possible.

Which leads to #2. There is a lot of room for HTTP and XMPP to develop in the enterprise. Meanwhile there are open source tools for using these and more API/language-centric tools for coordination/messaging in the enterprise. The real big key is to allow various parts of the enterprise to evolve independently. If the data center can generally be updated incrementally without unduly updating too many parts at once (unlikely from what I've seen), then incrementally moving HTTP and XMPP into the data center should not be such a big deal.

On the other hand if the data center is typical then there are all kinds of unnecessary dependencies preventing *anything* from evolving efficiently. This is the bigger problem that should be addressed first.

Number 3 is a doozy -- the browser has to come around to reality -- it is a *platform* for applications. Multiple, concurrent, independent, and secure applications. Unfortunately even under the best of conditions, the most modern browser is a half-assed piece of work. Coming to terms with that is crucial. Nothing proprietary though.

Dynamic coordination protocols still require contracts. They just aren't used for code generation. So #4 implies the need for contracts that support understanding and change, but clearly not WSDL that only pretends to be a contract.

Finally #5, the transition. See my response to #2. Ease of transition is the key any sort of data center sanity, which explains why the data center is so insane, nine times out of ten. Isolating crap like SOAP and ultimately removing it are steps toward sanity and successful transition.