I read alot of papers on frameworks and many talk about a web based client server model (synchronous) which sends events to a message broker (a-synchronous pub sub). If the client needs a response, how does it work with the a-synchronous messaging tier which goes on its merry way without a necessary response to the client side
you block in the middle tier while waiting for the reply.
But Pub/sub is based on the idea that you don't need a reply, and takes hacks to allow it (ie, the publisher then becomes a subscriber to the reply event while blocking). Pub/sub just anounces an event to whomever is interested. it could have zero subscribers, or hundreds, the publishe rdoesn't care. if you're expecting a reply, then the assumption is that you only have one subscriber by design, in which case pub/sub is not the correct tool for the job.
pub/sub is asynchronous, but pub/sub!= asynch. if you need a reply, use point-to-point. you can use synch or asynch with point-to-point. Most messaging systems facilitate synch and asynch point-to-point (queue based) as well as pub/sub (topic based). In the case of MQ, pub/sub requires the JMS package on top of MQ.
Thanks Jason. Very interesting. So if I have a site and I want to sign up for specific topics, are you suggesting that I NOT use messaging. What I am getting at is that I am not sure when I should substitute the function of a database and related tables with pub/sub. That is, if my data model inserts fields of interest for me and searches for such matching data, it is no different than subscribing to a topic and getting data from pub/sub. Do you know what I mean? The question is how to recognize a messaging opportunity OVER pure database searching functionality.
Regarding http, you are saying that because I require synchronous communication (which is what http is) and I want to use messaging, I should be using P2P.
Finally, if all of this is true how are people architectually using messaging within an EJB framework? Within an http based service framework?
if you're expecting a reply, then the assumption is that you only have one subscriber by design, in which case pub/sub is not the correct tool for the job
this isn't entirely true, the idea of a message broker is distribute messages to interested subscribers, and coagulate the results. The broker makes coarse grained decisions... i.e restricts the messages to a group of subscribers (i.e. a topic), the subscibers may choose to produce a responce... for example if i need price quotes on a specific item, the message is published on a topic, all subscribers who have a legal quote for the item respond to this message, in this case the primary publisher, i.e. the broker doesnot care what subscribers are there, and is potentially a listener to a queue where the primary subscribers (merchants) push the quotes, the broker blocks till a timeout event, coagulates the quotes and passes them on to the view.
Obviously using p2p here isn't the best thing to do.
So in this case you are saying the following:
1) various publishers of "car part" prices (various businesses) publish to a "car part price broker"
2) the "car part price broker" publishes all of that to a client's queue.
So here you are combining both types of messaging to solve this unique situation. However, you did not mention which parts of the architecture are synchronous and which parts are a-synchronous.
the base mechanism used in both cases is asynchronous. Synchronicity is imposed by imposing timeouts. The idea here is to cut the overhead in deciding what relevan endpoints should receive the message before transmitting the message. It becomes the choice of endpoints to pickup and respond to relevant messages depending on the system's state at any given time. Maybe a supplier is swamped with quote requests and would like to serve a limited # of requests to ensure adhereing to preset performance benchmarks, may be he can offer a better (more profitable)quote to another dealer at a given point in time... this is a complex decision set and can not be practically undertaken by a dealer backend. Thus the mode of message exchange is asynchronous, but the overall process... i.e. request a quote and receiving quotes is somewhat synchronous... every request has one big responce consisting of a set of quotes under a specified umbrella of time. the interaction between the dealer and the customer however is disconnected from this fact so it can be persued as a synchronous interaction.