The glossary in the help file describes role links as "The relationship between roles defined by the message and port types used in the interactions in both directions". Hmmm...that sort of hurts my head.
What role links are useful for is to abstract your business process from your trading partner or a disparate system. For example, let's say that I have a feed that comes out of my backend system, and the business process is the same for 25 vendors. Some of the vendors need this feed in a flat file, some need it in XML, some FTP, some HTTP...you get the picture. Now, there are ways to implement this with dynamic mapping, dynamic ports, a bunch of If statements, etc. But, it is tough to maintain, if a trading partner updates their process and can now receive messages through a web service, there is rework involved in our orchestration.
One way we can handle this is through role links. It is a misconception by some that role links are tied to BAS. Business Activity Services sort of consists of 2 parts. For one, it gives a non-technical business user a nice, safe way to manage the interaction with trading partners (configuring ports, transport URI's, etc.). This works in theory. It has some limitations, as you can't set any port level maps through the sharepoint interface for instance. But, anything you need to do for role links, you can implement through BizTalk explorer. The other part of BAS is the ability to set up service agreements with our partners. Things like if a purchase order limit is > $1000, we have to send it to a special approval department. The service agreements would rely on BAS (and therefore Sharepoint) to implement.
So, back to our example, how do role links help us? There are a couple of parts to get role links to work. Keep in mind there are several orders in which you can do the following, and the following would be for an outbound role link.
First we need to create a port type as ultimately we do need to send out a message. We can create the port type within the orchestration view window, and we need to point the port type to a message.
Next we will create a new role link type in the orchestration view, add a role to it, and assign our new port type to the role. So, let's say we had to send purchase orders out for approval, and different approvers were assigned to specific vendors. We could have a port type that referenced a PO message. Our role link type could be "Purchasing" and our role could be "Approver".
We now have a role link type that contains a role (Approver) that points to a port type that handles PO messages. We're part of the way there. Now we are going to create an actual role link. Right click on the port surface and choose "New Role Link" to bring up the role link wizard. Since we have already created our role link type, you can go ahead and select that. In the next step, select that we will be sending the first message (therefore consuming a service - the Approver can be thought of as a service).
We're almost there now. In BizTalk explorer, you can now create your actual ports, setting the URI, transport types and maps, etc. We also need to create a party at this point. The party is the other half of our role link. For those of us familiar with earlier versions of BizTalk, the party is sort of like the Organization used to be. We can set up identifiers, like organization name = SupplierA. We can also specify ports that this party can use. You will notice in the BizTalk Explorer that we have our role listed under Roles. Now that we have created a party, we can right click on our role and enlist a new party to allow it to make use of that role.
This is the key piece to the whole puzzle. Within your orchestration, you are going to have a step that will initialize the role link to be associated with the partner. Basically what is going to happen is based on some value in your message, you will tell BizTalk to figure out who the party is. Based on the value you pass in, BizTalk will determine the party, and determine the port to use (because you set the port when you created the party), and it will link that port, in essence, to the role link. So, in some sense it is similar to a dynamic port.
I know the details are a little confusing because there are a lot of separate pieces and types pointing to other types, etc. But, I will post an example showing what I have described above. I think reading through this, and poking around the example, you will start to see how all the pieces relate to each other. The definition in the glossary might even make some sense. Keep in mind that once it's all set up, you can edit a party to use a different port (which could use a different transport method, etc), you can add new parties if you get additional trading partners, or remove some that no longer exist, etc. Our orchestration is done and doesn't have to be changed, we can manage it all through the physical ports and partners.
I will post a link to an example in the next couple of days. Please let me know if you have any questions.