I’m a bit of a sceptic when it comes to REST and the SOAP vs REST “debate”. There seems to be a tinge of hatred of corporate IT and dogmatic promotion of niche programming languages. There has been quite a lot of REST-o-ranting on the topic and I am not going to go there now.

REST does interest me in the influence it has on service design; indeed I have been a little worried that a lot of alleged SOA is not as loosely coupled as the philosophers would like and that, even when using document-style (rather than rpc style) SOAP, it is too easy to be led astray into, for example: OO thinking, CRUD. REST is both attractive in lending itself to loose coupling and unattractive in drawing one towards class-oriented design rather than business process oriented design so I thought I would have an attempt at a REST approach to IMS Enterprise Services v1. Scott Wilson had a look at a “REST-style” approach to IMS Enterprise Services some time ago but this isn’t in the same style that I look at, which I think is more fundamentalist resource-centric. I don’t think either of us is actually saying that real implementations of IMS Enterprise would never want to use the WS-* stack; it offers a heap of valuable heavy-weight capabilities.

My first cut is available in PDF:

I have often observed chaotic meetings or been frustrated by group discussions that seem to lose the plot. I had never really thought about why this happens other than to complain under my breath about a weak chairperson or facilitator or to mutter “stick to the point” now and then. Now, at least, I have found a partial explanation: Christopher Allen has an interesting article, “The Dunbar Number as a Limit to Group Sizes” where he provides some evidence and relates to more fundamental anthopological research.