SOA Forum 2009 is history

On Wednesday the SOA Forum 2009 (http://www.soa-forum.ch) came to an end. We had a spectacular crowd of 175 attendants. Below are the slides that I presented in Track 2 together with Martin Kräuchi:

End-of-time Prophecies on Middleware, SOA, ESB and else

When Nostradamus pronounced and published his famous prophecies in the 16th century he did not need to worry about target consumer categories. His predictions - some of them interpreted as end-of-time prophecies or just plagues, earthquakes, etc. - where all-encompassing. Unfortunately, none of his writing was ever interpreted as predicting an event before it actually ocurred. :-)

So, what about those target consumer categories? I came across these when reading an excellent article by Steve Vinoski with the title "Is Middleware Dead? (IEEE Internet Computing, vol. 8, no. 4, 2004, pp. 94-96). This article is also about predictions -- in the technology and market domain this time.

Steve Vinoski wrote this article in response to "The End of Middleware", where Jonathan Schwartz of Sun touted middleware to be dead. The assumption behind this pronounciation: everybody would use Sun's Java Enterprise System then there would be no need to integrate with other middlewares. Of course, it did not pan out this way.

Similar pronouncements about the death of CORBA, SOA, ESB and many other technologies have been made. Steve points out that such predictions frequently do not take the target consumer category into account. According to Crossing the Chasm, there are five such categories in a technology adoption lifecycle (- innovators, - early adopters, - early majority, - late majority, - laggards).

When an "early adopter" feels that a certain technology is dead -- it may be alive and kicking from the point of view of the "laggard". One-size-fits-all solutions are therefore impossible. Where are ESBs on that adoption bell curve? Pretty much at (or slightly after) the peak, I'd say.

Stateful vs. Stateless Services

From a runtime point of view it is advantageous to have stateless services. Statelessness - from a conceptual point of view -- means that the service does not "remember" state between consecutive invocations. Of course, the service may still store information in the DB backend. The important point, however, is that this state is not within the service instance or the service volatile memory.

Clearly, stateless services do scale better: Additional instances of the service can be fired up to cope with increased load. They can also deal better with failover situations. A client request may be routed to an alternative instance transparently when the original instance goes down.

However, sometimes stateful services do make sense from a modelling perspective. Nicolai Josuttis, for example, describes a shopping cart service. For this type of service, a client would expect to successively call operations to add new items.

A stateful service may be implemented as a stateless service: either by sending all relevant information (eg the shopping cart contents) with every request or by sending a session ID with every request and keeping the shopping cart contents in the DB. Or a "real" stateful service keeps the shopping cart state in memory - this requires session affinity: ie, each successive request by a given client must be routed to the same service instance. When this instance goes down, the user must start their shopping trip all over again -- possibly an acceptable tradeoff in an eCommerce application. Nicolai Josuttis works out the associated tradeoffs (state in frontend, state in service, state in backend) really nicely in his book (p.195).