Alex Hoffman

Perspective on development, management and technology

Syndication

News

    Subscribe

    IASA Member

October 2006 - Posts

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".

Posted Wednesday, October 4, 2006 4:05 PM by Alex Hoffman | 1 comment(s)

Filed under: ,

More Posts