Pub/Sub Message Contents Common Practice


General J2EE: Pub/Sub Message Contents Common Practice

  1. Pub/Sub Message Contents Common Practice (2 messages)

    I have a need for my application to send a notification message (to a JMS topic) after the completion of each work use case. I.e, ExecuteTrade, StoreTrade, etc. that is executed within my EJB tier. (I will implement a two phase XA commit across the database and Topic.)

    However, in the message to the subscribers, what relavant information is usually (by common practice) included? Given the above example, all information on a given trade? Or just key id's? Id's to which the subscribers can query the EJB tier for necessary information.

    Is it common practice to:

    (1) Commit work within EJB and then send a short message to the Topic. I.e., <cmd type="ExecuteTrade" id="324"/> This implies that any receivers who would be interested in the trade would a. consume message, then b. query the EJB tier (perhaps through a webservice) to get all details regarding the trade.

    or is it better to

    (2) Commit work within EJB and then send a *detailed* message to the Topic to which all receivers could then process the contents without further querying of any EJB tier. I.e., <cmd type="ExecuteTrade" id="324"><data parm="1"../><data parm="2"../></cmd>. (I think security concerns would become an issue here with sensitive data.)

    In other words, in either scenario are there glaring reasons why I would not implement one or the other? Like anything there are tradeoffs and I am sure there are implementations that examplify both, but for performance reasons, I am leaning towards option #1.

    Any insight or pointers to messaging best practices (based upon content. I.e., SOAP-formatted async messages, etc.) would greatly be appreciated.


    Threaded Messages (2)

  2. Ah .. Push vs. Pull[ Go to top ]

    In my research I found integration pattern information on Push vs Pull models.
  3. Its common to include the data you have to hand when you are sending the message to avoid all the consumers having to re-query the database again.

    If you are publishing to some external system, it may not be given access to your database directly so you probably want to include all the information for the trade.

    If you send IDs only then each subscriber has to hit your database and do the same query which if you have lots of subscribers is not very scalable.