Introduction

Service Loose Coupling means that each service is an isolated entity with limited dependencies on other (shared) resources. These resources could be technologies, (legacy) applications, databases, components, API's, infrastructure... The more a service is isolated from external resources the more predictable and reliable it will be. Don't start thinking that you can't have dependencies/relationships between services, service compositions are essential to SOA and is also one of the SOA principles but services shouldn't share the same underlying resources such as a database.

Standardized Service Contract

Service Loose Coupling also means that the service contract should be created with this principle in mind. When the contract is generated from a developer tool or runtime environment you automatically make the service dependent on that technology and so the service implementation and consumers will also be dependent on that technology.

Good Coupling and Bad Coupling

By now you should have realized that some types of coupling are good (allowed) and some are not good (or should be limited) and some are necessary. Coupling a service to a service contract is good but not the other way. Coupling between services is good, services must be composed to to create new business capabilities. Eventually the service will be coupled to a specific technology and runtime, this is necessary, you must develop your service with some technology but avoid the coupling of you contract to a specific technology.