Musings with John Schlesinger

John Schlesinger is an event thinker par excellence. So whenever I get the chance, I visit him in London to validate some thinking - or just to spend time with a terrific guy! So on a recent trip to London the subject turned to the rise of event thinking and the downplaying of the traditional SOA patterns. Of course the SOA traditions are being reborn to encompass the events brigade, but because SOA is so broadly and imprecisely defined that's perfectly OK. The SOA hype is over, long live the SOA hype. But that's perhaps a topic for another time.

The key observation from my lunch with John was one I had suspected, but was not able to frame properly. With a few well chosen sentences John had it for me.

This is all concerned with orchestration and control. So (deep breath), here goes. Where an event is raised and that event is to be processed by some subscriber, any intent to orchestrate the handling of the event by the subscriber results in a massive increase in complexity. (Roger Sessions will love this!). Naively one starts to think you have the "OK/Not OK pair" of possible responses. But then the "Not OK" responses blossom out of control. We have situations where the "Not OK" response must result in the retransmission of the event (and how does that happen?) and other cases where it must not. We have cases where the originator of the event has to interpret the behavior of the recipient. That sounds like some awfully nasty coupling to me. So instead of thinking that one has the "OK/Not OK" duality from the recipients view point actually what you have is the"OK/{set of lots of possible not OKs which the sender has to know about} multi-trality. In short that's just crappy design!

Thanks John

SOA is from Mars EDA is from Venus

It seems that in most Service Oriented Architecture deployments, the predominant paradigm is request/response. Consumer A wants something from Service B. Essentially it is an RPC like model, but with extra overhead. This model has been dominant because of several factors:

• We can think of it like an extension of the earliest programming models we ever dealt with - subroutines and functions
• We don't have to get all snarled up in worrying about parallel processing/multi-tasking and other hard to debug kinds of models
• We can break up problems into conveniently sized chunks by some kind of hierarchic decomposition
• All languages support the model intrinsically.

Does this mean that it is the best way? Perhaps for some problems, but surely not for all. I see a subroutine or function as being a rather surly, uncommunicative programming equivalent of a slob sitting in a chair, swilling beer and only responding when he feels like doing so. Very good at doing one thing at a time, easy to discover (after all who can miss the chair, beer can and TV remote).

This model is so dominant that we have even simulated it on top of asynchronous protocols. So even in a system that doesn't support request/response directly (e.g. an asynchronous, message based system) we still allow for the same semantics, but this time fudging them to use pairs of asynchronous messages. Changing the transport doesn't really change the programming model. We still think in RPC terms.

Enter SOA and we often have the same view. This time instead of an RPC, we sometimes refer to a "Service Call". Immediately we should be on the defensive. Call implies request/response. Should that be what our services do? Well, of course sometimes they should.

Now let's look at things from a different perspective. In an Event Driven Architecture, when something happens, the component that realizes something has happened feels the need to communicate this goodness to anyone who will listen. Some listeners will take action as a result. It is almost a gossiping model, a model where as soon as information is available, it is able to be shared. Not only does sharing take place, but it is absolutely impossible for the originator or broadcaster of the information to control what happens to it. It is out in the aether with all sorts of actions taking place as a result. Some of the actions might be beneficial, some not.

So here, we have a much lighter weight, less surly architecture an approach where the actions are distinguished from the notifications, where the actors are actively listening and making decisions for themselves. An architecture that exhibits autonomy and a loosely coupled style. Of course the trouble with a gossiping style is that a large amount of information is made available, only some of which will be acted on. So it is very "chatty" Chattiness in IT systems correlates well with increased resource consumption. In constrained systems (especially those that are network or disk constrained) increasing resource consumption can have a large, and negative impact on the cost of doing business.

In the EDA model, information "publishers" and "consumers" are constantly doing other things. They are true multi-taskers, ever prioritizing their activities, deciding whether to wait for more information or whether to act immediately. Capable of acting and absorbing information at the same time, making complex decisions largely autonomously. In other words, there is less friction in this style of interaction.

Information, of course, doesn't need to be acted on immediately. A useful tidbit might be recognized a long time after some other tidbit, making a situation clear. The arrival of the final tidbit can trigger a complex set of actions, relying on information disassociated from the original event, but somehow dependent on it.

Bottom line, we need to understand when it is appropriate to use one style or another. Sometimes it is good for a bunch of slobs to hang out, grunt and drink beer. At other times a more nimble, more overlapping, less controlling approach can deliver systems that function more smoothly.