Messaging is the Right Way to Build a Distributed System

Discussions

Blogs: Messaging is the Right Way to Build a Distributed System

  1. A message-based design is fundamentally the right way to think about building a distributed system, as opposed to code sharing, remote procedure calls, and the like. Eric Armstrong explains why.

    Read Messaging is the Right Way to Build a Distributed System.
  2. I agree with all of Eric's points, many of which are inherent to (async) SOAP. One benefit of messaging he missed is tolerance of an unreliable network, including offline operation. Eric's points and mine are very well satisfied by JXTA and more or less overlooked by rivals such as J2EE, Jini, etc.
  3. I don't think so, it's a thin layer of ice here. Yes, in theory he's right but such systems are typically not economical to scale. A stateless design must keep its state somewhere else and that state needs to be fetched each time a message is received.

    Yes, it's simple and yes, it doesn't scale because usually noone can afford the cost of the hardware when scaling it out horizontally depending on the circumstances.

    What circumstances? If the system has almost no locality, i.e. if it was a single system, the cache hit ratio would be very low or the nature of the data is that entries in the cache are hit very infrequently, i.e. once a week then this stateless design makes sense. But, if these conditions don't apply then there are much more economical approaches to building such systems and they may involve directed routing message to stateful servers as is possible in WebSphere XD.

    So, the points in the blog are valid under a certain set of conditions, they just arent spelled out and it'd be a shame if people assumed this design approach is universally the best.

    Billy (IBM)
    http://www.billynewport.com
  4. I don't think so, it's a thin layer of ice here. Yes, in theory he's right but such systems are typically not economical to scale. A stateless design must keep its state somewhere else and that state needs to be fetched each time a message is received.

    I don't think that messaging and statelessness are linked. Having components linked by async messaging instead of sync apis does not say anything about holding/caching state on any component.
    Http is a stateless, messaging based protocol, but that hasn't stopped web-application-servers (including WebSphere) from effectively maintaining session state for clients.

    Maarten
  5. Pro's and Con's of Async[ Go to top ]

    Async Messaging and statelessness don't have to be linked, but when they aren't one ends up with fairly complex state machines on both sides of the async connection. Even with relatively simple sets of operations each side has to deal with potentially out of order messages and extremely delayed messages. This can be quite challenging. One could argue that this complexity is just the cost of doing business. I remember this argument well when people discussed the relative merrits of Garbage Collection, Higher Level Languages, and hydraulic cranes (innovators dilemma reference). I don't reallly believe it.

    I have built a few successful complex applications using async messaging. I have worked at a company that tried to bring guaranteed async messaging to the masses for web development. After these experiences I can say with confidence that for many applications developers want/need a higher level abstraction. Directly dropping down to async messaging can be (but is not always) overkill. Some applications need some ordering to their events. Others badly need Object Identity. Most need some level of batching or transaction. Many applications need to shuffle data around between processes on an as needed basis. Should everyone write that stuff themselves based on async messaging? I can only speak for myself when I say that I prefer to have abstractions around these classes of problem.

    What should that abstraction look like? I'm glad you asked that question. A good first step would be for it to look a lot like something people already understand. For J2EE applications it should look like session. But it should efficently send around only the bare minium of changes, and manage heap usage for you. For stand alone Java Applications it should look like a regular multi-threaded app. Just extend the Java memory model right down to wait and notify.

    Are these goals easy? No, of course not, but they are reachable much like efficent GC isn't easy. But it's the right direction and goal, and it is attainable over time.

    Steve
    www.terracottatech.com
  6. We're all agreed here. My points are simply that coupling messaging with statelessness doesn't always work from an economy point of view. The article linked messaging and stateless.

    Billy
  7. Actually, it's a great example of how an application that could be written with a handful of classes and methods could be chopped up over a network with all sorts of complex messaging. ;-)

    However, if you re-read the article and think "application" instead of "module" (i.e. think inter-application integration instead of inter-object communication) then the article has some good points to think about.

    But the supporting details are unfortunately just suppositions, and some are completely incorrect, such as:
    Object-construction is relatively expensive.

    This is compared with sending a message, which will likely construct thousands of individual objects (profile it!) to just accomplish a single message transfer? Why worry about the expense of object construction, which is inexpensive to start with. Or if it's an XML message using the Apache stack, the number of allocations goes off the scale, probably into the tens or hundreds of thousands to pass and parse a single message. And yet, even with those endless hordes of objects constructing, it can still seem relatively quick.
    On top of that, you have the problem of distributed garbage collection.

    I see probably a dozen different distributed systems a week, and I haven't seen distributed garbage collection in four or five years now. Maybe he's thinking about RMI? Yes, I suppose if you architect "the application that could be written with a handful of classes and methods but is instead chopped up over a network via RMI" then you will get what is coming to you. But that disastrous architectural fad went out of style ten years ago.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  8. This article is actually about objects vs. XML as a protocol for a distributed system, about which it makes some good points.

    But it purports to be about J2EE vs messaging middleware. But J2EE and messaging are clearly compatible through the JMS api. You can achieve XML messaging very easily in a j2EE framework. Or objects messaging, if you prefer. Or RMI etc.