1 Reply Latest reply on Jul 31, 2007 11:01 AM by tfennelly

    Providers vs. Listeners and Configuration

      Can anyone summarize what is the difference between a provider and a listener? Am I right thinking that providers are global with the ESB, whereas listeners are "local" to a service, and tie the provider with the service?

      Why would a particular configuration exist in one, but not the other? For example, In SQL, the provider seems to define the sql-message-filter, and the listener defines the number of threads. Why not the other way around?

      Finally, why are some configuration properties defined using and others are attributes of the <xxx-listener> element? For example, I define my poll-frequency-seconds in <fs-listener>, but need to define my composer-class and composer-process in a .

        • 1. Re: Providers vs. Listeners and Configuration
          tfennelly

           

          "bsheward" wrote:
          Can anyone summarize what is the difference between a provider and a listener? Am I right thinking that providers are global with the ESB, whereas listeners are "local" to a service, and tie the provider with the service?


          Yep, that's the basic idea. Listeners listen for messages provided by a bus. There's more on this in the configuration section of the programmers guide.

          "bsheward" wrote:
          Why would a particular configuration exist in one, but not the other? For example, In SQL, the provider seems to define the sql-message-filter, and the listener defines the number of threads. Why not the other way around?


          You're dead right there. Some of the listener configurations are a bit messed up. I've actually logged JIRA issues for this and I think the SQL based configs were in that.

          "bsheward" wrote:
          Finally, why are some configuration properties defined using <property name="xxx" value="yyy" /> and others are attributes of the <xxx-listener> element? For example, I define my poll-frequency-seconds in <fs-listener>, but need to define my composer-class and composer-process in a <property>.


          Not sure about the poll-frequency-seconds and composer-class properties not being attributes (revert to your previous comment), but I can guess that the "composer-process" one was left as a property simply because it was considered to be a bad idea for the same reasons you outlined at the top i.e. that composition should be done based on an interface and therefore no need to define process methods.