For example, In a trading application you may have 2 tasks
1. Verify your trade
2. Create a trade
When you verify a trade, you can submit your trade to a queue, where the trading engine picks up the trade and submit to the market for validation. The client application (e.g. your online trading app) blocks (i.e. synchronous) until a valid response is received. The trade verification needs to be synchronous to communicate any validation errors back to the user.
When you create an order, you could submit it asynchronously (fire and forget). The order status updates will also be received asynchronously once your trade is filled, rejected, etc by the market.
According to Oracle overview of the JMS API (http://docs.oracle.com/javaee/6/tutorial/doc/bncdr.html),
the JMS API has three characteristics:
1. Loosely coupling A component sends a message to a destination, and the recipient can retrieve the message from the destination. However, the sender and the receiver do not have to be available at the same time in order to communicate. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only which message format and which destination to use.
2. Communicate asynchronously A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.
3. Reliable The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.
However, in the lower part of the overview, it introduced JMS within a Java EE context, i.c. how can JMS be used among other Java EE components, such as Application clients, Enterprise JavaBeans (EJB) components, and web components
The JMS API in the Java EE platform has the following features.
Application clients, Enterprise JavaBeans (EJB) components, and web components can send or synchronously receive a JMS message. Application clients can in addition receive JMS messages asynchronously. (Applets, however, are not required to support the JMS API.)
Message-driven beans, which are a kind of enterprise bean, enable the asynchronous consumption of messages. A JMS provider can optionally implement concurrent processing of messages by message-driven beans.
Message send and receive operations can participate in distributed transactions, which allow JMS operations and database accesses to take place within a single transaction.
So, I guess this question depends on the types of components you use: client-side application can receive message asynchronously, while the business component (EJB) and web components (JSP, Servlet) can only receive JMS message synchronously.
A timing clock, fuse wire, high explosives and a tiny ad: