Where SOA Meets Cloud

David Linthicum

Testing for a Loosely Coupled Architecture

user-pic
Vote 0 Votes

Been thinking. Considering that loose coupling is a foundation of SOA, and I would say cloud computing as well, perhaps it's a good idea to break down loose coupling into a few basic patterns: Location independence, communication independence, security independence, and instance independence.

Location independence refers to the notion that it matters not where the service exists, the other components that need to leverage the service can discover it within a directory and leverage it through the late binding process. This comes in handy when you're leveraging services that are consistently changing physical and logical locations, especially services outside of your organization that you may not own such as cloud-delivered resources. Your risk calculation service may exist on premise on Monday and within the cloud on Tuesday, and it should make no difference to you.

Dynamic discovery is key to this concept, meaning that calling components can locate service information as needed, and without having to bind tightly to the service. Typically these services are private, shared, or public services as they exist within the directory.

Communications independence means that all components can talk to each other no matter how they communicate at the interface or protocol levels. Thus, we leverage enabling standards, such as Web services, to mediate the protocol and interface difference.

Security independence refers to the concept of mediating the difference between security models in and between components. This is a bit difficult to pull off, but necessary to any SOA. To enable this pattern, you have to leverage a federated security system that's able to create trust between components, no matter what security model is local to the components. This has been the primary force behind the number of federated security standards that have emerged in support of a loosely coupled model and web services.

Instance independence means that the architecture should support component-to-component communications using both a synchronous and asynchronous model, and not require that the other component be in any particular state before receiving the request, or, the message. Thus, if done right, all of the services should be able to service any requesting component, asynchronously, as well as retain and manage state no matter what the sequencing is.

The need for loosely coupled architecture within your cloud computing solution is really not the question. If you leverage cloud computing correctly, other than in some rare circumstances, you should have a loosely coupled architecture. However, analysis and planning are also part of the mix...understanding your requirements and how each component of your architecture should leverage the other components of your architecture. Leverage the coupling model that works for you.

Leave a comment

This blog is your first step toward understanding the issues you will face as cloud computing and SOA converge. The movement to cloud computing is a disruptive change that IT departments will soon face as SOA and cloud computing begin to have an effect on the modern enterprise. IT managers must learn how to give as well as take information in this new, shareable environment, while still protecting their company's interests. Innovative companies will take advantage of these new resources and reinvent themselves as unstoppable forces in their markets. Those who don't take advantage of this revolution will become quickly outdated, perhaps out of business.

David Linthicum

David Linthicum is the CTO of Blue Mountain Labs, and an internationally known distributed computing and application integration expert. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT