savas parastatidis

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.

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

  1. Stelios G. Sfakianakis
    Hi Savas (‘Gia xara!’) If you have a web service for an online store and you have a series of interactions for buying goods, you have the need for storing what is the current order i.e. the contents of the ‘shopping cart’. In such a case you definitely need a statefull implementation to support these scenarios but also a contract (WSDL, WS-RF, WS-Context,…) between clients and service that carries either explicitly or implicitly all the context i.e. the previously chosen items. You also seem to accept this as you say “Each message is supposed to carry enough information for the receiving service to reason about the interaction.”. But I fail to see if in this case we have a service that is “stateless as far as its consumers are concerned” since some kind of information (e.g. session id) should be transerred to the client so that it is included in its following calls. And this implicit (or explicit) argument in service calls makes the difference between (OO) components and WS even smaller since from what I have learned from my OO programming days “o->f(a)” is equivalent to “f(o, a)” 😀 Thanks, Stelios
  2. Savas Parastatidis
    Hey Stelios (“geia sou”:-). You make an excellent point. Indeed, in the single service case and in situations where you reason about a single “shopping cart” the two approaches may appear to be equivalent in architectural terms. In reality, in WS the message-oriented approach seems to be more flexible. For example (excuse my use of the method call notation which has no place in service-orientation :-), let’s say that you had a counter object and you could call getValue() on it: counter->getValue(). With messages you would do, as you suggested, getValue(counter) and the two would seem equivalent. Now, with a message you could also do, getValue(counter1, counter2, counter3, …) which is more flexible. Furthermore, counter1, counter2, etc. could be just logical names and not tighted to a particular distributed object-based technology (i.e., they are not network-wide pointers, like CORBA IORs). Of course you could have an “object” that would offer similar functionality but then again you’d be doing service-orientation using OO technologies (in a similar manner to CORBA services). Now, where things get more interesting is the distributed activities case. If you had a shopping cart and you wanted to visit many stores but only pay once, you only want to carry one cart with you. The context of your interactions is defined by the cart. That context needs to be carried with every message sent to any of the shops. What the shops do with regards to that context is up to them of course. I hope I haven’t confused the situation even further 🙂
  3. Stelios G. Sfakianakis
    Thanks for the reply, Sava, I think it clears things a bit. You seem to argue for the *inclusion* of any state in the messages exchanged (note that I say messages not function calls 🙂 : in the “distributed activities” case this state is explicitly transferred, assuming the participating shops do not share data. That is of course inline with the “services are stateless as far as their consumers are concerned” stmt. But are you against the “implied resource pattern” of WS-RF as a method of communicating state? Maybe (answering my own question) this pattern violates the view of a service as “stateless”? thanks, Stelios
  4. Savas Parastatidis
    Hey Stelios, yes, I am very against WS-RF’s attempt to explicitly model state beyond a service’s boundary. Jim and I have been arguing against WS-RF’s model for months now. The main problems I see with WS-RF is the way WS-Addressing is used as effectively a network-wide pointer, the lifetime related operations, the distinction between messages as results to “operations” and messages as results to resource properties requests (a la methods and properties in Java). The WS-RF model effectively builds a resource-oriented view of the world using SOAP. Services are treated as the interfaces to resources. Resources become the logical recipients of messages in exactly the same way objects are the targets of method invocations. I believe that in service-orientation we only have services and messages. Resources may exist but we don’t model them explicitly, we don’t make them part of the architecture.
  5. Stefan Tilkov
    Hi Savas, I would argue that the fact that you can generate proxies that are deployed into a platform doesn’t say anything about the service. Then again, I think you’d agree 🙂
  6. Savas Parastatidis
    Hey Stefan. I totally agree. Nothing is said about the functionality of the service. We need semantic descriptions for that. However, what we can say about the service, based on the metadata we have about it (message descriptions, policies, etc.) is what are the characteristics that a container can/should support (e.g., security, message delivery reliability, message compression, transactions, etc.). Now, as components have these characteristics for free when deployed into their containers, now services define what characteristics they support or require and they can be “deployed” (their proxies can) in any container out there.