JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ/MQS

[kurtstam]

The ESB needs to be able to talk to one or more JMS providers. At the service level definition we configure the host name and jndi port of the service. Since the naming system differ between naming implementations (jndi, jnp etc) we will need an extra parameter here to define the right naming context to use.

We currently have a class called AppServerContext, which we should rename to NamingContext and we should add more implementations besides the JBoss context.

This should give use the freedom to use any JMS provider and also to use multiple providers where the ESB can act as messaging bridge between the different JMS providers.

Am I right to assume that with this approach we don't necessarely have to deploy ActiveMQ to JBoss, but we could run ActiveMQ as standalone and 'mix and match'? Does this make sense? I'm currently retracing Arvinder's steps with ActiveMQ, but I'd like to know if you think this approach makes sense. Maybe I'm forgetting something?

thx,

--Kurt

[starksm64]

Why not just configure a provider URL that encompases the server, port, protocol and starting context?

We have found in jboss that we also need the full jndi InitialContext ctor env properties to allow control over things like the initial context factory, object/state fatory paths, etc.

[kurtstam]

I guess it's a tradeoff between keeping the configuration as simple as possible, and making things flexible. Right now we store the jndi InitialContext ctor env properties in that 'AppServerContext' class. I was just going to extent that for more 'AppServers'. Do you think it's a bad idea to store that info as static Strings for i.e. the naming context 'jboss'?

[starksm64]

Yes, that is a bad idea as even for a given jms pvoider we potentially need alternate configurations. Also, what is the relationship between this configuration object and the service that binds the jms connection factories? I assume it can be a jca deployment, mbean, etc.

[arvinder]

Kurt, thanks for the thoughts/work on this. There are some instructions on the wiki http://wiki.jboss.org/wiki/Wiki.jsp?page=ActiveMqIntegration, hope they will be of help. I am not around much (until after 19th Nov ) but i'll keep an eye out on email and groups.

[kurtstam]

Yes, that is a bad idea as even for a given jms pvoider we potentially need alternate configurations.

OK in that case we will have to make it configurable.

Also, what is the relationship between this configuration object and the service that binds the jms connection factories? I assume it can be a jca deployment, mbean, etc.

As is typical for ESBs, this release does not support transactions (in the real world most transports will use files, email, ftp etc). For the time being we use plain JMS, no JCA and/or mbeans. However I'm pretty sure we want to be transactional in the (near?) future. So future release will need JCA for sure. But this is more of a Mark question, I'm sure he will comment on this later this weekend.

There are some instructions on the wiki

Thanks Arvinder, that's a good place for it. (I was going off the email string). I will add to this page as I go.

[weston.price]

JCA would make the most sense. This is the role of our generic JMS adapter. We should talk about this when you guys are ready.

[arvinder]

Hi Weston,

Integration with ActiveMq is done via JCA, for IBM MQS, I beleive there is a rar aswell, although I need to check the distribution. I need to speak to Kurt to see the next set of steps to follow and the best way to code this plugin.

Is there something specific you wanted to talk about? Is this related ? http://jira.jboss.com/jira/browse/JBAS-3183

[weston.price]

No, IBM has no such RAR. They do not provide a JCA/JMS RAR for WebSphereMQ that I know of. You are more than welcome to use our JMC/JCA adapter with a few exceptions.

What I want to know about ESB's integration strategy in terms of tranasctional resources in general. We should be using JCA wherever possible. If we don't right now that's fine, but moving forward we should coordinate this type of effort between the teams.

[arvinder]

There seems to be a rar reference here: http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601_balachandar/0601_balachandar.html

Lets wait for Kurt to join in.

[weston.price]

So you are using the community edition JCA/JMS adapter? That is surprising. Yes, let's wait for Kurt.

[marklittle]

No, IBM has no such RAR. They do not provide a JCA/JMS RAR for WebSphereMQ that I know of. You are more than welcome to use our JMC/JCA adapter with a few exceptions.

What I want to know about ESB's integration strategy in terms of tranasctional resources in general. We should be using JCA wherever possible. If we don't right now that's fine, but moving forward we should coordinate this type of effort between the teams.

JCA support is on the roadmap for 2007. Let's talk early next year, i.e., once the 4.0 GA is out the door.

[arvinder]

I have no idea what is being used right now. If you look back in the thread I did the ActiveMq investigation. AFAIK Kurt was looking at MQS, I just started looking at it this week, although I have yet to install it.

So you are using the community edition JCA/JMS adapter?

Without further investigation, I can't answer your question. What community edition are you referring to? This term AFAIK is being applied to the Websphere Application Server Comunity Edition aka wrapper geronimo. AFAICT there is no 'community edition' MQS. So I am unsure what you are referring to when you say community edition JCA/JMS adapter.

That is surprising

What about?

[marklittle]

As is typical for ESBs, this release does not support transactions (in the real world most transports will use files, email, ftp etc). For the time being we use plain JMS, no JCA and/or mbeans. However I'm pretty sure we want to be transactional in the (near?) future. So future release will need JCA for sure. But this is more of a Mark question, I'm sure he will comment on this later this weekend.

Yes, we'll definitely need to support transactions in the future (2007). We should leverage the transaction bridging approach that we've used in JBossTS, so transactions can flow between implementations/models (multi-modal transactions). Getting the model right is important. The implementation (which uses JCA BTW) should be pretty straight forward.

[marklittle]

Weston, let's wait until Kurt recovers from Thanksgiving festivities. He is tasked with the MQSeries re-qualification. Rosetta already supported MQSeries through whatever mechanism and for expediency (plus the fact it's tried and tested) I'd assume we would use the same approach for the initial GA. Arvinder was driving the ActiveMQ integration, but Kurt was helping due to commitments on Arvinder's part.

Rather than play guessing games, let's wait until everyone is online to contribute and we have all of the facts to play with.

Cheers.