一、 绑定方式 – specify later（以后指定）
这种绑定方式是在biztalk中使用最多的一种绑定方式，一般的端口绑定都是用这种方式，设计时orchestration的端口设置为“specify later”，biztalk项目部署后在biztalk控制台配置这个应用程序，新建相应的物理端口跟orchestration的端口绑定。
只是为了说明这种绑定方式，设计一个极简单的测试场景。
有一个消息，类似这样的：
<ns0:Person xmlns:ns0="http://BindingSpecifyLater.SimpleInput">
<id>id_0</id>
<name>name_0</name>
</ns0:Person>
把它放在一个In目录中，通过file适配器读取文件，进入到orchestration中，这个流程这样的：
Figure 3. specify later 测试流程
整个流程就就简单的传送一个消息，就是上面那个消息的架构，Port_Input_Person端口设置为：单向、接收、以后绑定。Port_Output_Person端口设置为：单向、发送、以后绑定。
项目部署好后，在biztalk控制台配置这个应用程序。
Port_Input_Person端口绑定一个接收端口，端口的接收位置配置为file adapter，指向预设的In目录，读取目录中的以xml为后缀的文件。
Port_Output_Person端口绑定一个发送端口，发送端口配置为file adapter，指向预设的Out目录，写消息为%MessageID%.xml文件。
Biztalk控制台提供了很方便查看已产生的订阅的方法，可以用更直观的形式反映保存在数据库中的订阅关系。
Figure 4. 查询订阅
biztalk控制台中，在左边目录树中选“Biztalk Group”，在右边的“Group Overview”面板中选择“New Query”标签，这里可以选择查询服务实例、挂起的服务实例、订阅等等。我们选择查看订阅，然后点击“Run Query”按钮，下面的窗口就会列出所有已经产生的订阅。
双击第一个订阅，这个订阅是Orchestration订阅file接收端口进来的消息：
Figure 5. Orchestration订阅接收端口
在弹出的窗口中“General”标签的是订阅主体，反映的是Subscription消息订阅表中的内容，看一下这里的内容：
Service class是订阅消息的服务类型，这里是Orchestration类型。
Service name是订阅消息的具体服务，这里是BindingSpecifyLater.BizTalk_Orchestration1, BindingSpecifyLater, Version=1.0.0.0, Culture=neutral, PublicKeyToken=380d269ec565a18c，就是上面设计的那个流程。
再看“Express”标签：
Figure 6. Orchestration订阅接收端口的订阅条件
这里反映的是这个订阅的订阅条件，就是这个订阅在PredicateGroup谓词组对应表,订阅谓词表中的内容。可以看到这里有两个条件：
Subscription：
{
ORGroup0
{
BTS.ReceivePortID == {7DA3DB40-8E1B-47DB-AF1B-078E77F19372}
AND
BTS.MessageType == http://BindingSpecifyLater.SimpleInput#Person
}
}
从这里的订阅条件可以看出，Specify Later绑定，Orchestration接收端口绑定物理接收端口时，绑定动作产生的订阅条件是：消息必须来自绑定的那个端口，消息的类型必须是Orchestration中这个接收端口的指定的消息类型。只要满足这两个条件，消息就会被路由到这个Orchestration。
4、 发送端口订阅Orchestration
在biztalk控制台，双击第二个订阅，这个订阅是file发送端口订阅Orchestration发出的消息：
Figure 7. 发送端口订阅Orchestration
“General”标签中：
Service class是订阅消息的服务类型，这里是Messaging类型，就是Messaging InProcess，表示一般的端口。
Service name是订阅消息的具体服务，这里是SendPort_binding，就是跟Orchestration绑定的发送端口。
Figure 8. 发送端口订阅Orchestration的订阅条件
“Express”标签中，显示这样的订阅条件：
Subscription：
{
ORGroup0
{
BTS. SPTransportID == {54ECBCE9-AA7F-4DB1-B2CC-B97CF5F8D4CE}
}
}
从这里的订阅条件可以看出，Specify Later绑定，物理发送端口跟Orchestration的发送端口绑定时，绑定动作产生的订阅条件是：消息中BTS. SPTransportID属性指向这个物理发送端口的一个通道（一般指向这个发送端口的基本通道）。这个绑定动作还对Orchestration的发送端口产生作用，绑定后，消息经过Orchestration的发送端口时，端口会在消息中增加这个BTS. SPTransportID属性，属性的值就是绑定的物理发送端口的基本通道的GUID。这样，从这个Orchestration的发送端口出来的消息就会被路由到绑定的物理发送端口。