2 Replies Latest reply on Nov 25, 2008 6:36 AM by kconner

    JBR Listener synchronous property vs mep attribute

    sanjoa

      Could someone clarify to me why there is a separate (untyped / undocumented) synchronous property for the jbr-listener? The actions mep attribute would in my mind be a better place to define this behavior.

      i.e.
      <service category="cat" description="desc name="aservice">

      <jbr-listener busidref="jbr.service.http" is-gateway="true"
      maxThreads="1" name="jbr.service.listener">

      </jbr-listener>
      ..


      ..

      could be configured as:

      <service category="cat" description="desc name="aservice">

      <jbr-listener busidref="jbr.service.http" is-gateway="true"
      maxThreads="1" name="jbr.service.listener">
      </jbr-listener>
      ..

      <<<<=== jbr-listener honors mep attribute
      ..


      / Joakim

        • 1. Re: JBR Listener synchronous property vs mep attribute
          sanjoa

          oops, example got truncated.

          i.e.

           <service category="cat" description="desc name="aservice">
           <listeners>
           <jbr-listener busidref="jbr.service.http" is-gateway="true"
           maxThreads="1" name="jbr.service.listener">
           <property name="synchronous" value="false"/>
           </jbr-listener>
          ..
           </listeners>
           <actions>
          ..
          


          could be defined as:
           <service category="cat" description="desc name="aservice">
           <listeners>
           <jbr-listener busidref="jbr.service.http" is-gateway="true"
           maxThreads="1" name="jbr.service.listener">
           </jbr-listener>
          ..
           </listeners>
           <actions mep="OneWay">
          ..
          


          • 2. Re: JBR Listener synchronous property vs mep attribute
            kconner

            The mep determines how the service behaves whereas the synchronous parameter determines how the gateway behaves as a client.

            It is possible for responses to be returned from other services or business processes working asynchronously from the original target service.

            The following provides a generic example of using asynchronous communications to achieve request/response behaviour.

            http://www.jboss.org/community/docs/DOC-9105