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 🙂