There are a lot of conflicting ideas out there regarding orchestration/logical port binding options for BizTalk server. In this post I want to provide a short description of each option and some best practices for use.
· Specify Now/Specify Later
These two are commonly referred to as Static bound ports. Both of these options will require that the orchestration port is associated with a physical port before the orchestration can be enlisted or started. The difference between the two lay in the creation of the physical port.
Specify Now requires that you specify the configuration of the physical port inside Visual Studio before the orchestration assembly is compiled. The physical port configuration is baked-into the assembly and will be created in the run-time environment automatically when the assembly is deployed. This is considered the worst port binding option as the created physical port will have the same configuration each time the assembly is deployed. Also, the name of the automatically created port is pretty ugly.
Specify Later is essentially the same in function, but the definition for the physical port is done exclusively in the BizTalk Server Administration Console. This provides more flexibility for port configuration, such as having multiple logical ports connected to the same send port or binding the logical send port to a send port group. This is the more acceptable form of static binding, but shouldn’t be overused especially in cases where subscribers are likely to change over time.
· Direct (Partner Orchestration)
This enables two different orchestration models to communicate with one another. The two orchestration ports must use the same port type. A send port in orchestration A will publish the message to the MessageBox and a receive port in orchestration B will subscribe to the message. The logical ports used for this type of communication will not be displayed in the orchestration configuration options in the BizTalk Server Administration Console. The biggest concern when using this form of binding is that the connection between the two orchestrations is static and can only be changed through modifications to each orchestration and then recompiling.
· Direct (MessageBox database)
This option provides the purest use of the publish/subscribe architecture. A logical receive port that uses this binding will have a subscription that includes only the MessageType used by the logical port operation and the conditions defined in the Filter Expression of an Activating Receive shape. This means that potentially ANY process can feed that orchestration.
A logical send port that uses this binding will publish the message and assume that there is at least one subscriber for it, but there could be many subscribers (i.e. orchestrations, send ports, or send port groups). Assuming that the right subscriptions exist; this type of send port could feed any other process.
Things to beware of: (1) Invisible Subscriptions – there’s no reliable way to see which processes will feed your orchestration or which processes your orchestration will feed; even across application boundaries. (2) “Infinite” loops –the orchestration publishes a message that creates a new instance of the same model, which will publish a message that creates a new instance of the same model…
Upsides of Direct bound to the MessageBox: (1) Very loosely-coupled design – there are no direct dependencies or static relationships between publisher and subscriber. (2) Rip and replace-ability – with appropriate project partitioning, an orchestration could be replaced without affecting upstream or downstream processes.
· Direct (Self-Correlating)
This option exists to enable “callbacks” to the parent orchestration from a child orchestration when the Start Orchestration shape is used. The parent passes an instance of the logical port as a parameter to the child orchestration during invocation; therefore providing the callback channel used by the child to send a message back to the parent later on in the process.
· Dynamic
This option only exists for send ports. Dynamic ports enable you to assign the address used for transmission of the message on an instance-by-instance basis. Typically an orchestration will include a resolution mechanism that determines the address used for that instance and assigns it to the message being published by the logical dynamic port. Logical dynamic ports are bound to physical dynamic ports which look at the previously set address information to know which adapter and address to use for transmission.
This seems like the coolest of the send options but I’ve seen a lot of overuse around the dynamic send ports (especially in the ESB toolkit). The line in the sand I use for deciding whether to use it or not is this: “Do I know the address before I get the message?” If yes, use static physical send ports and role links. If no, ask “Does the message tell me where to send?” If yes, uses dynamic send port. If no, sounds like a big problem.
The perfect example for using a dynamic send port is this: I have a form on the internet; people fill out the form and click Submit. The submitted message is received into BizTalk where some processing is done. At some point during that processing I need to create an email that is sent back to the person that submitted the original message. I can create an orchestration that looks at the email inside the submitted message and assigns it as the address used by that later send.
I hate to see addresses statically stored in custom databases or configuration files and then assigned as the address of a dynamic send port. It really just creates an extra layer of management.
I hope this helped you out on your future BizTalk endeavors, and always remember it doesn’t matter the binding option you use logical ports are only used for communication between orchestrations and the MessageBox database.