What does it mean for a service to be loosely coupled in a Service-Oriented Architecture?
A service is said to be loosely coupled if its consumers are minimally impacted by changes to that service or its environment. Some coupling is obviously inevitable since the consumer has to make use of the service but can be minimised in a number of ways:
1. Separation of interface and implementation
The service interface is the formal contract between producer and consumer. This is the part that should not change frequently. The implementation however may need to change as more services are created, as the platforms are upgraded or changed etc. Separation of interface and implementation allows services to grow without impacting the client.
Notice that attempting to reduce dependency by providing a weakly typed interface that does not “change” frequently just means runtime as opposed to bind time coupling.
2. Versioning Policy
Service interfaces will change as new consumers bring new requirements or the business domain changes. An effective versioning policy will allow existing consumers to be isolated from service interface changes as much as possible. The policy should consist of mechanisms which allow services to be extended without forcing existing consumers to upgrade, i.e provide some degree of backward compatibility. On the other hand, the policy should also enforce an upgrade interval which consumers would need to comply with.
3. Runtime Contract
The functional contract between a consumer and producer is covered by the interface, but there is also a runtime contract, a service level agreement (SLA) which both the service and its consumers should be subject to. Consumers must be insulated as much as possible (within the bounds of the SLA) from any runtime changes to the service environment such as increased load or platform outage. This is achieved through clustering of services to provide failover, and partitioning hardware so that services do not have a runtime impact other services sharing the same environment.
4. Platform independence
Platform independence is partly achieved through separation of interface and implementation, but primarily requires a platform agnostic communication mechanism such as web services between consumers and the service. Platform independence allows infrastructural changes to occur with minimal impact on service consumers.
5. Location transparency
Services may change location for any number of reasons, e.g. servers are decommissioned, capacity management moves services to underutilised servers. For this reason its important for consumers to be isolated from the exact location of the service. This may be achieved to a degree through the use of DNS names hiding IP addresses, or creating server clusters fronted by an IP load balancer virtual service address. However, both of these still bind the consumer to a logical instance of the service. In contrast a service registry provides additional decoupling in that consumers are searched for by attribute (e.g. name and version number) rather than being bound by name.
You may also like:
Service Characteristics - Contract
Service Characteristics - Abstract
Service Characteristics - Composable
Service Characteristics - Autonomous
Service Characteristics - Discoverable
Service Characteristics - Distributed
Service Characteristics - Reusable