I was discussing component architectures, and in particular things like EJBs and MTS (remember that?), with a colleague earlier today. The question of statelessness came up, and it occurred to me that it was, all things considered, rather odd to be using objects - part of the point of which is to encapsulate local state - as the main abstraction for defining stateless, pooled, container-managed and declaratively configured services.

So, what would make a better alternative? Well, from the point of view of the component manager/configurator, open data structures are less hassle to deal with than encapsulated ones - a lot of the work the container needs to do involves simple getting and setting of properties, reading off a component’s declared “profile” and making modifications to it. EJBs make rather heavy weather of this - what’s needed is probably a lot more like a function from one profile to another than a class bristling with getters and setters that do nothing more sophisticated than mutate internal fields. Score one for a pure functional approach. And then there’s the question of statelessness: a service component should obtain at the point of invocation all the state it requires to process a request, effect any side-effects it needs to effect, persist any updates to the appropriate location, and then promptly forget the whole thing ever happened. It should look, in other words, more like a value in Haskell’s IO monad than a widget with a bunch of knobs and dials and blinkenlights that holds secret grudges between one invocation and the next.

It seems to me that pure functional programming may be a better fit for a service component architecture than OOP. Perhaps Haskell has a good story to tell in this area - why not define services as arrows?