What Is a Loose Coupling?

A loosely coupled system is usually a message-based system. At this time, the client and remote service do not know how each other implements it. The communication between the client and the service is governed by the architecture of the message. As long as the message conforms to the negotiated architecture, the client or service implementation can be changed as needed without worrying about breaking the other party.

The so-called "coupling" refers to connecting two elements together like a chain.

In software, "coupled" generally refers to

Given that loose coupling is the foundation of SOA, I think it is the same for cloud computing. Maybe it would be a good idea to break loose coupling into many basic models. These basic models include: location independence, communication independence, security independence And instance independence.

Location independence refers to the concept of no matter where a service is, you need to use the rest of the service to discover it in the catalog and leverage it through a late-binding process. Sooner or later, when you use services to continuously change physical and logical locations, you will need them, especially if the services are outside your organization, and you may not have delivered cloud resources. Your risk assessment service may only be on offer on Monday and in the cloud on Tuesday, it's no different for you.

Dynamic exploration is the key to this concept, which means that calling components can locate new services as needed, without having to tightly bind services. Usually these services are private, shared, or they enjoy public services in the directory.

Communication independence means that all components can communicate with each other regardless of how they communicate at the interface or protocol layer. Therefore, we make use of authorization standards like web services, mediation protocols and interface differences.

Security independence introduces the concept of regulating differences between security models and components. This approach is a bit difficult to implement, but it is necessary for any SOA. To implement this model, you must take advantage of a federated security system that is able to create trust between components, no matter what the security model is for the components. This is the main driving force behind several joint security standards that emerged to support loosely coupled models and web services.

Instance independence means that the architecture should support component-to-component communication. This communication uses synchronous and asynchronous models, and no other components need to be in any particular state before receiving a request or message. Therefore, if performed correctly, all services should be able to serve any request component asynchronously, regardless of the order, and remember the message status.