Rhino Service Bus (RSB from now on) is using the Castle Windsor syntax to provide configuration values. The configuration settings are aimed to be administrator (operations team) friendly, and should only specify values that are important for operations. Developer settings should be specified separately from operations settings.

RSB configuration is convention based, and it will configure itself properly based on the settings provided. The following is a sample RSB configuration file.

<configuration> 
  <configSections> 
    <section name="castle" 
             type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" /> 
  </configSections> 
 
  <castle> 
    <facilities> 
      <facility id="rhino.esb" > 
        <bus threadCount="5" 
             numberOfRetries="5" 
             endpoint="msmq://localhost/starbucks.customer"
             logEndpoint="msmq://localhost/audit.queue"
             queueIsolationLevel="ReadCommitted" 
             transactional="false" 
             /> 
        <messages> 
          <add name="Starbucks.Barista" 
               endpoint="msmq://localhost/starbucks.barista" 
               transactional="false"/> 
          <add name="Starbucks.Cashier" 
               endpoint="msmq://localhost/starbucks.cashier"/> 
        </messages> 
        <security> 
          <key>f/gdDWbDqHRvpqdRbTs3mxhGdZh9qCaDrasxJGXl+5s=</key> 
        </security> 
      </facility> 
    </facilities> 
   </castle> 
</configuration>

The first part define the config section handler. As mentioned, RSB uses the Castle Windsor configuration system to handle that.

The important part in the configuration is the "rhino.esb" facility element. Inside the rhino.esb facility, there are two mandatory configuration values, <bus/> and <messages/>,  and one optional, <security/>.

The <bus/> specifies the following options:

• threadCount [mandatory] - the number of threads listening to the queue. The recommended setting is to have one thread per each core in the machine. For development, the recommended setting is 1 (to make debugging easier).
• numberOfRetries [mandatory] - the number of times the bus will retry a message before sending it to the error queue. See error handling section for more details about that.
• endpoint [optional – IOnewayBus only, required otherwise]- the queue endpoint this bus is listening to. Every bus can listen to a single queue endpoint. Currently, the bus support two endpoints types, "msmq://", using the MSMQ queuing system, and "rhino.queues"://", using the Rhino Queues system. Note that the use of endpoint type must be identical for all endpoints (that is, the endpoint specified in the <bus/> element and the endpoints specified in the <messages/> element).
• logEndpoint [optional, for use with MSMQ only] – the endpoint to forward a copy of all messages to. Used for auditing purposes. RSB does nothing more than forward to this queue. It is your responsibility to do something with the messages once they get there.
• queueIsolationLevel [optional, default to Serializable] - the isolation level for the DTC transaction that the bus is running all operations under.
• transactional [optional, for use with MSMQ only, default to true] - whatever the MSMQ queue is transactional or not. This setting is useful if you want to be able to read from a remote non transactional queue.

The <messages/> element specifies the owners of message types. Message ownership dictates two important things:

• If a consumer wants to subscribe to a message, the message endpoint will specify where the subscription request will be sent.
• If an endpoint wants to send a message, the message endpoint dictate where it will be sent to.

Each element in the <messages/> define the following:

• name - namespace of the messages belonging to a particular endpoint.
• endpoint - the owner endpoint of those messages.
• transactional [optional, MSMQ only, defaults to true] - whatever the owning queue is transactional or not.

The <security/> element is optional, and specify a Rijndael key for encrypting fields or whole messages across the wire.

Last update: 10/25/2009 10:21:23 PM