A Service is Not an Object or Component

Continuing on the SOA front, I've recently been reading a version of the forthcoming book "Programming WCF Services" by Juval Lowy.  While a great book on WCF internals, I was thunderstruck by Juval's assertion that (services are the) "next evolutionary step in the long journey from functions to objects to components to services".  I so strongly disagreed, that I left some notes to that effect in the notes to him and the publisher.

As described, Juval sees an application as being made up (entirely) of services and I can see his reasoning.  You see Juval advocates interface based development which he claims (others would attribute another definition) is "component-oriented programming".  To him a "component" is an object that exposes an interface - one interacts with it through the "contract" exposed by that interface.  Its a case of turning the advice "program to an interface not an implementation" into an edict.  So in his previous book "Programming .NET Components" he sees an application as being composed of "components".

Now one interacts with a service (in WCF) via a "contract".  And his extrapolation is therefore that a service is really a type of component - is a type of object.  Which is where his statement (the) "next evolutionary step in the long journey from functions to objects to components to services" comes from.

How would I explain the relationship between an "application" and a "service"?

A single application can exist either within a single context of execution within a platform (typically a Process but in .NET could be AppDomain), or it can be distributed over multiple contexts of execution. Within any context of execution, the world will continue to use object oriented development to model the complexity of the domain and supporting infrastructure.  

But the parts of the application that are spread over different contexts of execution need to communicate with each other.  That can be extended outside an application also to communication between applications.  One can use any of the standard mechanisms of integration architecture :- file sharing, shared database, remote procedure invocation, messaging or just walk a floppy between them.

While Remote Procedure Invocation was formerly "de rigeur", messaging between "islands of functionality" or "Services" using industry standards has become the fashionable standard mechanism for communication between those "contexts of execution".

1 Comment

  • "next evolutionary step in the long journey from functions to objects to components to services " and back to functions.

    On the floor, it sure seems to me that this should be a self closing loop; calling services still feels like no more than remote function calls.

    I like the concept of execution context, I think that it could also be defined by the ability to fully retain the behaviors of the OO model.

Comments have been disabled for this content.