This is first one in the SOA series. I will be starting with explaining SOA in simple terms

Coupling as we all know is bad, but it is unavoidable too.The question is how to wisely choose what to be coupled to. A business-level coupling is good one as developers add value by implementing a system use case or a feature, by coupling software functionality together. Anything to do with writing plumbing code is a bad coupling.

In a service-oriented application, developers focus on writing business logic, and expose that logic via interchangeable interoperable service endpoints. Clients consume those endpoints, not the service code. The interaction between the clients and the service endpoint is based on a standard message exchange, and the service publishes some kind of metadata, describing what exactly it can do and how clients should invoke operations on it.

Service-orientation is, as per industry, the correct way to build maintainable, robust, and secure applications. When developing a service-oriented application, you decouple the service code from the technology and platform used by the client. Even securing the transfer of the message itself from the client to the service is also outside the scope of the service, and so is authenticating the caller. The service may do its own local authorization as per the requirements.

Benefits of Service-Orientation

Because the interaction between the client and the service is based on industry standards that defines how to secure the call, how to flow transactions, how to manage reliability, and so on, you could also have off-the-shelf implementation of such plumbing. This in turn yields a maintainable application because the application is decoupled on the correct aspects. As the plumbing evolves, the application remains unaffected.

A service-oriented application is robust because the developers can use available, proven, and tested plumbing, and the developers are more productive because they get to spend more of the cycle time on the features rather than the plumbing.

The many other benefits, such as cross-technology interoperability.When you write a service, you usually do not care which platform the client executes on that is immaterial, which is the whole point of seamless interoperability.

It enables developers to cross boundaries. One type of a boundary is technology and platform, and crossing it is what interoperability is all about.
But other boundaries may exist between the client and the service, such as security and trust boundaries, geographical boundaries, organizational boundaries, timeline boundaries, transaction boundaries, and even business model boundaries. Seamlessly crossing each of these boundaries is possible because of the standard message-based interaction.