The JMS thingy is really a joy to work with: clean and simple API, I would like to work with that everyday!
Now the tough part, well... after you did it, it's not tough at all. WebSphere MQ exposes two Java APIs, the "native" one, and the JMS bindings. If you choose JMS, you lose the ability to do synchronous request/answer through messaging. In my case it's pure asynchronous conversation, so the choice is really quickly done.
Making JBoss 3 to use MQSeries instead of JBossMQ is really... nothing (after reading JBoss' forums: a great help). Simply erase jbossmq-destinations-service.xml and jbossmq-service.xml from the default configuration, and populate the JNDI tree with JMSAdmin. And... it simply works. I would prefer a way to keep my configuration persistent in the JNDI tree, but I don't understand how "pcallies" solution works. Mapping jndi entries to the filesystem seems rather strange to me in this case, or maybe I'm missing some way to configure MQSeries through property files. Any help regarding this point is welcome.
Regarding the bad side of those attempts, I regret IBM's lock-in. You can't use an external access to WebSphereAS JNDI tree without the IBM JRE. In fact, the InitialContextFactory provided with WSAS is at one point strongly linked with IBM own CORBA implementation. I tried to access it with the standard J2EE 1.3 implementation, and then WebSphereAS has thrown at my face a 1229124488 CODESET_INCOMPATIBLE, which is an undocumented error (ORB errors)... So for now I wont use WebSphereAS as a true application server, but just as a glorified web server.