|« Same-Day-Delivery is a Key Enabler of rCommerce||Business Strategy in a Multidimensional World »|
Ganesh Prasad and Eric Newcomer are probably one of the two people I respect the most in the SOA community. I had the privilege to work on WS-CAF with Eric and that standard forged most of what I think is right on SOA. I also had the pleasure to meet Ganesh in Sydney in 2009.
That being said I am appalled that in 2012 we are still debating the question Eric asked to Prasad at QCon NY:
"Where I was working previously at Credit Suisse, we had a long debate about sharing and how to share code; we had done some analysis to find there was a lot of overlapping and duplicate functionality in the applications and we could rationalize those down to perhaps a single function that would be shared, but then we had a big question of how should we share it the best way; should we share it with libraries, should we put an abstract interface on it, how should we do it; what are your thoughts there? "
This is an excellent question, one that has haunted and apparently still haunts our industry. So for the record I would like to explain why it is so hard to reuse code and why and how it could be made much easier.
The main consideration you have to make to answer that question is to realize that every concept (software agent, information entity, physical thing, document...), absolutely everything, no matter what it is, has a lifecycle. Unfortunately for us, computers "compute" and do not really care about the states in which "things" are, hence there is nowhere in computer programming languages the notion of state and lifecycle. This is one of the greatest tragedy of software engineering.
I wrote many posts on that concept, but let me reiterate it here one more time. Here is a lifecycle, the lifecycle of stock order (as in stock market). Every state can be understood by any developer and most of them can code easily all the actions that will correspond to each transition on that diagram. That is the code that Eric is talking about, the one that we want to reuse for different situations, for instance retail vs private brokerage.
The fundamental problem to reuse is the lifecycle itself, the lifecycle is often, if not always different for every context, making it impossible to reuse. People look at reusing operations, blindly, without understanding there is an inherent lifecycle. They say I have a "createStockOrder" operation (POST StockOrder in REST BS), I have a submitStockOrder, a cancelStockOrder, ... check, check, check, retail and private brokerage should be able to use the same operations. Well, a typical problem between private and retail is that the funds are available at different times. Retail operations demand that funds be ready and alocated when the order is submitted, when private activities often involves reallocating funds which are not yet settled at the time the order is taken. As long as the transaction can be settled properly, private banking operations can operate without the funds.
So in general, two different contexts, in which the "service" will be used will require variations on the lifecycle implemented by the service. It is often trivial to align a lifecycle to support multiple contexts, it is just a mater of adding states and transitions. But no, our industry went the other way, it came up with REST, it said, you can't reuse the actions, let's make them disappear, voila. No lifecycles, no actions, everything is now burried under a big pile of CRUD. You want to reuse something? You are on your own, PUT, POST, DELETE, ... that's all you get.
So no Ganesh, this is not a problem of "smaller components", "chunks", "coupling" or "cohesion" ... this is simply a problem of lifecycle and variants of the lifecycle based on the context of utilisation. If the lifecycle is the same, great, you can reuse it, if the context requires a different one, you have to augment the existing lifecycle to match two or more contexts. The common parts of the lifecycle (states and actions) will be "reused", the ones that are specifically used for supporting a particular context cannot be reused.
No, it is not a dependency question, it is not a blueprint, it is not about breaking, reuse, ... it is about lifecycle. I am not quite sure why it is not possible to have an honest and serious discussion about the relationship between SOA, reuse and lifecycles. That has puzzled me for quite some time actually.
Ah ... I nearly forgot, and "reuse" happens the other way around. It is not the new context that is using the old lifecycle, it is the the old contexts which are reusing the new updated lifecycle.
How hard can it be to understand that?
Excellent observations. Reminds me of a blog post made elsewhere about why developers don’t use state machines.