I need to know how IBM Websphere MQ works.
As of my knowledge.
IBM Websphere MQ is an application that runs continuously
IBM Websphere MQ has a queue manager, queue name, port, host where it is runs, channel name.
We have a two different application in two different remote place.
Two applications and the IBM Websphere MQ applications are connected through network.
Using IBM Websphere MQ credentials the applications are able to send and receive messages between them via IBM Websphere MQ.
If I have anything wrong then please guide me.
My questions are:
If one application sends a message to the queue then where will the memory be consumed?
Where do we run the MQ listeners? On the applications environment or the Websphere environment (where we installed the IBM Websphere MQ)?
Do we need to run any programs in the application environments or are the IBM Websphere MQ credentials (queue manager, queue name, port, host where it is runs, channel name) enough to send and receive the messages?
If one application sends a message to the queue then where will the memory be consumed?
A Running Queue Manager requires memory in order to run and handle processing/storage of messages. As well as that every MQ Client application that connects to a Queue Manager requires memory to connect to and put/get messages. This is no different than any application that runs on any system.
Where do we run the MQ listeners?
Assuming you mean MQ Listeners. The MQ Listeners are run on the Queue Manager and specify the (TCP) port you want the Queue Manager to listen on.
Do we need to run any programs in the application environments or are the IBM Websphere MQ credentials (queue manager, queue name, port, host where it is runs, channel name) enough to send and receive the messages?
To run a Queue Manager on a machine, your machine must meet the System requirements stated in the System Requirements for WebSphere MQ page.
Here is the MQ v8 one
Likewise to run a MQ Client application that can connect into a Queue Manager, the application needs to have be ran on a machine that has the IBM MQ Client libraries installed on and meet the system requirements.
You also need to tell the application:
The location of the Queue Manager hostname/IP Address and port number.
The channel to connect into, which must exist on the Queue Manager
The Queue name to interact with, which must exist on the Queue Manager
Depending on your Queue Manager's configuration you need to ensure that your application is running with the correct user/supplying the correct user to ensure it is properly authorized to access the Queue Manager.
I am newbie to Websphere MQ and i have some basic understanding on the concept of MQ. I know that MQ client would create a message (with MQMD and application data) and then send to MQ manager. MQ client will get the correct response back from MQ Manager. Supposedly there are many messages on the MQ Queue Manager, how does MQ client able to retrieve the right messages? What determines the uniqueness of a MQ message?
There are different ways this can be approached - one common way is for the applications processing the messages to use the message ID and correlation ID fields. The message ID can be randomly generated and saved then copied to correlation ID field to be match when the reply is sent. Applications can do gets matching on those fields in the message header.
I suggest you read through the application programming guide and reference in the knowledge center.
I have setup a topic to MQ messaging. The setup is done like in the documentation "MQ Connectivity scenario 2: Fan in per device notification" it appears as though Messagesight adds data the the message when it arrives at MQ destination. (possibly JMS header data). Is there something that has to be setup either on messagesight or MQ manager to remove the data and only leave the message?
I have a Java JMS application that reads messages from a MQ queue. My application can successfully read a message and pull out the JMS headers (e.g. JMSDeliveryMode, JMSPriority etc) and the message body, but I can not access the <usr> folder part of the message.
I am placing messages on a queue using RFHutil. Under the RFH tab I am ticking 'Include RFH V2 Headers' and 'usr', and under the usr tab I have test1=1. I can see the <usr><test1>1</test1></usr> in the message if I browse the queue using MQExplorer, so I think I'm setting the usr folder correctly.
I have outputted the whole of message.getPropertyNames() enumeration (as discussed at topic JMS passing entire Application data <usr> block, but my usr fields are not under there. My message body also does not contain my usr fields.
I've also read on the MQ v7 info center you need to set WMQ_MESSAGE_BODY to WMQ_MESSAGE_BODY_MQ, but I am using v6MQ and do not know if this is relevant/how to set this value.
How can I get access to the usr folder using the JMS API?
Any help/pointers would be much appreciated as I am fairly new to JMS programming.
A first question is why is the USR folder of importance? Are you attempting to get your JMS application to interoperate with messages that put using another application that writes custom RFH2 headers.
RFHUtil is primarily used for test purposes.
MQ JMS originally used the RFH2 heasder to specifically send the JMS properties. Therefore the MQ JMS code reads the message, removes the RFH2 and processes it into a full JMS Message.
If you want the JMS API to fully read the RFH2, then the properties for reading the MQ message you've highlighted are correct. However those are not in MQ v6. Be aware that mq v6 and V7.0.1 are now out of support. Would strongly recommend that you investigate upgrading to MQ v8 - at minimum MQ 7.5.
CLients are freely downloadable if you are a developer and connecting to an estbalished QueueManager. Client versions don't have to match the QM.
What is the difference between a Websphere Message Broker and a Queue Manager. I guess the queue manager puts messages in the queue, takes messages out of the queue, moves messages to backout queues etc. So what is the job of the broker?
Does it sit between the publisher and the Queue Manager or between the consumer and the Queue Manager?
Websphere MQ is a software which uses the AMQ(Asynchronous messaging protocol). You can achieve asynchronous messaging between your applications via Websphere MQ, which will make your infrastructure loosely coupled(Applications can keep working even though other applications are down in the infrastructure).
But the applications in your infrastructure may not be able to understand each others' message formats, and hence just sending the message to the target application may not be enough. You may require transformation of the message.
You can do it by writing your own program using the Websphere MQ API.
Your program should be able to do the below things:
Pick message from a specific queue (using MQGET)
Should be able to understand the message. That is say it's an XML message. Then your program must be able to parse the XML and read the
data in it.
After reading the input message you will make your output message based on the requirements.
Then you will either publish the message or put the message in some specific queue(say TargetQ), so that the target application can get
the message. Target application will then get the message either by
issuing MQGET on the TargetQ or subscribing to the topic which was
published from your application.
But writing your own program will take a lot of development time and effort and also may be a bit complex.
So, IBM provided its own software to do the job, which is "Websphere Message Broker".
WMB allows you to create programs very easily and a lot faster.
Appropriate nodes in WMB will do all above steps for you. In fact it provides lot many features than the above steps.
Websphere MQ still doesn't have an HTTP listener. But, a message broker does. It allows you to host web services and have HTTP based flows etc that too in a secure way(Supports SSL).
MQ is providing you the infrastructure for messaging: queues and topics - IBM MQ
IBM Integration Bus (formerly known as WebSphere Message Broker) allows you to apply the common EAI patterns, e.g. Routing, Transformation
Hope that helps.
Best,
Patrick
I want to add just two points: Message Broker (now IIB) includes a set of optimized and fast parsers (XML, CSV, etc) and useful mapping nodes (msg-msg, msg-db). MQ is also used for internal configuration messages coming from the Configuration Manager.
WebSphere MQ is a solution for application-to-application communication services regardless of where your applications or data reside. Whether on a single server, separate servers of the same type, or separate servers of different architecture types, WebSphere MQ facilitates communications between applications by sending and receiving message data via messaging queues. Applications then use the information in these messages to interact with Web browsers, business logic, and databases. WebSphere MQ provides a secure and reliable transport layer for moving data unchanged in the form of messages between applications but it is not aware of the content of the messages. WebSphere MQ uses a set of small and standard application programming interfaces (APIs) that support a number of programming languages, including Visual Basic, NATURAL, COBOL, Java, and C across all platforms.
WebSphere Message Broker is built to extend WebSphere MQ, and it is capable of understanding the content of each message that it moves through the Broker. Customers can define the set of operations on each message depending on its content. The message processing nodes supplied with WebSphere Message Broker are capable of processing messages from various sources, such as Java Message Service (JMS) providers, HyperText Transfer Protocol (HTTP) calls, or data read from files. By connecting these nodes with each other, customers can define linked operations on a message as it flows from one application to its destination.
Message Broker can do the following:
Matches and routes communications between services
Converts between different transport protocols
Transforms message formats between requestor and service
Identifies and distributes business events from disparate sources
Together, WebSphere MQ and WebSphere Message Broker deliver a comprehensive publish and subscribe facility, connecting Message Broker’s broad transport and format support to WebSphere MQ’s messaging backbone. WebSphere Message Broker extends the WebSphere MQ publish and subscribe functionality with advanced function such as content-based publish and subscribe by means of an enhanced Publication node. The two products share a common publish and subscribe domain for topic- and content-based operations
MQ is mainly for the transforming the messages from on system to another system.
WMB(websphere message broker) will sit between QMGR's and transforming message along with change content of the message format as per the system requirement/Business Logic implementation.
Srinu D