Services… are they the evolution of components? And… “stateless” vs “stateful” again.

In a previous post I mentioned Jim‘s thoughts on the transition from objects, to components, and now services. His post generated some interesting comments and an entry in Stefan‘s blog. Stefan wrote that

…a component has a contract not only with the outside world, but also with the component platform into which it is deployed…

which is very interesting indeed. But couldn’t we say that services have a similar property too? Couldn’t we suggest that the contract for message interactions a service publishes could be used by consumers to create component-proxies that are appropriate for their own component platform? Hence, services have all the properties of traditional components but can also be (virtually) hosted on any component platform. Me thinking aloud here 🙂

Also the discussion touched on the terminology used by Jim who suggested that “services are stateless”. Jim explained that services are stateless as far as their consumers are concerned and that there is no suggestion that they are not allowed to maintain state for their intra-workings. Jim and I agree on what “stateless service” means in architectural terms but, unfortunately, some take this to mean that services are like functions in a functional programming environment and are not allowed to maintain state. Of course, this is far from what we mean.

As a result, I have stopped using the term “stateless service”. Instead, in my talks I talk about “stateless” and “stateful interactions”. People seem to understand this better. Services are, of course, allowed to have state (e.g., Google… lots of state behind the service boundary). Each message is supposed to carry enough information for the receiving service to reason about the interaction.