SOA is about providing software capabilities through interfaces called services and supporting the business concept known as service orientation, where applications are built as sets of services with service users unaware of how or where services are implemented. Beyond the interfaces—which are a key part, but not the only part of a good SOA—are software components and component models. Component models are useful for building new SOA services from the ground up, but they're also useful for creating SOA services from legacy IT assets. You can use component models to provide abstraction of legacy services and to re-engineer existing legacy assets, especially when the component model supports language neutrality.
There are many aspects to the concept of a software component. This article focuses on software components as they're used within the context of an SOA-based business service solution. In this context, you can use various software component technologies to:
* Implement business services.
* Adapt services for integration between disparate run times, languages, or interfaces.
* Provide a business-level abstraction for the composition of preexisting business services.
The software component concept can be decomposed into what this article calls coarse-grained components and fine-grained components. Unfortunately, it's not possible to define these two concepts precisely. There's a wide-ranging opinion in the industry on how to precisely delineate component granularity. For example, the OASIS SOA Reference Model (see Resources for a link) specifically rejects the notion that interface chattiness is a consideration. By contrast, the Wikipedia definitions (see Resources) primarily center on the frequency and amount of data exchanged between components. Further, the industry has adopted the concept of coupling, which is defined as the fragility exhibited in the relationship between two software components. The terms loose coupling (a small amount of fragility) and tight coupling (a large amount of fragility) are often mistakenly used as synonyms for coarse-grained and fine-grained components.
This article asserts that coupling is only one aspect of granularity, as discussed in the Component interface section, but does support the current industry thinking that, in general, loosely coupled components are coarse grained, while tightly coupled components are more likely to be fine grained. It's worth noting that while some component models focus on one form of granularity, others attempt to strike a balance between the two extremes. (See the Inventory of component technologies section for a categorization of component models based on the attributes described in this article.)
Open source, Apache, SOA, SCA and other good technical tips & tricks on general development
Thursday, December 06, 2007
Article : Software components: Coarse-grained versus fine-grained
Some of the SCA gurus at IBM have written an article around Software component granularity. Below is the article overview, and you can find the entire content here.
I was interested to read the discussions on Granularity - the various definitions have always interested me.
ReplyDeleteI think of Granularity in a general sense referring to the size of a typical or average constituent component of the whole e.g. grain size on abrasive paper -although here I imagine it to be maximum grain size - otherwise you would wreck the surface!
Going forward from this, I took Granularity of a Software Component to refer to the amount or degree of (business) functionality it provided. Presumably, the fact that it is a Component implies that it is already/always was highly decoupled.
On this basis, a Web Service would perhaps be medium-grained, so it would do something reasonably useful in a business context, and hence be likely to be efficiently re-usable, but not fine-grained, e.g. caculate the square root of a number, when things like network latency would render it almost useless for remote compositions.
And then the traditional Monolithic apps. would typically provide/be coarse-grained functionality, at least from an external perspective, i.e solve a few substantial business problems, hiding away all the intermediate details.
If a monolithic App. were made up of (defined in terms of) many fine-grained Components, presumably this would not be a good/efficient use of Component technology, and also presumably the functionality in the Grains would not be available externally.
I hope a definition might stabilize sometime soon - it is difficult to teach these concepts in an academic environment when there is so much disagreement in the literature.