• Set of classes work together to provide a unit of functionality (e.g. log4j)
• A Component can be distributed and used by other systems (e.g. EJB components)
• A component works like a black box so long as the client and the component adhere to the interface, the client doesn’t have to worry about the implementation details even if it changes over time

Wait a minute! Isn’t this how services behave too? Yes. And that’s why the conceptual difference is important. Designing a system as a set of components and converting them into services when needed is a short sited approach. Services should be thought of as implementation of business activities. In real world, given set of activities performed in a particular sequence forms a business process. Technologically, this should be accomplished by invoking a set of services and components should be used to implement these services.

It is important to keep in mind the following points about services and components:

• Functionality provided by components is finer than that provided by services e.g. logging as a component versus credit card validation as a service
• Components encapsulate business entities and rules governing their interaction. For example, a purchase order component will have business entities such as purchase order, item list, item etc. On the other hand, services represent activities in a business process e.g. receive an order (or even coarser, process order)
• Logically, a component implementing a piece of functionality is distributed and deployed to the client applications whereas in a service oriented architecture, clients that need to use the service need to bind to the service and invoke it (in other words, clients need to go to the service)