The classic view of the difference between objects, components and services is laid out with admirable clarity in an ACM Queue article this month by Roger Sessions of Objectwatch: Fuzzy Boundaries: Objects, Components, and Web Services. Anyone who's curious about the differences and why they matter will learn a lot from reading this, even if they've never written any program code in their life, nor ever intend to.
Roger explains that development tools make it easy to transform an object with a few "tweaks and toggles" into either a component or a web service. But maybe they make it too easy, he warns: "The compiler vendors have given us the power of transformation, but no instruction as to when and how to use this power."
He goes on to provide the classic recipe for when each of these three forms of encapsulation should and shouldn't be used:
"When we are not constrained by needing multiple environments, components are more efficient than Web services. When we are not constrained by needing multiple processes, objects are more efficient than either components or Web services. Web services are the least efficient of all of these systems, unless we are working under constraints that prohibit the use of either objects or components."
He goes on to map out a pyramid to demonstrate the inevitability that objects will always be more numerous than components, and that there will always be fewer services than components. This view of the world is obvious to any classically trained application developer. Like all engineers, developers hate inefficiency. Working within the closed system of the application they can maximize performance by designing tight integration between hundreds of finely grained objects. It's only when they come to link the completed system to other applications that they reluctantly relax their tight grip on internal performance.
I emphasize that this is the classic view. Most developers think like this. But it's not necessarily correct. It's the prevailing wisdom because it reflects the application-centric way in which most systems have been built to date. But other ways of building systems are gaining ground, in particular service oriented architectures. In such systems, it is not the case that, as Roger asserts, "a typical system has relatively few cross-system connection points." On the contrary, an SOA is made up entirely of cross-system connection points they're the reason for building one.
Let's look, then, at an extreme example in order to illustrate a completely opposite case to the classical view Roger has outlined. Imagine an enterprise that has no internal systems whatever, except for browser-equipped PCs on workers' desks. It fulfils all its computing needs by accessing services from third-party providers, much of it from salesforce.com and the other hosted application providers in its On-Demand Marketplace, with integration provided by a combination of Grand Central's Business Services Network and Amazon Simple Queue Service. Here is a theoretical system where every element (including the middleware) is a service. There are no components, there are no objects.
Of course, the components and objects are still there, hidden away behind the providers' service interfaces. Or are they? As a service consumer, I don't really care. So long as the service delivers as required, for all I care the inner workings can be down to serried ranks of hamsters on treadmills (subject to proper animal welfare practices, of course). Joking apart, maybe those providers find it more efficient to serve their customers by building their systems out of yet more services some of them from other providers.
Even those Windows PCs on the organization's desks have a service-oriented future ahead of them. Indigo, the web services-based communications subsystem under development for the next release of Windows, will allow developers to link services into Windows. A demonstration at last year's Professional Developers Conference (PDC) showed a web service adding functions to the Windows taskbar. Surely it would be more efficient to build that using objects? Yes, but then you'd have to wait for Microsoft to build it for you. Using a standards-based service interface gives you the flexibility of doing it yourself using the ubiquitous capabilities of SOAP and WSDL. While that may make the system marginally less efficient, it has the potential to make you the user significantly more productive. Which, after all, is the ultimate purpose of building all these computer systems in the first place.
The image I have in mind, then, for the relative distribution of objects, components and services is an hourglass. Sure, there are a lot of objects out there, but I think that as service oriented architectures roll out along with increasing numbers of on-demand services the number of services used in a typical enterprise architecture is going to expand dramatically, and could one day equal the number of objects hidden away inside the individual service mechanisms.