Is this J2EE compliant ??

[Johannes de Jong]

We have two "MDB" (WAS 4.0) that listen to all messages that come in on all our MQ queues.
They then according to the "service" defined in the header route it to a specific session bean. This session bean however needs parameters to perform certain tests. We cant pass these using the actual MQ message. So what I did is I wrote a SOJP that starts up a session bean that has as its sole purpose the binding of the parameters to JNDI. These parameters by the weay change with each test & are entered by a user on the command line.
The session bean that actually processes the MQ mesg will once it is "triggered" by the MDB, read these JNDI "strings" to get the current parameters.
Now I'm wondering is this all J2EE complient ??
By the way we first had a version where the SOJP put the parameters in a MQ queue & the session bean read them from there, but our MQ Office said no way could we use a queue to do that, yeah they are full of s..t The alternative was a database, but the client did not want to pay for that.
[ March 02, 2004: Message edited by: Johannes de Jong ]

[Lasse Koskela]

Sorry JdJ, but could you spell out SOJP for me?

[Johannes de Jong]

Simple Old Java Program.

[Lasse Koskela]

So someone runs the SOJP every now and then when the configuration properties need to be changed? What you're doing now is probably standards-compliant, but I think it would be prettier to just use a configuration file and have the MDB read it every now and then (which is a no-no according to the spec, but works just fine in most situations).

[Chris Mathews]

Seems to me that these parameters are tied directly to the message being sent so they should certainly be sent as JMS headers with the message. However, it seems that for politic reasons this is not allowed.
Your solution certainly seems "J2EE Compliant" but I am not sure it is making appropriate use of JNDI. A database would be the much more standard approach here but in truth it doesn't really buy you anything over your JNDI approach if you don't need these values to persist between server restarts.
This process seems error prone without the parameters tied to the message. What happens if the user forgets to set the parameters first? What happens if messages are processed out of the expected order (remember ordering is not guaranteed)? Overall, I don't get a warm and fuzzy...

[Mark Herschberg]

I'm lost. So you can't put the info in the message at all (header or body)? What's the point of having it?
You can fake this using a JNDI tree as you noted. That's how we cheated. It's legal, but don't expect J2EE high priests to be commenting on your piousness. I think the big drawback is that JNDI tree are hard when you cluster, because they are either kept on one server, or you have to deal with synchronization issues (time cost, fear of stale data) between the clustered servers.
As for the SOJP? Um, so when and where is that run? I like the idea of a config file much better. I think we also cheated by having some singleton bean which runs on startup (i.e. the code runs the first time any instance of the bean is loaded) to do this. It's not great, but probably better than some non-J2EE application running on the server.
(Of course, I'm rusty on all this.)
--Mark