Когда сообщение покидает оркестрацию, его "OutboundTranspoprtLocation" property должна содержать URI, по которому MessagingEngine будет в состоянии сформировать полноценный вызов адаптера со всеми необходимыми ему параметрами. Например, если его значение "file://c:\FileDrops\Out", то этого достаточно, чтобы MessageEngine заключил из него, что запрашивается FILE-Adaper (по т.наз. moniker - "file://") и передать ему нужно следующим за ним адрес - "c:\...".
На этом, собственно, можно было бы и остановиться с динамической конфигурацией, если бы не оригинальный способ назначить "OutboundTransportLocation" property из оркестрации.
XLANG компилятор, придерживается того правила, что если динамический порт присутствует в оркестрации, он должен быть назначен. Из этого правила следует, что присвоения вида
Message_out(BTS.OutboundTransportLocation) = @"file://c:\FileDrops\Out";
из Assignment Shape не решают не разрешают неопределенности компилятора относительно динамического порта, хотя, с точки зрения Messaging, вполне достаточны. В чём логика этого ограничения компилятора?
Помимо очевидного внимания, которого требует ситуация с неопределенным динамическим портом в run-time, компилятор предусматривает возможность того, что через такой порт может пройти много разных сообщений. Вместо того, чтобы проверять для каждого из них правильность заполнения "OutboundTransportLocation" property, назначение адреса самого порта
Port_Out(Microsoft.XLANGs.BaseTypes.Address) = @"file://c:\FileDrops\Out";
гарантирует, что любое сообщение, проходящие через динамический порт, прежде чем покинуть оркестрацию, получит требуемый property самим фактом его связи со сконфигурированным портом.
Достойная забота и о run-time, и о возможных разветвлениях в оркестрации, однако остается открым вопрос о том, как можно назначить динамический порт в сценариях без оркестраций.
MS ESB Guidance (Dynamic Resolution sample) предлагает receive pipeline component - ESB Dispatcher, который читая свои per-instance properties, выставляет "OutboundTranspportLocation" и "OutboundTransportType" properties полученного сообщения.
Заметим попутно, что этот component использует для динамического назначения порта созданный в P&P Resolver. Этот, в свою очередь, может создавать любые monikers для существующих адаптеров, использовать для этого BRE, XPath (т.е. читать конфигурацию из самого сообщения). Особенно интересно, что ESB Dispatcher может исполнить Map, дополнительно к Inbound Maps ReceivePort'a.