savas parastatidis

The MEST saga continues 🙂

In his comment to my “Explaining MEST” post Brian Glaser supported pub/sub systems in favour of MEST. Chris Ferris does the same in his “MEST-Up” 🙂 post and promotes such an event-based architecture for implementing loosely-coupled systems.

As Jacek correctly points out, pub/sub is a particular pattern that needs to be implemented somehow. MEST defines the building blocks that enable pub/sub, request-response, complex interaction patterns, etc. to be implemented. MEST just captures the principle of message transfer (amongst other things) as a mechanism for building distributed applications. Object-orientation has the method invocation abstraction, RPC has the remote call abstraction, MEST has the message transfer (without a suggestion that this is a big revelation or something new).

MEST also talks about other architectural things as well. It’s just that Jim and I haven’t written about those yet in our blogs. Think of how REST captures the architectural principles of resource-orientation. It’s not that REST invented resource-orientation or that people weren’t building resource-oriented applications beforehand. MEST attempts to describe service-orientation in similar terms without a suggestion that it invents services, messages, message-orientation, etc.

Pub/sub systems are great for loose-coupling but they require additional semantics that are not part of MEST. For example, the state associated with a subscription (i.e. the information about where to send the message when we are not talking about broadcast/multicast events).

BTW… I think Chris will like some tooling that we have created that provides a different programming model to deal with SOAP messages; rather than exposing a method abstraction from processing a contract, a series of events are made available (e.g. PurchaseOrderArrived).

Only few days away 🙂

5 responses to “The MEST saga continues :-)”

  1. Brian Glaser
    Savas, I understand what you’re trying to say, it’s just that I don’t think we need to reinvent a paradigm that’s already more than capable of being applied to SOA. Alright, you say that ProcessMessage can layer underneath pub-sub, but so what? What does it add that pub-sub doesn’t? It just seems to be adding another layer into the picture when one simply isn’t needed. It doesn’t add anything that I can’t reason about better with a pub-sub model (and pub-sub says nothing about communications layer either). In some ways, it could be argued that pub-sub is the unifying principle for all distributed middleware. In which case, shouldn’t ProcessMessage layer on pub-sub?
  2. Malik Abdul
    Is it just me, or doesn’t it seem that Notify is an even more fundamental architectural principle than ProcessMessage (aka HereHaveAMessage)?
  3. Savas Parastatidis
    Brian, Malik, I disagree that pub-sub provides us with a unifying model for describing service-oriented applications. While it’s a good way to build loosely-coupled applications around the concept of events, it’s not applicable to all situations. Pub-sub makes the extra assumptions about subscription management capabilities that MEST doesn’t make. In the cases where we are not talking about broadcast of messages, one has to subscribe to an event and that information has to be managed/maintained. That’s an assumption that is introduced in the architecture that doesn’t exist in MEST. You’d probably use the simplicity of MEST to build such semantics. Also, how do you model the semantics of that initial message that registers your interest with an event? Another example is the ability to describe complicated protocols. You’d have to go to extra lenghts to describe something like a transactional protocol only with pub/sub. You can do it but you’ll have to do more than if you only reasoned about one-way messages (no subscriptions). I am not against pub-sub but I think you are comparing different things when you are comparing it against MEST.
  4. Brian Glaser
    Savas, it’s a conceptual thing. The sub is a service registering interest to the network for messages. The pub is a service pushing a message onto the network. These are *all* messages (it’s not pub-sub for a specific topic, unless you want to think of the topic as EveryMessage). Event oriented architectures are at the heart of every system you can think of, whether it’s distributed or not. You only have to look within the hardware of the machine you’re currently using to see that it’s not just a software thing either. In fact, pub-sub works in hardware too. Broadcasting of messages or unicasting isn’t tackled any differently in pub-sub than in MEST as far as I can tell from an architectural perspective. As to this “initial message” question, how’s it done in MEST? How does a client determine where it needs to perform (sorry, not the right term I know) ProcessMessage in the first place? Remember, this is all archiectural – it’s not implementation. So, from a conceptual perspective, all services are inherently sub-ed to the network. Your statement about transaction protocols and pub/sub is wrong. Last time I used MQSeries, transactional JMS and some proprietary equivalents was about 5 years ago and it was all present there in a fairly natural manner, modeled on one-way messages. Don’t get me wrong: I agree with the core of what you’re saying – keep everything loosely coupled and reason about things in terms of messages. I just think you’re going about it the wrong way. Don’t introduce some “new” paradigm when one isn’t needed. Evangelize one that’s already there and understood.
  5. Malik Abdul
    Phew, I didn’t think this was going to be such a debate. Savas/Brian, my comment about Notify wasn’t anything to do with pub-sub. I was wondering if a purely event-oriented architecture (some kind of notification service approach) would be even more fundamental, since you can model pub-sub on it. I agree with Brian though: the world is crowded enough with architectural models without introducing another.