The SOA service granularity issue

I was reading a…

blog entry on Bankwatch this morning, discussing an IBM doc about SOA. The point was being made that by turning software applications into reusable building blocks, new services to reconfigure the business can be carried out at great speed.

This made me think of the SOA service granularity issue, which I have discussed in many places such as in the free Illuminatus Research report on Best of Breed Mainframe SOA Tools. Although this paper is targeted at mainframe users, the granularity discussion is relevant to any SOA user. Basically, the problem is that if SOA services, the reusable building blocks, are created too mechanically, there can be serious impacts on performance and throughput.

For example, if every low-level operation is turned into a web service, this may be architecturally clean, but it means that the clothing around the web service has to be executed on every invocation. This might include mapping from non-XML to XML formats and back, for instance. On top of this, the architectural picture provided by SOA is deliberately a logical one. The physical reality may be different. So, invoking six web services to make up an operation may be fine if they are all running in one place, but a terrible overhead if they are geographically dispersed across multiple operating environments.

The trick is to decide on the desired granularity before rushing headlong into creating the reusable building blocks.


Posted in Imported, SOA.

Leave a Reply

Your email address will not be published. Required fields are marked *