Tenets of good SOA programming

Today's post is a follow up to my post on complexity being a math problem. SOA programming just like Object Oriented programming has a select set of steps and principles that need to be followed in order to ensure the most effective use of these technologies.

Most programmers can spit out the rules of good Object Oriented design in their sleep. These same principles are very similar in my opinion to the tenets for good SOA design. OO Tenets are Abstraction, Encapsulation, Inheritance and Polymorphism.

• Abstraction means ignoring irrelevant features, properties, or functions and emphasizing the relevant ones… relevant to the given project. This also covers Data abstraction simplifying.
• Encapsulation means that all data members (fields) of a class are declared private. Local use methods may be private too. The class interacts with other classes (called the clients of this class) only through the class’s constructors and public methods.
• Inheritance states that a class can extend another class, inheriting all its data members and methods while redefining some of them and/or adding its own. Inheritance represents the is a relationship between data types. (e.g. a FemaleDancer is a Dancer)
• Polymorphism ensures that the appropriate method is called for an object of a specific type when the object is disguised as a more general type. (e.g. Square being used like a shape)

To keep things simple and play off the magic number of four tenets these are

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Compatibility is based upon policy

Boundaries Are Explicit basically means that a caller of a service need only (and for that matter, should only) understand the interface to a service. It does not need to know what is going on behind the scenes nor should it care. This enables the implementation to evolve over time without requiring changes in its consumers. This abstracts complexity and is core to making SOA work.

Services are Autonomous is setting up services so that they are independent and able to function on their own. While a set of services becomes part of an orchestrated whole and thus build a system they should be designed in such as way as to be as self governing as possible.

Services Share Schema and Contract, Not Class accessing systems should care about the data and schema that are received and the data that is required for a service to be used. This should be viewed as a contractual interface between the caller and the service. Callers should not expect a Class file from that service as services are about data and schema not specific implementations. When integrating systems and performing remote calls the expectation and integration at the class level is fine, but it is not a service.

Compatibility is Based on Policy means that functional compatibility needs to be managed. Versioning of services and ensuring that they are backwards and forwards compatible is a wonderful goal but may not be fully achievable. This needs to be accepted and managed through policy.

Looks like there is ample ground for posts on this topic. What do you think? Do these Tenets make sense? Should there be others?