Another Way to Explain BizTalk Role Links

I am working on a project where I am extending a BizTalk application so that I can route messages from a single FILE port to different BizTalk applications and various orchestrations through the use of role links. Role links are one of the less frequently used and discussed tools of an experienced BizTalk developer. Getting my mind around role links was difficult because of the number of configuration details required to setup a role link. I am indebted to Eric Stott’s blog post at http://blog.biztalk-info.com/archive/2006/10/25/BizTalk_Role_Links_explained.aspx, but I think it would seem easier to describe role links as a precursor to the WCF binding architecture. I will describe some architecture notes on role links next but to see my thoughts on how role links are like WCF, skip on down a few paragraphs.  

 

Role links are essentially the opposite of dynamic ports. A dynamic port consists of one port that then has multiple variations of configurations based on the dynamic expressions applied to this port for one adapter. A role link is a static configuration but is essentially a collection of ports of different adapters. For a dynamic port there is not always an explicit party concept; in a dynamic port a message is being sent from one organization to some other variable organization. And in a role link a message is either being sent or received and is then one of a collection of organizations for each endpoint. Role links are based on ports that are designated as being associated with some BizTalk party. The party can have one or more aliases which act as destination tokens when used with role link based routing.

 

So here are a few examples of how role links could be used:

– When you need to have dev, test, and production parties all hosted in a single BizTalk application and merely need to differentiate logic for these parties based on ports

– When you need to expose a single business process to multiple parties without creating more than one orchestration to handle all of them.

– When you need more than 1 backup port in a BizTalk application

– When you are struggling to manage so many BizTalk artifacts and are looking for a way to reduce the number of orchestrations

– When you want a lightweight built-in BizTalk routing mechanism that has a simple but flexible mechanism for specifying a routing destination.

– When you want to expose more than one adapter for some organization as connectivity options

 

This last example of a role link use helped me think about a more contemporary example of a role link. In WCF when you expose a service, it is possible to expose more than a single endpoint for a service so that the organization that connects to the service can use either HTTP or TCP or some other protocol or set of binding options to connect to the service. This is frequently used to expose a WSI basic profile service for interoperability and a WS-* or SOAP 1.2 service for newer clients as in the following example: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx. WCF provides the binding infrastructure so that it is possible for a client to have various options for connectivity. In the same way, role links provide a way to provide to a client multiple integration options that all get consumed into the same business process.

 

So role links are very similar to the binding infrastructure in WCF due to the trasnport-level flexibility both enable. If you are a BizTalk developer, you should take role links for a spin because they provide some very valuable extensibility options. It does take a while to get used to role link abstractions so I recommend taking WCF as a good example of what role links seek to accomplish and then throw adapters and parties in the mix and it makes much more sense. Have fun with role links!