This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Services and Components

Stefan Tilkov,

Jim Webber thinks that the major difference between components and services is that communication with a service is stateless. I disagree — that would turn components where communication is stateless into services automatically as well, right? I believe there is a number of issues that separate the two concepts, but if I were forced to narrow it down to just one, I would say that a component has a contract not only with the outside world, but also with the component platform into which it is deployed. A service knows no such thing.

On July 16, 2004 1:49 AM, Jim Webber said:

Hey Stefan, I know my services are stateless components might seem crude, but if you have a stateless (as in the Web architecture definition) then it is actually a service. If it helps, you can just call it a stateless component, but service works just as well. Web Services have a contract with the platform into which they are deployed too, of course! Jim

On July 16, 2004 8:05 AM, Stefan Tilkov said:

Of course it’s all just a game with names, so you can call anything a service, much as the term component is so generic that you can apply it to almost everything. And I disagree that a Web service has a contract with a platform — it’s the Web service implementation, which may take the form of a component, that has this contract.

Say you install some sort of gateway that will expose some of your application interfaces via SOAP, document-oriented, coarse-grained and everything - you’ll end up with a service, right? Nobody can tell that it’s not being implemented from scratch.

Would the same be true for a component? No, because I can’t take the component (implementation and all) and deploy it to my runtime instead of yours.