SOA aims to create a unified loosely coupled software architecture in which resources can be plugged in and out at will. Grid aims to do much the same in hardware, except that being hardware, most commercial implementations tend to prefer tight coupling wherever possible, because that allows them to squeeze higher performance out of the environment.Firstly, we can agree that SOA has a tendency towards loose coupling and heterogeneity, while much of the current grid work has a tendency towards tight coupling and virtual homogeneity. But this is not an absolute contradiction - merely a tension that has to be watched.
Secondly, there may be nothing wrong with an architecture that deploys both tight coupling and loose coupling - provided that the overall geometry makes sense. (As an analogy, think of the bone structure of the human body, which provides both strength and flexibility.)
- For example, it may make sense to deploy loose coupling within the business and within the software application, in order to achieve tight coupling (known as Alignment) between the business requirements and the application services.
- Conversely, it may make sense (despite Phil's criticism) to deploy tight coupling at the hardware level in order to support loose coupling at the application level.
Phil Wainewright agrees about granularity at least.
"Adopting an SOA can help you realize much greater efficiencies in resource utilization without having to buy any new equipment at all. SOA doesn't need grid - it virtualizes all resources within the IT infrastructure anyway, irrespective of whether they're hardware or software resources. It's just a matter of how granular you want to make your service definitions."I shall say more about stratification and granularity in a future post.
No comments:
Post a Comment