My Life As A Blog

MEST Practice

with 2 comments

Via this post on Stefan Tilkov’s blog, I found an interview that Stefan did with Jim Webber about SOA and MEST – a message-centric approach to SOA.  You can watch it here.  I don’t often watch this sort of thing, because I prefer to read the transcripts – in addition to being able to read faster than anyone I have met or seen can talk, I can read the interview in a way that suits me (e.g. going back and re-reading an answer.)  However, I made an exception in this case, and I’m glad I did.  One interesting observation made by Jim Webber, which rings true, is that relying or being dependent on a big SOA platform increases coupling – with the resultant increase in inertia.  I like the idea of the “letterbox” being the service interface – the letters being messages that are defined by a schema or equivalent in a transport-agnostic way.  What is left unanswered in this interview is what to do when you need a near-realtime response (e.g. a query.)  It is very easy in these instances to adopt an RPC style, which is a style you should be avoiding in building an SOA.  At the moment, I tend to favour forward caches in these instances (i.e. the system of record uses a pub-sub paradigm to disseminate its data.)  While this simplifies the message definitions and allows a lot more flexibility in how to use the data, it does have the disadvantage, of course, of a proliferation of data.


Written by remark

September 2, 2007 at 2:56 pm

2 Responses

Subscribe to comments with RSS.

  1. Neither pub/sub nor transport-correlated messaging (aka RPC) necessarily support (near) real-time responses alone – the abstractions always leak if you push them hard enough.

    If you design your services with the notion of temporal decoupling in mind then you can achieve this (or at least know for sure when you haven’t), but transport-level patterns can’t help here either.

    Whether my service receives a message because of a subscription it place, or whether it receives a message because of some other condition (e.g. a correlated response to an earlier request) is unimportant – my service will have to take timing into account anyway. For instance my service may well not act on a stock quote which is 3 hours old, but it might act on a fire alarm that is 10 seconds old.


    Jim Webber

    September 3, 2007 at 9:16 am

  2. Jim,

    Thanks for adding your thoughts. It seems to me that the simplest approach to temporal decoupling is for the message to include timing information (e.g. when the message was created, the period for which the message is valid, the period within which a response is expected, etc.) In this way the service receiving the message can make sensible judgements. WS-CDL has some timing elements – but any standard whose first three characters are WS- tends to make me a little apprehensive.


    September 3, 2007 at 10:59 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: