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="cbcye@live.com";

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》