The Artima Developer Community
Sponsored Link

Weblogs Forum
Messaging is the Right Way to Build a Distributed System

50 replies on 4 pages. Most recent reply: Aug 22, 2006 4:12 AM by D. A.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 50 replies on 4 pages [ « | 1 2 3 4 ]
Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: Messaging is the Right Way to Build a Distributed System Posted: Aug 21, 2005 8:11 AM
Reply to this message Reply
Advertisement
Attila Szegedi's Weblog
Ruby on Rails? What about Java based alternatives?
"For maximum scalability, you can even serialize the continuation into a hidden form field in the response HTML, so you completely get rid of any server managed state!"
http://www.jroller.com/page/aszegedi?entry=ruby_on_rails_what_about

This is a very interesting blog. It isn't on the subject of messaging per se but it does relate to this discussion thread because one of the arguments that you made for messaging, Eric, is that stateless message processing is more scalable. This person describes a most interesting approach to doing what you advocate - retaining context in the client and supplying it to the server-side as encapsulated in request. Yeah, nothing new there - but the exact mechanics of how to do that is what is fascinating in what this blog author describes.

(You have to wade thru a bit of discussion on dynamic script languages vs. strongly typed languages before getting to the above quoted item.)

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Messaging is the Right Way to Build a Distributed System Posted: Aug 24, 2005 11:17 AM
Reply to this message Reply
Roger Voss wrote:
> Attila Szegedi's Weblog
> Ruby on Rails? What about Java based alternatives?
> "For maximum scalability, you can even serialize the
> continuation into a hidden form field in the response
> HTML, so you completely get rid of any server managed
> state!"

> http://www.jroller.com/page/aszegedi?entry=ruby_on_rails_wh
> at_about
>
As you say, a very interesting blog. The suggested procedure boiled down to a few points:
a. Use the Rhino scripting language
b. Use the "continuation" feature (ability to store
a stack frame and restore it)
c. Serialize the stack frame and include it in the
message, thereby preserving all state information.

It's an interesting concept, but it fails the "transparency" test. You can't inspect the serialized stack frame to see what's going on. That will make it murderous to debug.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Messaging is the Right Way to Build a Distributed System Posted: Jan 30, 2006 10:23 AM
Reply to this message Reply
The concepts behind using messaging to build a distributed system are sound, but the level of detail described here is definitely "thinking in the small". If you had to build an entire application this way, you'd have to have a team of only-experts and it would take 10 years to build a simple system.

I think the move toward ESBs and SOA in general will help simplify this, and distributed data services (such as <a href="http://tangosol.com/coherence.jsp">Tangosol Coherence</a>) can address many of the difficult parts of building large-scale systems.

Peace.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Messaging is the Right Way to Build a Distributed System Posted: Jan 30, 2006 8:48 PM
Reply to this message Reply
> I think the move toward ESBs and SOA in general will help
> simplify this...
>
Darn old acronyms. I can't even begin to guess what they mean, or if they're interesting enough to google. But if you tell me what they stand for, then I guess a lot about them before I even look...
:_)

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Messaging is the Right Way to Build a Distributed System Posted: Feb 6, 2006 2:33 PM
Reply to this message Reply
Sure :-)

SOA refers to a software architectural approach that breaks down large chunks of responsibilities into services, and then follows through with a technical implementation that does the same (e.g. using web services). Note that SOA does not necessarily refer to a particular technology, such as web services, but could be implemented on any service-exposing infrastructure (JMS, WS-*, SOAP, XML over HTTP(s), even CORBA).

ESB is often drawn as a conceptual river off of which various services are fishing, but that's just a really good way to confuse people. Basically, an ESB is a bus (some manner to pass messages, whether JMS or XML or SOAP etc.) that connects any number of endpoints (applications and services) without requiring those endpoints to be predefined (i.e. routing changes over time) and with the ability for (a) applications to express interest in and (b) services to declare support for various classifications of messages.

In other words, ESB is a bus approach to implementing SOA. ESBs in Java are typically technology-centric, e.g. JMS-centric. The idea, though, is that an organization would standardize on one approach across the entire organization, and somehow magically insulate themselves from change over time ;-)

Peace,

Cameron Purdy
http://www.tangosol.com/

D. A.

Posts: 1
Nickname: fayser
Registered: Aug, 2006

Re: Messaging is the Right Way to Build a Distributed System Posted: Aug 22, 2006 4:12 AM
Reply to this message Reply
(I know it is one year after the main discussion took place, but I find this topic very interesting)

From my point of view, the big point that makes messaging suitable for distributed systems is the amount and complexity of the state information. Storing the state in the message itself is, in many systems, almost impossible. If your system is almost stateless, use messages. If not, use a distributed object approach.

Imagine you have to develop a distributed system that shall allow several users at the same time to edit concurrently the same document, using lock/unlock mechanisms to share portions of the document, and events to notify each user of changes in portions of the document. The document is big and complex: think for example in something like an Autocad file to be edited by several users at the same time. To make things worse, the document references external data (for example, parts of the plan are templates stored somewhere, or the document is composed of other smaller documents that can be edited separately).

In that case, the "document" is something so big and complex that has no sense to be exchanged continuously between all the systems that collaborate in its edition. I think the only way is to have a server that stores the document and all the external data referenced by the document, providing an API that is used by the different clients to get the document data, lock/unlock/modify parts of the document, be notified of changes on the document, etc. The document itself will be so complex that even in XML format it will be completely unreadable (XML handles badly the links between entities, it is tree based and storing N-M relations makes them very complex), and will be better described using object data structures. Since everybody is editing the same data, synchronisation is so important that I do not see how to implement all that mess using messaging. And to make things worse, all editing operations shall be undoable... but having the state in the server allows having a command queue to implement the undo/redo funcionality (it would be impossible to have that queue in the message itself).

I think messaging is a good approach for some systems... just the same than distributed objects are good for some others.

Flat View: This topic has 50 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Messaging is the Right Way to Build a Distributed System Previous Topic   Next Topic Topic: Upcoming Appearances

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use