Making the Righ Port Binding Choice by John Callaway
Many organizations are making BizTalk a central part of their Service Oriented Architecture (SOA) environment. One of the tenants of SOA dictates the importance of loose coupling. Some of the port binding options are better than others in this regard. In this article we will evaluate each of the different port binding options that BizTalk provides.
As we all know by now, BizTalk provides two core functionalities. The Message engine which is responsible for routing messages and the Orchestration engine which provides the execution environment for processing orchestrations. Messaging ports are BizTalk’s connection to the outside world and are created and managed by BizTalk Administrators. Orchestration ports are created by developers. When creating a new receive port within an orchestration, you have three different choices. When creating a new send port, you have a fourth choice. Each of these choices can have a profound effect on the performance and the flexibility of a business process.
Specify Now – This type of port binding is frequently referred to as early bound. The principal benefit of early binding is that the process of creating the physical (messaging) port happens when the assembly containing the orchestration is deployed thus avoiding the extra step of port creation. Of the different binding choices this is the most tightly coupled, and therefore from an SOA perspective, the weakest choice. Although changes to these ports can be made after deployment (for that matter they can even be totally replaced) when redeployment occurs the ports will be recreated as they were originally configured and this may cause a conflict with the existing ports. Early bound ports should probably only be used for “quick-and-dirty” testing scenarios during development and will have limited application in a production environment.
Specify Later – In scenarios where the developer knows in advance that communication outside of BizTalk, to a queue, another application, or a database is required, late bound ports provide a better option over early bound ports. When using late bound ports the boundary between implementation and instrumentation is maintained. The developer defines only the communication pattern, one or two way, and it is left to the administrator to configure the physical port for endpoint communication. This option while more loosely coupled still assumes prior knowledge of how the component (the orchestration) is to be used. This would be a poor choice if for example it was necessary to send a message to another orchestration as it requires communication to an external destination.
Dynamic – Only available for send ports, dynamic ports provide developers with the flexibility to define how a port is to be configured on a per instance basis within the orchestration. This can be useful in scenarios where you wish to send a message to an ftp site or to an email address using the same logical port. Hard coding this decision into an orchestration may be a poor design choice, but implementing the Business Rule Engine can provide more flexibility in this design. Although it requires additional and configuration a better solution in these types of scenarios might be the use of role-links.
Direct – Our final port choice is the most loosely coupled and most flexible, though it can be difficult to use correctly. When selecting direct-bound ports you have three options: orchestration-to-orchestration, self-correlating, and direct bound to the message box. From an SOA perspective ports directly bound to the message box are often the “best” choice. When orchestration ports are direct bound, there is no need to provide a binding to the physical port. It is still necessary to create the physical port, but these ports simply deliver the message to the Message box. The messaging engine uses the correlation set(s) or filter defined on the receive shape along with the message type to determine the subscription. This design allows for flexibility in design since there is no explicit coupling between the logical and physical ports. Care should be taken when choosing direct bound ports as it is very easy to get into a endless loop situation. Coincidentally this design also supports some of the other SOA tenants such as contract first and explicit boundaries.
I hope that this review of the various port binding options and a discussion of the various benefits of each, (SOA speaking at least) will assist you as you with your BizTalk SOA solutions.
The opinions expressed in this article reflect those of the author in his experience as a BizTalk consultant and trainer.
John has more than 9 years of experience developing enterprise-level applications and teaching advanced courses based on Microsoft products and technologies. John works for QuickLearn.

QuickLearn's BizTalk Server 2006 Training Curriculum
Go straight to the source and get BizTalk training from the company who developed the official BizTalk Server 2004/2006 courseware for Microsoft. We teach more BizTalk training than anybody in the world. To date, we have taught more than 2000 developers how to develop and deploy BizTalk integration and business process automation solutions. Our instructors are experienced BizTalk Server developers and the best trainers in the industry.
Here are the BizTalk Server 2006 courses we currently offer:
BizTalk Server QuickStart (for new BizTalk developers).
BizTalk Server DeepDive (for experienced BizTalk developers).
Building Service-Oriented Solutions with BizTalk (business application developers).
QuickLearn can deliver onsite training at your facilities anywhere in the world. Click here for more information.
BizTalk 2006 R2 WCF First Look Video
Take a look at some of the new features of BizTalk 2006 R2. I have put together a short video covering some of the basics of WCF in BizTalk 2006 R2. Be one of the first to view the video though this link.
HELP! BizTalkGurus.com Forums Needs your support!
It has been a busy few weeks on the BizTalkGurus.com Forum board. In just the past week we have had over 40 new threads and nearly 100 posts and that's just in the BizTalk 2006 category! I make every effort to ensure posts do not go unanswered.
We would like to thanks everyone who contributed to the forum this year! Special thanks to our top members greg.forsythe (with over 500 posts!), nwalters, tomast, rseroter, Nar_BTS, cell, eladr, and CodeCola!
If you want to get involved, it is easy to sign up and anonymous posting is allowed. Check out our forum at http://www.biztalkgurus.com/forums/default.asp
Updated BizUnit Extensions
Santosh Benjamin has released an updated version of the BizUnit Extensions. It is targeted to BizTalk 2004. Get more information on the CodePlex download site. If you have not looked at using BizUnit for automated unit testing, now is a great time to do so. It can be a huge time saver!
BizTest 2.0 Automated Testing Software
To continue on the automated unit test theme... Donware has released BizTalk 2.0 Professional to help create automated functional and integration test for BizTalk related scenarios. A free 30-day trail edition is available at http://www.donware.com/
Comments or Suggestions?
I welcome comments, questions, and suggestions. After all, this newsletter is about delivering content you want to hear about! Feel free to contact me through the forum or via e-mail.
Until next time...
Stephen W. Thomas -
BizTalkGurus.com
The Bottom Line:
When all else fails, just head to China. |