BizTalk本质上是异步的消息处理引擎。BizTalk的请求与响应模式是基于异步之上的同步消息交换。消息引擎通过消息的扩展架构链接许 多异步消息，消息的相关集关联请求与响应消息。例如,客户端发送一个SOAP请求到BizTalk SOAP适配器。连接该Web Service的BizTalk Orchestration接收处理消息。并返回一个SOAP响应消息。对于客户端程序来说是一个同步的SOAP请求。但在引擎内部则是通过并联交换许多 的异步消息来实现。
以下是请求-响应模式中的五个架构属性：
- BTS.CorrelationToken 允许响应消息路由到请求-响应端口。
- BTS.EpmRRCorrelationToken 用于内部的消息引擎指定请求-响应消息流的服务器名称，处理ID和唯一的GUID。
- BTS.IsRequestResponse 指定是否是请求-响应消息
- BTS.ReqRespTransmitPipelineID
- BTS.RouteDirectToTp 用于内部消息引擎允许循环回调请求-响应消息。
基于以上介绍大概了解了双向端口（请求-响应模式）在BizTalk内部的交换原理，我们的想法是通过单向端口来实现双向端口的功能，理论上大体 是这样的：创建一个单向端口接收来自Web Service的请求，在Orchestration中通过消息属性订阅消息，Orchestration接到消息之后处理消息，比如创建一个同样的消息 （拷贝相应的属性），并修改相应字段的值。新的消息通过发送形状发布到MessageBox中，并初始化相关集。消息引擎根据消息的相关集设置将消息返回 给请求与响应端口。
下图是根据理论分析创建的流程图,流程图非常的简单，接收与发送端口都是使用Direct端口类型Receive接收形状使用Filter从Messagebox从MessageBox订阅消息。Send发送形状则是将消息发布到Messagebox。
在Construct New Message形状里的表达式语句如下，通过创建新的消息并指定相关集的值。
System.Diagnostics.EventLog.WriteEntry("TwoWayDemo","Begin Process
");
OutMsg = InMsg;
OutMsg(*) = InMsg(*);
OutMsg.Body.Field="[email protected]";
OutMsg.Header.State="Completed";
OutMsg(BTS.RouteDirectToTP)=true;
System.Diagnostics.EventLog.WriteEntry("TwoWayDemo","Completed Process");
BizTalk项目部署之后需要将Schema发布为Web
Service.并在BizTalk应用程序中创建接收端口，由于Orchestration是通过属性订阅消息所以需要在SOAP接收位置中使用XML
Receive Pipeline。最后我们通过soapUI测试Web
Service可以看到我们的SOAP请求已经的成功的被Orchestration处理并返回处理结果。
总结
以上简单的Demo涉及到的BizTalk相关知识比较多比如发布/订阅机制，相关集，SOAP 适配器的使用等。不过理解该Demo相信对于BizTalk的架构领会是一个不小的跨越。最后说明一点这里所指的单向端口是指Orchestration中的单向端口。Web Service发布的端口是双向的。
参考资料
《Microsoft BizTalk 2006 R2 Documentation》
《ESB Guidance Documentation》