MGB 2004: The four tenets of service orientation and other thougths on SOA - part 1
I am at the Microsoft General Briefing (MGB) in Atlanta, an intenal conference for Microsoft Field employees. The two days before the conference started we had an Architecture Training in Atlanta, very good, learned a lot in two days, and I got to eat dinner with Pat Helland ;-)
In the training I joined a very interesting (chalk) talk by Mike Burner, which discussed Microsoft position around SOA, and SOA generally. In the discussion there was raised the questions whether Don's four tenets of service orientation actually are correct. The four tenets are:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Compability is based upon policy
Tenet 1 and 3 are no problem. One of the good things with service orientation is that it becoumes explicit to the developers (service consumers) that there are some cost associated with the use of a service.
The interesting discussion is around #2 and #4. Are services really autonomous? How about infrastructure services like authentication and authorization? Would you expect every service to implement their own security, or rely on common security services to provide the necessary implementation. How about logging and auditing? In many of the recent presentations and discussion I have been to on SOA, one starts to categorize services into Process, Activity, Entity and Infrastructure. For activity and process services (if you forget about their dependence on infrastructure services) I can see the concept of them being autonomous, but for entity services? As entity services is described as wrappers for CRUD-operations, they will likely not reflect the business rules of the system/applications they are a part of, and subsequently not be autonomous.
This brings up another question on SOA, in my view. When discussing SOA, service orientation is motivated from the alignment of business and IT. Ie services are coarse grained operations that reflect business use cases, and they are implemented using (asyncronous) messaging, for example using web services. But, with the introduction of entity services, we break with the concept of business and it alignment, and are more focused around the technical aspects or definition of a service. A service is defined by its technical "signature" (message-based), and not by its functional or architectural role. I dislike the latter definition, as this is more of a implementation detail than leveraging functionality (services) within an architecture.