| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Should I be installing MQSeries? |
« View previous topic :: View next topic » |
| Author |
Message
|
| karl_f |
 Posted: Fri Jul 11, 2003 12:26 pm Post subject: Should I be installing MQSeries? |
 |
|
Newbie
Joined: 11 Jul 2003
Posts: 1
|
I business partner indicated that they would like to use MQSeries as their primary means of communication since they are worried about duplicate transmissions and require guaranteed delivery.
The messages that I will be receiving from them will then need to be processed and sent to yet another business partner that is also using MQSeries as a communications gateway.
How does MQSeries send/receive messages? Do I require MQSeries or can it simply do an HTTP POST to a web service? Even if I do have MQSeries I would still need to extract the message from it somehow and pass it on the database application that would process the information. How would I do this? Currently all my clients send and e-mail with an attachment or does an FTP put to upload their data. Another application takes that uploaded data and POSTS (HTTP POST) it to a database application.
I will also need to send data back to MQSeries to delivry it to the ulimate destination once it has been processed, would I be able to FTP/POST a file directly to MQSeries?
Basically I need to understand how I’m going to get data into and out of MQSeries.
Any explanation or links would be appreciated.
Thanks
Karl |
|
| Back to top |
|
 |
| bduncan |
| Posted: Fri Jul 11, 2003 2:46 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Karl-
Without delving into too many details, you can think of MQSeries as mechanism to transmit messages between various points (queues). The queues are contained within a queue manager, which you can think of as a server. Now, to give messages to MQSeries for transmission, or retrieve messages that have been sent, you'll need an application that can connect to the queue manager. It does not do this via HTTP. An application connects using either a client or server API. The server API requires the application to be running on the same machine as a queue manager, whereas the client API does not.
Now I could imagine a solution for you that would look somewhat like the following.
You'll have a web server which invokes a servlet that uses the client API to connect to a queue manager on a different machine. The servlet creates a request message and hands it off to the queue manager for delivery to a queue which resides on another queue manager. This second queue manager is running on a database machine. An application gets triggered when the message arrives, and this application retrieves the message from the queue, does a database transaction, and creates a new reply message. It hands this message off to the DB queue manager for delivery back to the other queue manager. In the meantime, the servlet started waiting for a reply message as soon as it sent the request message. Now it arrives, and the servlet displays some HTML back to the user.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jul 11, 2003 2:47 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Also, if you click the "intercommunication" link under the "documentation" tab on this site, you'll see IBM's intercommunication guide for MQSeries. I think this is the best place to start to get a high level view of how MQSeries (and asynchronous/point-to-point messaging in general) works.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
