views:

130

answers:

3

hi, I am using Oracle Service Bus(OSB) as the MOM, and the destination URI is a IBM MQ queue. I just want to know which would be the preferred transport. OSB provides 2 adapters for the same, JMS adapter and MQ adapter for transport. Does any one knows what are the PROS and CONS of the same. TIA

A: 

I don't know the exact software you use, but it appears to me that adapters only "adapt" the underlying technology to a certain API - in this case JMS. So the underlying MQ, which would make the difference, stays the same. I think I would go for the JMS adapter, because it is standard.

Bozho
yes, JMS is standard but the native MQ transport is supposed to be faster. I just want to know whether there are any thread blocking issues with using native MQ as transport.
hakish
what I meant is the transport probably does not change. It's only the API that changes.
Bozho
i am not sure about the implementation of how the MQ native transport is implemented, i know that MQ is faster than JMS, but are there any other issues especially thread blocking for a response, that i am not sure of.
hakish
+2  A: 

It depends on whther the program at the other end of the MQ queue is expecting a JMS or "native" MQ message.

MQ can act as a native queue mechanism or a transport for JMS messages. The difference being that JMS messages have some standard header fields at the begining of the message buffer and "native" mq messages contain just the data your program sent to the buffer.

James Anderson
The app at the other end is only concerned with the Body of the message, it does not do anything with the header fields.
hakish
@James - That is not really true. Native MQI messages also contain headers. More often than not the only one that is used by an application is the MQRFH2 (Jms header), but you can interact with others.
gwhitake
@gwhitake. -- but the native MQ headers are in separate structures whereas the JMS headers are delivered in the same buffer as the message.
James Anderson
A: 

Typically, sending messages via the native MQI interface will be faster than using JMS. In reality I doubt you will see a real difference, unless you are sending tons of messages per day. However, there are other things to consider than just speed. For example, if you are not familiar with MQI applications the learning curve will be steeper than JMS.

JMS header information is mapped to an MQRFH2 header when sent to another JMS destination via MQ. The inclusion of a MQRFH2 header is driven off of the Destination object you create. If the destination is a JMS endpoint then the header is included.

I have included a link below that explains how the fields are mapped:

  1. Mapping JMS messages onto MQI messages.

In reality, unless you are sending millions of messages a day I would assume that the performance of JMS on WebsphereMQ will be more than adequate for your needs. As far as thread blocking goes in request reply I don't think you need to worry about this. By default the reply in WebsphereMQ is consumed by a seperate thread, not the requesting thread.

gwhitake
yes gwhitake, it a very high volume application that i am working on, the message count is definitely on the higher side.
hakish