| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| General |
« View previous topic :: View next topic » |
| Author |
Message
|
| coolash_151 |
 Posted: Tue Dec 06, 2005 12:00 am Post subject: General |
 |
|
Newbie
Joined: 05 Dec 2005
Posts: 2
Location: india
|
Why can't a message be received from a remote queue?
Also as client server communication is synchronous if there is no connection then how can client connet to the queue manager in the server and initiate message transfer when MQI is asynchronous?
_________________
waiting reply ...
coolash_151 |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Tue Dec 06, 2005 12:27 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Why can't a message be received from a remote queue? |
messages can only be stored into local queues. a remotequeue points to a target queue that is a local queue somehwhere, but this local queue does not exist (normally) in the queuemanager where the remotequeue is defined. mq deliveres messages till its destination using channels and transmission queues (which are one-way), and to get the messages you have to connect to the destination queuemanager and get the messages from the local queue. mq will not route the message back if someone tries to read from a remote queue.
remote queues are for sending messages, not for getting access to a queue that exists elsewhere.
i do not understand the second question, sorry
_________________
Regards, Butcher |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Dec 06, 2005 3:34 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Also as client server communication is synchronous if there is no connection then how can client connet to the queue manager in the server and initiate message transfer when MQI is asynchronous? |
You can't. Clients can't "store" requests locally. They ONLY work when they can connect to a queue manager. This is the same way all data base clients work.
If you're looking for something that has a small footprint and can work locally without a full qmgr connection, have a look at MQe.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 06, 2005 4:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The answer to both of your questions, really, is "Because this is the way MQ is written to work".
Other messaging products have different views on the messaging space, and so have implemented different approaches based on those views.
It is a basic principle of software design that when working with COTS software or any complex API or standard, you design to the way the product works, rather than trying to force the product to do what you want.
So learn how MQ wants to do things, and understand that it doesn't impose a significant burdon on the application - and can actually free the application up quite a lot.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Dec 06, 2005 9:34 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
I agree with jeff completely here, but would like to add an important point:
WMQ is meant to provide an asyncronous and distributive data communications solution, coupled with assured delivery, and is designed as such; not only that, but it is designed in pretty much the only logical+possible way such a product ever could be.
Think of it this way - since there is no guarantee that the message will arrive to its destination (dest queue full, undefined, comm error, goes to dlq etc) getting from "remote queue" implicitly mean "go through all QMs on your network, and search for appropriate messages in all xmitq's and dlq's"; I don't know about you, but I believe this to be utterly implausible and senseless, impossible even. WMQ queues, and queues in general used for comm, are Input queues and nothing but - when this is fully grasped, the whole WMQ network pattern suddenly makes perfect sense.
Considering Clients I'm with Butch, I don't really know what you were trying to ask; Please rephrase. |
|
| Back to top |
|
|
| coolash_151 |
| Posted: Wed Dec 14, 2005 6:39 am Post subject: mqseries general |
|
|
Newbie
Joined: 05 Dec 2005
Posts: 2
Location: india
|
i am a final year student and mqseries is my seminar topic where i am just covering the funadamentals tht is objects of mqseries.i dont have deep knowledge of this topic.all the matter that i have collected is from net.one of the ppt says that programmer cannot get a message from a queue.
now MQI is asynchronous so tht when there is no connection the message can wait n whn the connection is established the message can b sent.However the client server application is synchronous.so when there is no connection the api calls cant be issued.now the clients connect to the queue manager in the server but when there is no connection how can client connct and send message.mite be astuid question but i dont understand.so please help.also i want to know why the message channel is unidirectional n mqi channael bidirectional
u can mail me on coolash_151@yahoo.co.in
| Mr Butcher wrote: |
| Quote: |
| Why can't a message be received from a remote queue? |
messages can only be stored into local queues. a remotequeue points to a target queue that is a local queue somehwhere, but this local queue does not exist (normally) in the queuemanager where the remotequeue is defined. mq deliveres messages till its destination using channels and transmission queues (which are one-way), and to get the messages you have to connect to the destination queuemanager and get the messages from the local queue. mq will not route the message back if someone tries to read from a remote queue.
remote queues are for sending messages, not for getting access to a queue that exists elsewhere.
i do not understand the second question, sorry |
_________________
waiting reply ...
coolash_151 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 14, 2005 7:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you have a web application, and it is only a web application that only executes code when someone is making HTTP requests, then there is no way to receive messages when the application is not processing a request.
However, you can spawn a thread during application initiation time, that can wait for messages and do something with them - but you will of course not be able to display any data to a user who is not making a request.
In a j2EE environment, you can deploy a particular kind of Enterprise Java Bean called a Message Driven Bean (MDB). The J2EE EJB container will start a thread or series of threads at it's initiation time, that will watch the queue for messages. And then the MDB will get called when a message appears.
Again, though, you can not display results to a user if there is not a user present at the time.
There is not necessarily any particular reason for why MQ channels are unidirectional, rather than bi-directional, that I know of. It might have been because this way data flowing in one direction will not interfere with data flowing in another direction - you can move data in both directions in parallel at higher speeds than you might if it were bidirectional - because you won't have to figure out which way data is moving (am I sending a message, or receiving a message now? And then next, what am I doing?).
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
