[T]he notion of context independence is the very definition and necessary condition for loose coupling, separating services from components.
I beg to differ. I recently witnessed an SOA presentation by a smart architect, and it was very obvious that you just as well might have replaced the term “service” with “component” without anybody noticing at all. If something like this is possible, it clearly shows that a clear definition of the distinction — provided there is one — is needed. So I offer one we came up with inside my company after a lot of heated discussion:
The major factor that separates a component from a service is that a component is re-used by deploying it into a component runtime, while a service is always used remotely.
Stephan:
It is like saying, I cannot have an OO approach with a procedural language like C and vice versa. Of course I can, I can pass a handle to a data structure for every function, once I enter the function, I initialize the context of execution of that function with the data structure pointed to by the handle.
OO relies on a small set of concepts.
Unfortunately, we don’t have this luxury for services.
Properties I found different: 1) components are extensible but services are composable 2) components can be stateless or stateful, services too, but in addition, you really want to design services in ways that are independent of their context of utilization, just like when you send a letter, the post office has no idea whether it is a PO, an invoice, a check, or a document, … How complex things would be if the price of shipping letters was dependent on its content !!
JJ-