As we all know 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 word and are generally created and managed by BizTalk Administrators however the orchestration ports are created by developers. When creating new ports in orchestrations we are presented with three choices for receive ports. Send ports have a fourth option. The choices that we make in creating orchestrations have a profound effect on the performance and the flexibility of our processes, thus making the right choice is a pretty big decision.
Most organizations are making BizTalk a central part of their Service Oriented Architecture (SOA) environment, as well they should. One of the tenants of SOA dictates that loose coupling is important. Some of the port binding options are better than other in this regard. Let’s evaluate each of these options.
Specify Now – This 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 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 originally configured and may conflict with the existing ports. Early bound ports should probably only be used for “quick-and-dirty” testing scenarios while in development and will have limited application in production.
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 while its 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 (orchestration) is to be used. This would be a poor choice if for example I want to send a message to another orchestration as it will requires I/O to an external location.
Dynamic – Only available for send ports, dynamic ports allow developers the flexibility to define within the orchestration how a port is to be configured on a per instance basis. This can be useful in scenarios where you wish to send a message in some cases to an ftp site or in other cases to an email address using the same logical port. Hard coding this decision into an orchestration may be a poor design choice, but using the Business Rule Engine can provide flexibility in this design. Although it requires additional planning a better option in these situations would frequently be using 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 three options are available, 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 no need to provide a binding to the a 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 endeavor to create your BizTalk based SOA solutions.
The opinions expressed in this article reflect those of the author in his experience as a BizTalk consultant and trainer.