The following BizTalk orchestration is wrong for more reasons that I can count. Basically it is a wrapper, which ensures that we only have a specific number of sub orchestrations running in parallel at a given time to avoid crashing a subsystem.
The obviuos question is, why not just create a seperate host and throttle it appropriatly? That is one of the main reasons they exist in the first place. Or perhaps choose a more low-level .Net approach and adjust ConnectionManagement/maxconnection in the BTSNTSvc.exe.config? Unfortunately this did not solve the issues, because the sub orchestration had to call several services in a very particular way and order (looong story).
So although it seems like a very wrong path to go, in this exact scenario and given a lot of restrictions and other challenges, it worked really really well. This just shows that it might be good to have common best practices for various challenges, but that you never should stop using your common sense and be prepared to create some weird stuff from time to time. And in this case it almost looks artistic 🙂