Dedicated Broker Setup

Topics: Technical Questions
May 18, 2009 at 5:40 PM

I'm trying to setup a distributed Broker and Messanger.  Are there any guidelines/walkthroughs how to do this?

I have two servers.  One runs the Messenger and the other the Broker.  But I can't get the config for the Broker to work.  This is the error that I'm getting:

mseTraceSrc Error: 0 : MSE Runtime is unable to connect to the catalog. Communication Exception raised in GetRuntimeServerFromCatalog : Failed to create service Uri due to error. Endpoint address may be invalid [:8990/MyCalculator]

The host URI seems to be missing.  There is no way to set the host URI in the Admin tool when configuring a dedicated Broker.

Anybody know what's causing this?


May 20, 2009 at 6:19 PM
Edited May 20, 2009 at 6:20 PM

Based on the error and some testing I did, it looks like you tried to drag & drop an Endpoint onto the Broker runtime.  The ModelViewer should prevent this since a Broker should not host endpoints (this is a bug).  Only Messenger runtime instances host endpoints.  You can recover from this by removing the endpoint associations for the broker runtime... double click your broker runtime to enter the detail screen.  Under the Related tab of the Endpoint summary view, right click on any endpoints that are listed and remove the relationship.

For configuring a dedicated Broker runtime, you'll need to fill out each of the fields in the runtime detail screen.  The only configuration that is unique for a broker runtime instance is the Listener URI and its associated binding.  This is the endpoint the broker will host that Messenger Runtimes will need to point to.  The primary restriction here is that you must specify a binding that supports Soap12, Addressing10. (i.e. WsHttp, NetTcp).


May 25, 2009 at 6:22 PM

Worked like a charm, thanks.

I have a few more questions regarding the messenger/broker setup. 
- What are the benefits of using a distributed messenger/broker setup? 
- What policies would you execute on the messenger and what policies would you execute on the broker? 
- Is the messenger some sort of router?

May 26, 2009 at 4:38 PM

The Messenger hosts endpoints that allow you to pick which resources from your imported service implementations are exposed and/or published.  Each of these endpoints can have different policies applied to enforce security requirements, message filtering, auditing, SLA measurement, etc. 

In the distributed Messenger Broker scenario, you can provide access to functionality without having to open firewalls to expose the systems implementing the functionality.  For example, if you had trading partners that you wanted to expose services to, you could have an external Messenger (in the DMZ) that hosts the virtual services and sends messages to an internal Broker. Your firewalls only need to open the port for the internal messenger broker communication channel.  The broker would then invoke the proper service implementation from inside your network.

In addition, you could have an internal Messenger that provides access to the same service implementations, but the endpoints hosted by the internal messenger would have different security policies applied.  For example, the external Messenger endpoints may use Membership & Role Providers to authenticate and authorize users while the internal Messenger endpoints would use Active Directory.  This scenario demonstrates the ability to provide different projections of your service implementations w/o having to deploy your serivce implementations in multiple locations.

Typically a policy applied to a Runtime or Endpoint is executed at the Messenger (WCF ServiceHost).  Policies applied to an OperationVersion, Resource, System Instance, or System are executed when the Broker invokes the dispatcher (WCF service client). 

As for best practices, policies that are "operation aware" (i.e. they expect to apply transformations to or interrogate known elements in a message) should usually be applied on the OperationVersion or later (Resource, Instance, System).  This is because the Messenger doesn't concern itself with specific operations.  The Broker is what rationalizes an incomming message to a specific known OperationVersion based on which endpoint the message arrived at.  Following this pattern can make it easier for you to implement your policy assertions.  For other considerations about where to apply security related policies, look at the security guide.

Hope that helps.


May 29, 2009 at 3:15 PM