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.
Comments
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.
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