Juval Löwy describes the four tenets of service-oriented architectures in his wonderful book Programming WCF Services:
- Service boundaries are explicit
- Services are autonomous
- Services share operational contracts and data schema, not type-and technology-specific metadata
- Services are compatible based on policy
By building upon these pillars, engineers insure that the architectures that they define are service-oriented. These guidelines help insure that the components within a system are loosely coupled – a key requirements of a SOA.
The importance of reduced coupling isn’t new or SOA-specific. I remember being taught in college to strive to lower coupling irrespective of the architectural pattern being applied; however, I don’t recall being given any practical advice on how to achieve this or any metrics to measure it.
In fact, I’ve heard it said that coupling can’t be quantified; I disagree, however. If you count the number of distinct service operations which a client invokes, you can determine how tightly it’s bound to that service. Swapping it out would require a new one to supports at least the same functionality. If you don’t own all of the clients, you can’t make this determination, however, and must assume that all of the operations are in use.
For this reason, it is advisable to:
- limit the number of operations exposed by a service (Löwy suggests no more than 20);
- not define two methods if one will suffice (i.e., avoid convenience functions); and
- if the arguments of an operation are likely to change and are numerous, bundle them together in a structure and pass this to the operation.
For other pointers, see John Evdemon’s blog as well as David Orchard’s. After reading those, check out the other suggestions that Löwy has in Appendix C of his book Programming WCF Services. I also suggest browsing through Milind Shingade's article where he defines different types of coupling.