SOA: September 2007 Archives

Juval Löwy describes the four tenets of service-oriented architectures in his wonderful book Programming WCF Services: 

1. Service boundaries are explicit
2. Services are autonomous
3. Services share operational contracts and data schema, not type-and technology-specific metadata
4. 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:

1. limit the number of operations exposed by a service (Löwy suggests no more than 20);
2. not define two methods if one will suffice (i.e., avoid convenience functions); and
3. 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.

As Rozanski and Woods state in their book Software Systems Architecture, every problem has many candidate architectures.  So, what makes one service-oriented and not another?  Weerawarana et. al. outline the qualities of a SOA in their book Web Services Platform Architecture.  They say that a SOA is one that meets the following requirements:

• It is composed of loosely coupled services.
• The interface of these services is defined in a programming-language- and platform-agnostic manner.
• It furnishes service providers with a means to publish their functionality.
• It provides consumers with a way to find published services that meet their needs and allows them to bind to these services dynamically.
• The above requires are governed by standards that are not implementation specific (i.e., language- and framework-neutral).

Using this definition, are the following SOAs: DCOM, CORBA, Web services, WCF, JWS?  Though many will say that they are, doing so is like saying that metal is a car.  You use raw materials, like metal, to make cars, but no one would conflate them.  Likewise, these technologies can be used to create Service-Oriented Architectures, but they aren’t architectures at all.  Brenda Michelson, Program Director of the SOA Consortium, stated in the SOA Consortium’s blog that "SOA is not about the underlying technology, but about 'enabling organizations to create, and adapt to, change.'"  Likewise, Richard Soley has respectfully rejected Jan Pokin’s definition that "SOA is a technology;" he says that "SOA is an enterprise strategy based on an architectural principle."

Businesses and architects would be wise to guard against the trap of equating SOAs with the technologies used to build them.  If ensnared by this wile, they’ll build systems that are in the same predicaments as the ones they're phasing out. Companies will site their use of WCF, JWS, etc. (which were sold to them as the pathway out of entanglement) and fail to understand why their systems are still tightly knit together, costly to update, and unable to adapt in time to profit from ever-changing market trends.