1 2 Previous Next 27 Replies Latest reply on Mar 28, 2008 5:51 AM by kconner

    Features of JBoss Messaaging Message Bridge present in ESB p

    dsmiley

      The JBoss Messaging Message Bridge is pretty cool:
      http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/bridge.html

      If I have an ESB service with a JMS input (gateway) and a JMS output (via JMSRouter), then obviously I gain lots of abilities like message transformation but do I retain the same fault tolerance found in the JMS Bridge with the same QoS configuration options? If you don't know what I'm talking about check out the link above; it's a quick read.

      I'm hoping there is similar robustness in the ESB. If not, I suppose I could chain bridges onto both ends with a couple queues but that's kind of a hack.

        • 1. Re: Features of JBoss Messaaging Message Bridge present in E
          beve

          Hi,

          I believe you can get the same fault tolerance by configuring your connection factory, queue and JMSRouter. By configuring the queue as clustered and using a clustered connection factory this should be possible.
          Take a look at the configuration options for JMSRouter:

          JMS Routing Action Processor.
          
          Sample Action Configuration:
          
           <action class="org.jboss.soa.esb.actions.routing.JMSRouter">
           <property name="jndiName" value="queue/A"/>
           </action>
          
           Option properties (default values shown):
           <property name="unwrap" value="false"/>
           <property name="jndi-context-factory" value="org.jnp.interfaces.NamingContextFactory"/>
           <property name="jndi-URL" value="127.0.0.1:1099"/>
           <property name="jndi-pkg-prefix" value="org.jboss.naming:org.jnp.interfaces"/>
           <property name="connection-factory" value="ConnectionFactory"/>
           <property name="persistent" value="true"/>
           <property name="priority" value="javax.jms.Message.DEFAULT_PRIORITY"/>
           <property name="time-to-live" value="javax.jms.Message.DEFAULT_TIME_TO_LIVE"/>
           <property name="message-prop->prop-name<="> value="prop-value<" />
          


          Or if you have other requirements please specify them and we'll take a look.

          Regards,

          /Daniel

          • 2. Re: Features of JBoss Messaaging Message Bridge present in E
            dsmiley

            In my case, neither end of the queues are a JBoss Messaging implementation but I'm not convinced at all that even in that case, it settles the issue.

            What will happen in the ESB if the destination queue is unavailable or the ESB crashes suddently? Obviously some error and/or exception would end up being logged but what would the state of the service & message be? This is where those QoS options for the bridge come in and I don't know which, in-effect, are the case for the ESB. If the ESB acknowledges message from the JMS gateway before any action processing begins, then your are offering QOS_AT_MOST_ONCE semantics. A quick look at JmsEndpoint.java suggests to me that is what is happening but I'd appreciate confirmation on this matter from JBoss. If you don't acknowledge until the service is done, then you are offering QOS_DUPLICATES_OK semantics. That in particular is the level I'd like if I could get it but it appears I'm SOL for now. Finally, if you do the whole thing under JCA then you offer QOS_ONCE_AND_ONLY_ONCE. I see that there are configuration options reflecting that the JMS gateway is transacted, but there appears to be no follow-through in the JMSRouter to get an end-to-end transaction. I'm not an expert on this matter so perhaps it's really there but I just don't know it.

            For my needs... I definitely don't want the message being lost.

            A related question i have is what if an action produces an exception... what happens then? I'm hoping there's some built-in retry mechanism.

            This is something that should be prominently documented because it's an important matter for enterprise middle ware, IMO.

            • 3. Re: Features of JBoss Messaaging Message Bridge present in E
              timfox

              I concur with dmiley.

              Depending on the order in which ESB acknowledges the message from source and sends to destination come in, you will get either an "at most once" or "dups_ok" delivery guarantee.

              For a "once and only once" delivery guarantee the ack and the send need to be in the same transaction.

              If the source and destination are handled by the same resource manager then that transaction can be a simple local jms tx, otherwise it would need to be a JTA tx.

              All the above cases are handled by the JBM bridge. I'm not clear they are handled by the ESB router.

              I would consider guaranteed delivery (once and only once) to be a very common requirement for bridging.

              • 4. Re: Features of JBoss Messaaging Message Bridge present in E
                timfox

                I'd avoid re-inventing the wheel, and leverage what we already have (bridge) for JMS routing.

                • 5. Re: Features of JBoss Messaaging Message Bridge present in E
                  beve

                  Sorry my bad...the JMSRouter cannot be used in such a situation.

                  The way we are currently doing this is using the jms-jca-provider to have a global transaction for an action pipeline. So the message acknowledgement is handled by the commit of the transaction. If we rollback the transaction the message will be redelivered.
                  But this only handles the incoming message. Not the part of sending out.

                  /Daniel

                  • 6. Re: Features of JBoss Messaaging Message Bridge present in E
                    kconner

                    You already have the ability to make this transactional within the ESB so it is not necessary to use the messaging bridge.

                    There is also no 'reinventing' going on here as we are just using standard JTA and JMS APIs.

                    • 7. Re: Features of JBoss Messaaging Message Bridge present in E
                      kconner

                       

                      "beve" wrote:
                      But this only handles the incoming message. Not the part of sending out.

                      This is not true, the outgoing message will also be covered by the transaction.

                      The original 'transacted' notion has recently been tidied up to look at the current transactional context and not the EPR information.

                      • 8. Re: Features of JBoss Messaaging Message Bridge present in E
                        beve

                        Ah, cool. Is this in the main trunk or in one of the branches?

                        Thanks,

                        Daniel

                        • 9. Re: Features of JBoss Messaaging Message Bridge present in E
                          timfox

                          It's up to you.

                          You'll find the bridge has other nice features like message batching - being able to specify a batch size and a max batch time. I.e. send a batch every 10 seconds and/or every 1000 messages.

                          It also has reconnect functionality which makes it very useful over an unreliable WAN. We have lots of users/customers currently using it.

                          Also bear in mind that some JMS providers don't provide an XA resource implementation that can be used outside their app server, so you won't be able use a JTA transaction, in which case having fine grained control over your qos becomes important so users can do stuff like duplicate detection at the end in order to get an effective "once and only once" guarantee.

                          • 10. Re: Features of JBoss Messaaging Message Bridge present in E
                            kconner

                             

                            "beve" wrote:
                            Ah, cool. Is this in the main trunk or in one of the branches?

                            It's in both CP and trunk at the moment. There is one more task to be completed by tomorrow though, the SQL integration has to be reverified.


                            • 11. Re: Features of JBoss Messaaging Message Bridge present in E
                              timfox

                              Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end.

                              This can often be much faster than using XA and gives the same overall reliability guarantee, but in order to do that you need to know that the bridge always sends the message on before acking it to the source (i.e. dups_ok) so in case of failure you know you will never lose any messages but may get duplicates. So fine grained qos control is useful there.

                              Then you might have other uses who never want duplicate messages, but don't mind losing a few - this is "at most once" delivery in messaging terminology.

                              • 12. Re: Features of JBoss Messaaging Message Bridge present in E
                                timfox

                                So I guess users have a choice - they can use the esb router if it suits their needs, or just use the bridge if they want more flexible QoS settings, batching and reconnection.

                                • 13. Re: Features of JBoss Messaaging Message Bridge present in E
                                  kconner

                                   

                                  "timfox" wrote:
                                  It's up to you.

                                  Handling transactional JMS messages is a requirement of ours, this naturally comes out of it.

                                  "timfox" wrote:
                                  You'll find the bridge has other nice features

                                  It has lots of cool features and it is a different beast from the ESB. The ESB also has other cool features not available in bridging :)


                                  • 14. Re: Features of JBoss Messaaging Message Bridge present in E
                                    kconner

                                     

                                    "timfox" wrote:
                                    So I guess users have a choice - they can use the esb router if it suits their needs, or just use the bridge if they want more flexible QoS settings, batching and reconnection.


                                    Not quite how I would put it but I do agree with the choice ;)

                                    1 2 Previous Next