Service Reuse

Reuse is a topic which confuses a lot of people. Main reason for confusion is inability to understand the difference between component-based and service-oriented architectures. These have fundamentally different ways of reuse.

In component-based architecture, the idea is writing components with generic interfaces which can be used in different scenarios. So instead of implementing functions over and over, create a generic/abstract interface and reuse the function in different places. This works in different levels such as simple libraries (log4j, log4net, spring, etc), it works in large frameworks (drools, jpmn, workflow foundation, wcf, lucene, etc.) and also in infrastructure level (database servers, distributed caches etc). The idea is all same: generic stable interface, high configurability. Although this approach works very well with infrastructural components (doesn’t deliver business value directly), unfortunately, experience of the industry shows that it doesn’t work well with implementation of business processes (usually called as “business logic” in the language of this architecture style).

In service oriented architecture, reuse has a completely different meaning. Reuse of services is about existing consumers using newer version of the service. Reuse of services is “forwards” (existing consumers using new service versions) not “backwards” (new consumers using existing services). It’s not about how to implement generic services which doesn’t need to change for new consumers, it’s about how to implement services which can be extended without disturbing (upgrading) existing consumers. Therefore service compatibility and contract versioning are key concepts in service oriented architecture.

A weak understanding of services ends up with, for example, efforts to define generic service contracts. Because it’s practically not possible to know the unknown these efforts are just wasted. Usually this becomes guess-work, future-predicting. David Chappell says “Creating services that can be reused requires predicting the future…” and concludes that SOA doesn’t work. It’s very clear that he doesn’t understand the concepts of service-orientation. Similarly when Juval Lowy is excited about the capabilities of WCF and advertises the concepts “every object as a service”, same mindset presents itself. It’s not difficult to guess why WCF still doesn’t have contract-first web service development.

I noticed an InfoQ presentation “Expressing Service Capabilities Uniformly” which explains reusability as “multiple services implements same contract”. Funny that change of service contract is stated as a problem, and in the “cons” list you can find the difficulty of  change management. Of course, he doesn’t mention a word about versioning or compatibility. With his architecture style business process is reduced to “moving data from service to service” and REST is the savior. Same story over and over again…

Long story short, there are lot’s of people around who doesn’t understand service-orientation but claim it doesn’t work. Reuse is just one example. More to come…