Rajesh
You can't do anything on the WMQ side to enable that kind of communication.
If you want a MessageProducer running against a WMQ JMS Provider to have its
messages delivered to a.n.other JMS Provider, you need some kind of bridging
agent. One solution could be the WebSphere Message Broker, wh
Thanks for the clarification, Gary.
So in that case my only other advice to Peter would be to ask his client to
ensure they have configured an appropriate level of security on the WMQ
side.
*goes off to think about trying all of this out*
-
Andy Piper
IBM WebSphere Messaging Community Lead
h
Simply because I don't know of another messaging server that will connect to
a WMQ queue manager over sender/receiver channels, and if you use client
connections (SVRCONN) you'll have no local queueing and have to handle
connection broken error conditions in your app.
Again, I may be misunderstand
Sorry - I didn't mean to introduce yet more confusion, I was just wanting to
encourage good practice/caution. There's no need for this to open any holes,
there are ways of securing a SVRCONN channel via e.g. SSL - this is fine in
native WMQ but I don't know whether the ActiveMQ bridging piece can d
BTW WMQ client connections (via SVRCONN) are bi-directional. Sender/Receiver
channels are unidirectional and set up in pairs between Queue Managers. HTH.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-integration-with-WebSphere-MQ-tp3550031p3563911.html
Sent from
Ah I see, so this remote jmsBridgeConnector that Edan refers to would equate
to what I described as "bridge code" - essentially using the WMQ JMS classes
(you'll need the JAR containing com.ibm.mq.jms.MQQueueConnectionFactory of
course) to make a separate connection over the network using the WMQ c
Indeed not - WebSphere MQ predates many of the other MOM technologies around
and the sender/receiver channel can talk to other WMQ implementations at
different versions, but not to ActiveMQ.
On your comment about standards, bear in mind that JMS is an API spec and
not a protocol / implementation t