This section covers more of a pattern than a best practice per se, but it is still incredibly valuable to understand before designing orchestrations.
Long-running business processes are fully supported using BizTalk orchestration. A given business process may last for days, weeks, or months, depending on your requirements. However, these long-running processes may introduce problems when you want to upgrade your solution.
It's not practical (and often not even possible) to wait for all long-running processes to finish before performing an upgrade.
Most medium-to-large business process implementations are factored into multiple orchestrations rather than one large, monolithic orchestration. Multiple orchestrations such as these are used for manageability reasons, such as allowing multiple developers to work on implementing a business process and keeping the physical size of the orchestration small.
In addition, with multiple orchestrations, you upgrade one small piece of your business process rather than the entire business process. As discussed in Chapter 5, an orchestration is compiled down into a .NET assembly that must be strongly named (and therefore you can deploy one or more versions of the same assembly side by side by using the Global Assembly Cache [GAC]).
All seems great! But not quite. The natural way to invoke these child orchestrations is by using the Call Orchestration or Start Orchestration shape, which directly binds to a specific assembly ...