« links for 2006-05-27 | Main | links for 2006-05-29 »


Aaron Johnson comments on using IM for grid computing

"Reminds me of the Jabber / Agents (http://ll3.ai.mit.edu/abstracts.html#acme) presentation I saw at the Lightweight Languages workshop at MIT a couple years back."

Which is great for two reasons. First I was heavily into agent computing a few years back, before WS hype, the lack of interesting applications and insufficient infrastructure sucked the life out it (even today, too much infrastructure needs to be built out first before agents will become plausible - that's an entire other post).

Second, Dana Moore is one of authors of the paper Aaron points at. Dana Moore, with Rich Kilmer, gave one of the most interesting tech interviews I've ever seen, Controlling agent societies with Ruby, to Jon Udell. Agents folks will eat it up, but much more interesting is how they leveraged the dynamism of Ruby to stress and test a Cougaar system (Cougaar is a Java based agent platform). Udell posed the issue of if a scripting language is useful for around the edges stuff, like testing, and gets used here and there initially, and then in more and more places to "fill in" around statically written systems, at what point do you say to heck with it and build everything in the scripting language? It's a great question that gets harder to answer every year. I had the impression after their experience that Kilmer and Moore were about ready to throw the towel in and use Ruby end to end. [They also have an excellent comeback on the "IDEs and Code Generation good" counter argument to dynamic languages that's being doing the rounds in last few months.]

Personally I've run into where to draw and redraw the line with Python for enough years now to think the line is more or less rubbed out. I think maybe you wouldn't build an OS kernel in Python, but I think you could build good MQ software with it and that's something I wouldn't have considered realistic 4 or 5 years ago. In the commercial space, the technology arguments around dynamic languages are much less interesting than human resource ones.

Which gets me back to XMPP. My main integration experience with XMPP was to use it to shuttle events around a heterogeneous messaging system; which I think most people would describe now as a SOA (it did a lot of gateway and intermediary forwarding work). XMPP was, like Ruby for the agent system, "filling in" around the messaging system. One reason to use it was that it was possible to do near real time event and monitoring messaging without getting heavy on how to scale the infrastructure. Another was that IM clients can be deployed incrementally, which was important because this system needed to rolled out very quickly and we had no real idea when or whether it would stop growing. Yet another was that it could be built out without taking any existing messaging sub systems offline or stressing them out. The final reason was that it need to process more traffic than the messaging system itself was designed for (there are more events about messages than messages). The latter makes you wonder then whether you couldn't run the messaging over the XMPP network. Now, the messaging system in question had the fast to deploy and evolvability parts nailed (the way that system's network has grown is wholly organic), but the lateral scaling and "real time" characteristics of XMPP are compelling, when you see the effort expended to hook up enterprise MQ systems over HTTP, for time sensitive information. The question of where to draw the line comes up again. Myself, I'd be inclined to mumble something about whether the data is time sensitive and/or naturally delivered as a stream rather than a document, but it's vague at best. Just like the static/dynamic language divide, it's not question of which is "better", but which is the better in a given situation.

Using XMPP today for this kind of work, is about at about the same level of awareness as using HTTP for system integration was 8 years ago. XMPP might become a de-facto enterprise integration technology in or around the end of this decade, just like HTTP did at the beginning of the decade. Even as far as syndication technology will take you (and that's probably further than many people expected), the Web is not ideal as an event backbone. Whereas with XMPP and HTTP used side by side, most if not all of the interchange and integration use cases are covered off. And Atom is the interchange format that will let you carry data across both networks.

May 27, 2006 04:28 PM


Adam Rosien
(May 27, 2006 05:18 PM #)

I've also been musing about HTTP+XMPP as the "right" technology for the APIs to our system. I'll have to do more reading in to XMPP. Thanks.

Paul Browne
(May 29, 2006 12:56 PM #)

Any Good Agent links? Final Masters exam on Friday will deal with these :-)

Nolan Eakins
(May 29, 2006 07:51 PM #)

For a number of months I've had the idea of exposing a limited XMPP API to JavaScripts in a browser. It would essentially be XmlHttpRequest on steroids since there would be absolutely no polling, and it wouldn't be as hackish as Comet where an HTTP stream is always kept open.

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: