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