[Spread-users] Spread message queueing questions
rob_butler at hotmail.com
Thu Apr 25 14:22:31 EDT 2002
>Hi Rob. Did you find out anything about how to have Spread/JMS play
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.
Join the worlds largest e-mail service with MSN Hotmail.
More information about the Spread-users