David Walend's Blog

SalutafugiJMS -- Java Messaging Service on ZeroConf

SalutafugiJMS is a peer-to-peer implementation of the Java Messaging Service specification that uses ZeroConf DNS-SD discovery and TCP sockets to communicate in a distributed computing system. I built it after seeing Daniel Steinberg's JavaOne talk on ZeroConf. SalutafugiJMS uses SomnifugiJMS as a skeleton and Apple's Bonjour implementation of ZeroConf for muscle inside special SomnifugiJMS FanOuts and Channels. SalutafugiJMS eliminates the central (or federated or clustered) message broker found in traditional JMS implementations and the need to manage specific services required by traditional DNS-SD systems. Name the JMS Queues and Topics for information your system needs to exchange. Your system consumes what your system needs. Your system sends out what it chooses. SalutafugiJMS takes care of the rest, leaving your system very loosely coupled.

Broker-Free JMS

In a traditional JMS application, message producers and message consumers don't have to know about each other. That feature creates highly decoupled systems. However, message producers and consumers all have to get connections to the same JMS message broker. That shared knowledge about the JMS broker usually comes from magic connection url strings to summon objects out of JNDI servers. Getting those magic strings correct is tedious; many elaborate projects focus on abstracting away those strings, sometimes to the point of programming in XML. SalutafugiJMS is a peer-to-peer system -- producers send messages directly to consumers -- while remaining highly decoupled. The only magic string for you to wrangle is the name of the JMS Topic or Queue. No central broker exists; the system can handle failures in any single service and keep going.

Anonymous ZeroConf

In a traditional ZeroConf system, ZeroConf provides service discovery; a service registers itself so that applications can discover and use it. Those applications browse for the services they need, and resolve them by name. The system is loosely coupled at build time, but becomes very tightly coupled as soon as the application resolves the services at runtime. If the application depends on a service that fails midway through a run, that application suffers. SalutafugiJMS adds JMS' anonymous endpoints to ZeroConf to eliminate that tight coupling. Behind the curtain, SalutafugiJMS consumers register what Queue or Topic they wish to receive messages from. SalutafugiJMS manages browsing and resolving the services inside the producers. Your applications simply produce and consume messages in the system when they need to.

Building SalutafugiJMS

I spent about thirty hours' total reading, designing and coding to get messages flowing between JMS Topic Publishers and Subscribers. Bonjour's programmers' interface is a little call-back heavy. Stopping all the services' monitor threads took some thought and a little reworking of SomnifugiJMS. Daniel and Stuart Cheshire's book was very good; everything worked like they said it would. Getting to the initial release was easy and fun. I'd hoped to be able to mine the effort for half-a-dozen blogs, but I think I'll only get two -- one on Thread.sleep(), and one comparing ZeroConf, JXTA and JINI.

The only aggravating part was getting the Bonjour dns_sd.jar from Apple. I do most of my work on an older G4 Mac (amazingly long battery life). Apple's Bonjour page provided a windows .exe installer to get at that dns_sd.jar. I got the jar from a friend with a newer Intel Mac. Daniel tells me I could have pulled in the Bonjour source code and built the dns_sd.jar myself after all. I've gotten very used to Java's jar-based library distribution. I normally only pull in source code to help fix problems and add features. I didn't even think to look.

SalutafugiJMS' first release is very much alpha-0-1, JMS Topics-only, and missing many features. SalutafugiJMS seems a little slow and I haven't looked into why. I haven't used SalutafugiJMS in any of my own applications yet, so downloader beware. Alpha-0-2 will focus on logging and fault management, alpha-0-3 on filling in features for Topics.

If you're more interested in broker-free JMS now and can swallow a GPL (or maybe MPL) license, have a look at MantaRay. I think they use a proprietary multicast protocol, not ZeroConf. They've had a working peer-to-peer JMS for a few years.

Comments

• FWIW Apache ActiveMQ can work in a peer to peer mode; using its own multicast discovery or zeroconf... http://activemq.apache.org/discovery.html http://activemq.apache.org/peer-transport-reference.html You can use discovery in a peer to peer architecture, or in a federated cluster architecture; so you've the best of both worlds. Typically if you want reliable messaging and persistence, you probably don't want peer to peer; as thats a lot of disks to worry about backing up etc :)

  Posted by: jstrachan on June 25, 2007 at 02:50 AM

• Thanks. I spotted their federated cluster business, but not the peer-to-peer.

  At some point I'll write a blog about reliable messaging's detrimental effects on system reliability...

  Posted by: dwalend on June 25, 2007 at 05:40 AM

• you said: "At some point I'll write a blog about reliable messaging's detrimental effects on system reliability..."

  Yeah I was actually on a project a few years ago that got cancelled because someones' "reliable" eb-xml messaging didn't work. The prototype worked in production for a year using dumb-ole-http-post without missing a beat.

  However some genius thought we needed "reliable messaging" and so we modified everything to use eb-xml. Unfortunately, due to an interop problem between endpoints (both using the same libs) the sender always threw an exception, even though the messages were "reliably" delivered.

  So since there was no way to distinguish between a real message failure, and the bogus exception which always occurred, "reliable" sending was declared unachievable and the project was canned.

  Go figure...

  Posted by: geoffh on June 27, 2007 at 06:02 AM

• geoffh,

  Wow. That's a terrible war story.

  Most of what I've seen is systemic failure caused by the demands of reliable messaging: big latencies, databases filling up, big message backlogs, nasty interactions with timeouts, thrash and churn sorts of problems.

  Posted by: dwalend on July 01, 2007 at 08:13 AM

This work is licensed under a Creative Commons License.