Wednesday, May 7, 2008

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.

4 comments:

Anonymous said...

Interesting observation: "there is less friction in this style of interaction". As in things continue to move along and not slow down despite the interactions. I guess it's true for any async consumer, but I've never heard it put this way.

Unknown said...

Chris,

wellsy hear, stretching your analogy a tad, does the slob not become event driven when the beer has run out ?

Unknown said...

oops...here I mean

John Schlesinger said...

Having railed against SOA for over sixteen years (the first time was in 1998 with a programmer from KPMG) I think I now have a succinct statement of the problem. Firstly, as Chris states, every programmer thinks integration is just a matter of RPC. Which of course it isn't. The second problem is that we need to separate interaction from integration. Both need routing and transformation, which is why the marketing teams at vendors think they are the same problem. But interaction needs syntactic transformation and two way message routing whereas integration needs semantic transformation and one way message routing. That is why Microsoft no longer uses BizTalk for interaction but rather acquired Apiphany for the task.

The principle is that you can never call out of a transaction in an enterprise application as it stops you scaling. If you call out you serialize the transaction and become dependent on another system. That is, you become flaky and latent.

Or as the CTO of Amazon puts it, all enterprise services must be asynchronous and autonomous.

So rather than use SOA, a marketing term, separate your enterprise architecture into exploitation of interaction (using a Resource Oriented Architecture if possible) and integration (using an Event Driven Architecture if possible).

This will also help you avoid the horrific SOA mistake of making all integration into orchestration, thereby increasing the complexity of the enterprise a thousand-fold.

John