wood burning stoves*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes JMS confusions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "JMS confusions" Watch "JMS confusions" New topic
Author

JMS confusions

Denis Wang
Ranch Hand

Joined: Jan 23, 2004
Posts: 81
1) is this statement ture or false?
Anyway JMS is an asychronous architecture, which is not appropriate for communication requiring instant response, such as broadcasting stock price to traders and credit card validation.
2) The point to point messaging model allows both 'send and receive' and 'send and forget' messages. --Quote from some notes.
I don't know what is a 'send and receive' message. In my understanding, JMS decouplse sender and receiver. How can the sender expects immediate response from its receivers?
3) Synchronous messaging:
I think this is an awkard phrase need to be clearified. In the context of considerations for:
a) receiver clients and MOM server
In the JMS we defines MessageConsumer and MessageListener to distinguish a/sychronous receivers.
b) sender clients and MOM server
There is no such a concept applying to the senders.
c) the relationship between sender and receiver
Obviously JMS is an asychronous mechanism. The MOM mediator in between of sender and receiver basically disable a synchronous communication via JMS.
May I safely assume people use the phrase 'synchronous messaging' to refer to some mechanism different from JMS messaging architecture? If not, give me an example how to enforce 'synchronous messaging' in JMS please.
Your kindly response will be highly appreciated.
Best,
Denis
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
false
Broadcasting stock quotes or requesting cc validation seem perfectly logical.
Synchronous messaging has much in common with what is known as blocking I/O.
Denis Wang
Ranch Hand

Joined: Jan 23, 2004
Posts: 81
Thanks for your reply. Would you please explain more in details? A simple yes or no answer without any validation does not help me.
Denis Wang
Ranch Hand

Joined: Jan 23, 2004
Posts: 81
by the way, did you respond based on your own experience or purely hypothetical induction from readings?
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
You stock price is an interesting issue. When you publish a price to a subscriber, are you saying, I'm willing to sell at this price. Or are you saying, this is the current price a stock is selling for?
In a credit card transaction, say buying passage on a ship, Monson-Haefel's Titan Cruise Lines. You might click a button that says book my cruise, with pay by cc. Now a screen comes up that says Your passage will be booked when the transaction clears the cc clearing house. We will send email notification.
The application sends a requests to a cc clearing house via JMS. If the cc clearing house is real busy it goes on the end of the queue and waits its turn. If the cc clearing house is down with a disk crash, it could sit on the JMS queue for hours. In a sychronous transaction your client has to wait hours too. By decoupling the client, time wise, from a synchronous transaction things run smoother.
If you do not decouple the credit card transaction from the booking process, what do you do when the credit card clearing house goes down? Do you roll back the room reservation and tell the customer to keep trying until he is successful?
Denis Wang
Ranch Hand

Joined: Jan 23, 2004
Posts: 81
I got your point. The conclusion is not important, but the rational we used to reach the conclusion is important:
"Synchronous architectures are more appropriate than asynchronous architectures in applications where the sender and receiver must participate in a message exchange, and the sender must respond to the receiver in a limited time frame."
Go back to my initial statment. For the stock price, traders definite need it in a very timely manner to make their decisions. Whether buy or sell or even no further action is trivial.
As to the cc authorization scenario, you provide a very good reasoning. I had an experience when people took for granted 'something' must be within a transaction synchronously until the performance brought down the server's knees and no tunning could make any improvements further. However, cc authorization, I guess, is a different story. Most cc servers should be VERY powerful and react instantly. Anyway your reasoning makes sense. Maybe your business model will gain more popularity in the future. As I said, I don't care about the final conclusion. Thanks for participating in my discussion.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JMS confusions
 
Similar Threads
My SCEA Part 1Study Notes
Why there is so hype of JMS in just to send a message? Please give some explanations..
Query rgarding JMS
JMS or JCA or Webservice ?