lustratus LiteBytes

Talking to my colleague Ronan the other day, he brought up the issue of shared vs reusable SOA services.

I have to confess that at first I didn’t really see much difference. We all know that a key element of SOA is that it provides a pool of reusable services, and that this reuse can lead to lower maintenance costs, less redundancy and reduced risk. Surely saying ‘shared services’ is just the same thing, isn’t it?

However, on thinking it through, I can see the point. As an ex-developer myself, I remember reusing lots of bits of technology – whether it was a segment of code I was copying from someone else’s program, Powerpoint slides I was using as a template to modify, or someone’s coding technique I thought was pretty cool. This sort of reuse is definitely NOT what SOA is about. This rather blinkered view of reuse ended up with multiple copies of the same segment of code as it was reused by someone else in a different program. SOA is about making sure that a service can be called by users anywhere, whenever needed, but in a LOOSE-COUPLED sense, where there is no need for the caller to know anything about the implementation details and there remains only one copy of the actual service itself (although it may have many run-time instances).

Some people may argue that this is what they mean when they talk about reuse in an SOA sense, but I can now appreciate that this is introducing all sorts of opportunity for confusion – and the last thing SOA needs is MORE confusion. In contrast, talking about shared services instead of reusable services has a much clearer connotation. The implication is that there is one service, and it is shared between any operations that need it.

So, in an effort to continue to demystify SOA and sharpen understanding of it, following on from my Lustratus Insight about getting clear on what an SOA service is I am advocating a shift to talking about SOA as providing SHARED rather than REUSABLE services.

Steve