• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JMS confusions

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
by the way, did you respond based on your own experience or purely hypothetical induction from readings?
 
Rufus BugleWeed
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic