Services ad nauseam*

I just read Shy Cohen's (via Nick Malik) article in Microsoft's Architecture Journal entitled Ontology and Taxonomy of Services in a Service-Oriented Architecture.

Shy provides a list of what he calls "service types". He identifies two major types bus services and application. He then continues to sub-divide them, the bus services are divided into communication and utility services, and the application services are divided into entity, capability, activity, and process services.
I have to say it was quite alarming to see this coming from someone who had deep involvement in defining Windows Communication Foundation Indigo.

Where do I start?

Well, for one, the article completely fails to make the distinction between services as in "Service-Oriented Architecture" and services as in "capabilities or features an infrastructure provide". The "communication services" are for the most part capabilities that a service infrastructure (such as an ESB) provides. Not services you would define in an SOA initiative

And then there's the matter of service granularity and the difference between remote objects and SOA. For instance, the example Shy gives for a "method" (his word) on a customer service (entity service):

An example of a domain-specific operation is a customers service that exposes a method called FindCustomerByLocation that can locate a customer's ID given the customer's address.

Why would a service return a customer ID? This is the kind of call you would make on an object you hold a reference to not some remote "Something" that also want to authorize your call and may reside in a different company. This kind of thinking is what made remote objects fail. Gregor Hohpe explained that nicely in a paper called Developing software in a Service Oriented World:

The Transparency Illusion. Distributed components promised to hide remote communication from the developer by making the remoteness "transparent". While the basic syntactic interaction between remote components can be wrapped inside a proxy object, it turned out that dealing with partial failures, latency, and remote exceptions could not be hidden from the developer. It turned out that 90% transparency was actually worse than no transparency because it gave developers a false sense of comfort.

As an aside, Gregor recently gave a presentation that covers this paper at JavaZone which you can watch online at InfoQ .

Returning to Shy's article, let's take a look at another quote:

Capability Service may flow an atomic transaction in which it is included to the Entity Services that it uses. Capability Services are also used to implement a Reservation Pattern over Entity Services that do not support that pattern, and to a much lesser extent over other Capability Services that do not support that pattern.

I already explained why cross-service transactions and especially flowing transactions is not a good idea in SOA so I won't do it again here -- but you can read about it both here ("Transactions between Services? No, No, No!") and here ("Cross-Service Transactions").

Also I hope Shy didn't mean .NET data sets when he said "In some cases, typically for convenience reasons, Entity Service implementers choose to expose the underlying data as data sets rather than strongly-schematized XML data. Even though data sets are not entities in the strict sense, those services are still considered Entity Services for classification purposes."

In any event the whole decomposition of services into fine grained "capability", "activity", and "process" takes no account of the fact the SOA is a distributed architecture...maybe Microsoft is not affected by the Fallacies of Distributed Computing ?

Posted by Arnon Rotem-Gal-Oz at 06:03 PM  Permalink