savas parastatidis

Tim Ewald on MEST

Tim has some comments on MEST. While I said that I am not going to try and describe MEST again until we have a paper written, I think I need to make a clarification (some more details can be found as a comment on Tim‘s post).

As I’ve said previously, MEST is not proposing something that we are not already doing. As Tim says, MEST is already omni-present. We were just trying to define the architectural style called “service-orientation” in terms of architectural elements (data, connectors, components) and then compare it with “resource-orientation” which is represented by REST.

I can’t emphasise enough that the last thing we have been suggesting is that there is only a single WSDL operation defined for every Web Service called ‘ProcessMessage’. Obviously it’s been our fault for not making this crystal clear! Sorry!

10 responses to “Tim Ewald on MEST”

  1. Mark Baker
    Erm, so how many operations does MEST support? Tim makes the far-too-common mistake in his post, of believing – in effect or in actuality – that MEPs have application semantics. They don’t!
  2. Jim Webber
    Mark, Tim thought we advocated a single operation in WSDL called “ProcessMethod” whereas we don’t (as you know). A MEST service might have any number of WSDL operations but architecturally these are a single operation which allows the transfer of a message – all the WSDL operations do (in a very limited way indeed) is give you the MEPs that the MEST service supports.
  3. Mark Baker
    Ah, ok, I see the difference now; it’s just a granularity thing. But I don’t think your response to him emphasized that all operational semantics are indeed identical.
  4. Mark Baker
    Oops, sorry Jim, I thought you were Savas…
  5. John Teach
    Savas, I’ve seen comments from Brian Glaser and others on pub-sub. Do you think that ProcessMessage is a better architectural model than pub-sub for loosely coupled systems? JT.
  6. Jim Webber
    John: ProcessMessage is a lower level of abstraction than pub-sub. In a pub-sub interaction, there would be a number of “ProcessMessage” events, at least: one on the “server” side to deal with subscription, and potentially many on the “consumer” side to deal with events that it has subscribed to. The pub/sub argument is much like the RPC argument – it can be built on top of plain old message passing, but is at a higher level of abstraction. Though pub/sub is more likely to scale than RPC of course.
  7. Savas Parastatidis
    John, please let me clarify that “ProcessMessage” is not the name for the architectural style we are talking about; that’s “MEST”. “ProcessMessage” is just a concept we are using to capture the “get this one-way message and process it” semantics. As Jim says, pub/sub makes some assumptions that MEST does not. Pub/sub is just one of the higher-level architectures that can be supported by MEST. Others are possible as well. If you put pub/sub and MEST side-by-side, i’d say that MEST is more flexible and better as an underlying architecture for distributed systems but I understand that this is a statement that at the moment is not proven and is not supported by peer-reviewed papers. The picture around MEST will become clearer as we make available documents that describe it and, hoperfully, get more feedback based on them. Again, MEST is not attempting to describe anything foundamentally new; it just tries to capture service-orientation as a paradigm by using architectural elements. That way we can formally reason about its (possible) characterestics like loose-coupling, scalability, etc. and we can compare it against other paragigms (e.g. resource-orientation).
  8. Brian Glaser
    Jim/Savas, I think you’re missing the point about pub-sub as an architectural paradigm for loosely-coupled systems. What you describe as it’s disadvantages (e.g., a “number of ProcessMessage events” and that it’s RPC based) are implementation descriptions. I don’t want to dive into implemetations, because that doesn’t seem to be the area where ProcessMessage plays either (like you said, it isn’t about a single WSDL operation called ProcessMessage); however, everything you are mentioning as a disadvantage of pub-sub is implementation. Let’s try to keep this a comparison between likes. Conceptually/architecturally, my services subscribe to the ether to receive messages (pub-sub isn’t necessarily RPC based – check out some of the specs and implementations, going back at least a decade). My services publish to the ether to send messages. At this level I don’t need to talk about things like topics or queues (they are implementation details). If I want to consider that kind of thing, which is really selective publish and subscribe, then I can always categorize my ether into different buses. Afterall, what we’re talking about here is a message bus. If you look inside your favorite computer, you’ll see the same paradigm used there too: typically there’s a shared information bus that each peripheral/chip attaches to and for sending and receiving *messages*. In fact, the hardware analogy is probably a better example of pub-sub’s applicability to loosely coupled systems because today’s hardware is loosely coupled and interactions across that bus aren’t typically request-ack-response-ack, they’re one-ways message exchanges.
  9. Jim Webber
    Brian: Sorry – I didn’t mean to imply that Pub/Sub is RPC – just that pub/sub is a pattern built on top of plain old message passing. What we advocate is to start with plain old message passing and then build up to the right pattern for your service/application. What happens now is that folks start with something RPC-ish (thank you very much WSDL!) and build up from there – a poor foundation for Internet-scale systems.
  10. Savas Parastatidis
    Hey Brian, I think I see where you are going… Pub/sub seems to assume a broadcast of messages (I am not talking about implementation). MEST promotes directed messages with services playing the role of senders and receivers. I don’t think that the paradigms are far from each other. They may indeed be very close. Can you propose the best paper in your POV that describes pub/sub in architectural terms?