SOA as the name suggest is a development strategies that tries to put decoupling in mind from ground up by using the notion of services. Although decoupling is un-avoidable when we engineer software/component but to a degree of efforts, SOA allows you to take advantage of seperation of concerns service orchestration, Service Choreography, REST Architecture and Service reusability. Decoupling is bad to some extent because this business of ours is all about integrating stuffs (coupling), there are types of coupling that make sense and there are coupling that makes no sense at all. The following are sample of types of coupling :
Business Coupling : In the real world where we make money and apply both theorical and practical knowledge to software engineering, we cannot avoid integrating systems with legacies and new applications. Business coupling makes sense because we tend to apply rules of data interchange between disparate systems why we avoid any form of tight coupling to reduce the dependencies amongst participants. This is an exact coupling that SOA would allow, the business logic codes are exposed as a service and there are no dependencies between services and consumers. Although business coupling could lead to plumbing if developers do not take into account the tenets of Service Architecture.
Plumbing Coupling : This type of coupling is what most developers that are just finding their ways into true software engineering processes do. This coupling is bad and does not add any value to your assets and infrastructure. In my years of experience, i have encouraged developers and have educate developers to move away from this development practices because as long as you continue to plumb couple, your system will die naturaly without any cause. Plumbing is a sin that we all must have committed one way or the other and the only ways to cleanse ourselves from this sins is to embrace SOA and try to pay back our technical debt by constanly reviewing and refactoring our code.
Having understood the two most common coupling, we should now know where SOA fits in software engineering. SOA allows us to expose business functionalities without exposing the underlying code by enforcing a data-interchage driven by SOAP (Simple Object Application Protocol) by encouraging metadata interchange. SOA is client/devices/platform independent so far we follow the W3C semantics of SOAP and the WS-* specifications.
The Tenets of SOA
- Explicit Boundary : Service should communicate with themselves in a true and loose coupled manner using agreed messaging construct (SOA encourages SOAP Envelopes). As long as there is no rigourous dependencies amongs services, services should be able to send and recieve messages between themselves without the knowledge of where they are located. Services are platform angnostic by default and should use this effectively. A service boundary starts from the service contract, all communication agreements should should be based on contract.
- Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomous, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services. Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomy, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services.
- Shared Contract: Service clients talk to services using a published contract. The contract is an interface where service clients communicate with the service. The service client is not required to know the intricacies of the service because the contract sits between the client and the service. Most dependencies are on the contract and not the actual implementations of the service.
To be continued ...
