OpenJMS

[Robert M. Gary]

I'm curious what other's experiences have been with OpenJMS. I'm
looking for a "vender neutral" JMS so I can provide services to my
customers who implement on a variety of App Servers. I thought I could
standardize on OpenJMS since they could all interact with it (vs me
having to provide a service to each vender's JMS). This is a
commercial product and I'm a bit concerned that OpenJMS says its still
in beta and doesn't see to have any work done on it in about a year.
Is it stable enough for commercial use??

-Roberrt

 

[Richard Reynolds]

I'm curious what other's experiences have been with OpenJMS. I'm
looking for a "vender neutral" JMS so I can provide services to my
customers who implement on a variety of App Servers. I thought I could
standardize on OpenJMS since they could all interact with it (vs me
having to provide a service to each vender's JMS). This is a
commercial product and I'm a bit concerned that OpenJMS says its still
in beta and doesn't see to have any work done on it in about a year.
Is it stable enough for commercial use??

-Roberrt

We use it to broadcast changes made on a java thick swing client to all the
other clients that are currently logged on in realtime.
It's a really old version, maybe 5 years.
We use flat file persistence rather than the preferred db schema as it was
originally just a proof of concept that ended up staying in the final
product.
It's never given us any problems and is quite quick and light so I'd have
to say we've found it ok though it's not doing anything very heavy or
complicated, possibly 50 clients worldwide on an intranet.
I agree that there doesn't seem to be any work being done on it, I reckon
it's pretty much been left behind by J2EE vendor JMSs and things like tibco
EMS.

 

[Arne Vajhøj]

I'm curious what other's experiences have been with OpenJMS. I'm
looking for a "vender neutral" JMS so I can provide services to my
customers who implement on a variety of App Servers. I thought I could
standardize on OpenJMS since they could all interact with it (vs me
having to provide a service to each vender's JMS). This is a
commercial product and I'm a bit concerned that OpenJMS says its still
in beta and doesn't see to have any work done on it in about a year.
Is it stable enough for commercial use??

JMS is an API and is always 100% vendor neutral.

Various message queue specific implementation exist.

But that should not bother you in your Java EE app.

You lookup the message queue by name and access it via the JMS API
no matter what implementation it is.

Some customers will prefer to use their existing message queue
infrastructure.

Other customers will prefer you to deliver a complete solution.

For the last category you may want to look for a free message
queue implementation with JMS support.

Several such exist.

OpenJMS would not be on my short list.

Arne

 

[Robert M. Gary]

But that should not bother you in your Java EE app.

Im not an EE app, I just want to publish on the JMS buss so customers
can subscribe.

You lookup the message queue by name and access it via the JMS API
no matter what implementation it is.

The JMS specifications claim its not a wire protocol and say the wire
implemention is up to the implementer. Are you saying this is not
true?

Some customers will prefer to use their existing message queue
infrastructure.

So you are saying I could choose to use, say JBoss and publish a
message on the JMS buss that is read by my customer running Web Logic,
etc? What specifications would JBoss and WebLogic use to talk to each
other, I don't see that specification, only an API specification.

-robert

 

[Arne Vajhøj]

Im not an EE app, I just want to publish on the JMS buss so customers
can subscribe.

It is easier doing EE stuff inside an EE container than outside.

The JMS specifications claim its not a wire protocol and say the wire
implemention is up to the implementer. Are you saying this is not
true?
No.


So you are saying I could choose to use, say JBoss and publish a
message on the JMS buss that is read by my customer running Web Logic,
etc? What specifications would JBoss and WebLogic use to talk to each
other, I don't see that specification, only an API specification.

So we have:

your Java SE app----Foobar MQ----XYZ Java EE app on ABC app server

the admin for the ABC app server deploys Foobar MQ client lib
and bind a name to the Foobar MQ servive

the developer og XYZ Java EE app just look up the queue by name
and uses the standard JMS API so the code is independent of
implementation

your Java SE app will need to have the Foobar MQ client lib
in classpath and you will need to somehow do something
Foobar MQ specific to get the connection but can do all
the rest using the standard JMS API

Arne

 

[Robert M. Gary]

Robert M. Gary wrote:
So we have:

your Java SE app----Foobar MQ----XYZ Java EE app on ABC app server

the admin for the ABC app server deploys Foobar MQ client lib
and bind a name to the Foobar MQ servive ...
your Java SE app will need to have the Foobar MQ client lib
in classpath and you will need to somehow do something
Foobar MQ specific to get the connection but can do all
the rest using the standard JMS API

I did consider that but with 300 customers in 40 countries I don't
want to be in the business of having to support every App Server that
a customer can find. In my smaller customers I may be able to dictate
their App Server but not in the larger customers. That is what got me
thinking about OpenJMS. I figure I could tell them that I'm using
OpenJMS and they could interact with that and I wouldn't be dictating
their App Server vender.

-Robert

 

[Arne Vajhøj]

I did consider that but with 300 customers in 40 countries I don't
want to be in the business of having to support every App Server that
a customer can find. In my smaller customers I may be able to dictate
their App Server but not in the larger customers. That is what got me
thinking about OpenJMS. I figure I could tell them that I'm using
OpenJMS and they could interact with that and I wouldn't be dictating
their App Server vender.

You do not have to tell them what app server to use. You just
need to give them the client libs for the message queue you are
using and let them config it in their app server.

Arne

 

[Robert M. Gary]

Robert M. Gary wrote:

You do not have to tell them what app server to use. You just
need to give them the client libs for the message queue you are
using and let them config it in their app server.

That's basically what I would be doing with OpenJMS I think. I figured
it would be better to use something like OpenJMS because it wouldn't
come with the baggage of an App Server. That way they wouldn't need to
load the libraries for another App Server in their App Server, just a
little library for the JMS. Am I missing something?

-Robert

 

[Arne Vajhøj]

That's basically what I would be doing with OpenJMS I think. I figured
it would be better to use something like OpenJMS because it wouldn't
come with the baggage of an App Server. That way they wouldn't need to
load the libraries for another App Server in their App Server, just a
little library for the JMS. Am I missing something?

I would expect most (probably all) message queue's supporting JMS to
come with an app server independent client lib.

Nothing special about OpenJMS for that.

Arne

 

[Robert M. Gary]

I would expect most (probably all) message queue's supporting JMS to
come with an app server independent client lib.

Nothing special about OpenJMS for that.

Interesting. I hadn't thought about that. I guess that's why I post
these things to USENET. I'll look into doing that.

-Robert