[Spread-users] Spread message queueing questions

[Rob Butler]

>Hi Rob.  Did you find out anything about how to have Spread/JMS play
>nicely together?

Basically there are a few options.

1) build a bridge.  Build a software bridge that would allow messages sent 
by spread to be forwarded to a JMS server, and vice versa.  This probably 
would not be too difficult if done in Java.  Using Java makes the JMS API 
available by default, and the spread toolkit already has a Java API.  So 
this wouldn't be too hard to do.

2) build a big bridge.  Instead of building software to pass messages from 
spread to jms and back, abstract a level to another API of sorts, or another 
communication layer.  Basically, build something that can talk JMS, and have 
it support some sort of "wire protocol" on the other end.  That "wire 
protocol" can then be used by any language to communicate to the "big 
bridge".  The "big bridge" can then communicate to any JMS server.  This 
would have the added benefit of not being JMS / spread specific.  So if you 
wanted to write a C++ program, and use the services of JMS, you can 
communicate through the bridge to JMS.  This would be a bit more work than 
option 1, but much more flexible.

3) Implement a wire protocol for a JMS server.  Jboss has a JMS server 
implementation available with it for free.  The Jboss MQ JMS server appears 
IDEAL for attaching a wire protocol to it. Jboss MQ has a defined interface 
that allows interfacing different communication protocols to their JMS 
server.  All the JMS communication protocols that are presently implemented 
look fairly java specific.  But I'm sure another communication protocol 
could be developed and interfaced to their JMS communication interface.  
This new communication protocol could implement a "wire protocol" allowing 
different languages to make use of the Jboss MQ server.  The advantage of 
this approach is you don't have another process sitting between you and the 
messaging server.  Less to install, configure, have running on your system, 
etc.  The downside of this approach is that it will only benefit you if you 
want to use the Jboss MQ server though.

Of the three approaches I have considered both option 2 and 3 as viable.  
Option 2 would be simpler to implement because the JMS API is well defined 
and can be learned about easily.  Also, you could then use any JMS server 
you wanted.  Option 3 is nice because there could be less code to develop, 
but you would have to understand the Jboss MQ code and interface.  Another 
plus though is JBoss is actively developed, and so is the MQ server.  It is 
a good posibility that someone else could "do the work for us".

I've been busy with other projects and haven't had much time to devote to 
this.  I haven't had a chance to communicate with the JBoss development 
community about the development of a "wire protocol" for JBoss MQ.  
Although, I have thought a lot about how the "wire protocol" should be 
developed.  Or at least what features and capabilities it should have.  
Optional SSL encryption, very light weight simple client, most logic on 
server, etc, etc.

When I have more time, I'd like to approach both options 2 and 3.  That way, 
if you don't like Jboss MQ for some reason, you have choices.

Oh, a fourth option is to develop a c or c++ interface using JAVA JNI to 
access the JMS API.  There is at least one commercial product that has been 
developed using this method.  I don't think this is a good option, because 
unless you have some legacy application you are extending, or some other 
very strong reason not to use Java, you may as well.  Using c++ or c, to 
interface JMS via JNI still has the costs of starting up and using the JVM.  
So for me, this option is not an option.

Again, development of option 2 and 3 are both very interesting and important 
to me, but I don't have the time to do it right now.  Hopefully I can get 
more time shortly.

Rob


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com