Nowadays the term service is in every modern acronym (SOA, SAAS, SLA, etc.), and there is non clarification on what is a service and how it differentiate from old fashioned terms like Components.

The term Components come from the manufacture’s industry where all those modules are used to build things. It doesn’t matter if a car engine is manufactured by Ford or by Subaru, it is produced reusing some of the same components and it is not implemented from the scratch.
During the last years, the Information Technology approach has been to watch other industries and to try to implement all that has succeeded into software. Like in the manufacture, software components are a unit of software that provides business or technical functionality.
Typically they’re self-contained and independently deployable. Thinking about a software component we’re used to think to:

• a specification (analysis and design) that defines the scope of the component;
• an implementation with any invokable interfaces;
• a module to be deployed (an EJB, a WAR, an EAR, a DLL, etc.).

A component offers its implementation through an interface, that’s the unique way a component should be used.

Differently services are focused on satisfying business needs, on a consumer/producer paradigm where the service is producing something valuable for the business. A service can be thought as a set of components and differently from components. A service can be something else than a component. Instead of having an interface service allow the concept of API on different protocol and they can act synchronously or as event’s agents.

Another big difference between Services and Components is the way they’re reused. Going back to manufacture Components is stored on the shelf and is taken and deployed when necessarily.

Service, in an opposite direction, lives somewhere and is addressed to be used.
It’s like going to the post office to send something instead of creating a post office in house.

An approach with components requires a new deployment, new hardware dimensioning and integration while a service approach is only focusing on integration.

What is making the difference?

The way the architectures are thought is making the difference, thinking SOA is benefiting the reuse of value added services and is accelerating the way software is implemented. Every architect is implementing a system, should think a way to make the application addressable and callable by other Service around the network promoting Service Reusability. In terms of business, Service reusability creates a new approach of doing business where specialized companies are providing something that produces real value as a service and is offering a large scale the service at a low price. Google, or salesforce.com or Amazon is again an example of the power of thinking SOA.