The January 2005 issue of ACM Queue contains and article by Roger Sessions called Fuzzy Boundaries that does a good job of discussing the differences between objects, components, and services and when to use each. This is a difference that's hard for students to grasp at first and I suspect many a veteran programmer would have a tough time explaining it, even though they understand it intuitively.

To start with, we have to acknowledge that each of these has the same abstract purpose: stick some code behind a well-defined API and are designed to respond to requests from a client.

Sessions differentiates them by referring to process and environment. For objects for the object and it's client live in the same process and the same environment. For components, the client and target exist in separate environments, but the same process. Sessions defines an environment as a component framework like EJBs or Corba. Services don't share either processes or environments.

Sessions used the following table to clarify the differences. Builder relationship and quantity are interesting. Builder relationship specifies the relationship between the builders of the target and the client. Quantity is a relative measure of how prevalent these various forms will be in any given system. Because services are meant for top-level APIs between organizations, they will be relatively few.

The important point is that objects, components, and services aren't mutually exclusive. Rather, each has it's place and a complex system will probably have some of each in the proper proportions.

Sessions finishes the article by describing the "software fortress" model of architecture that he put together for his book by the same name. This model is all about defining boundaries and creating a framework for proper analysis. The book's out of print, but available used from Amazon. I've ordered a copy.