你的问题范围相当大，我想回答它可能不太适合SO“Q+A”格式。
然而，提供由一个或多个底层 Web 服务组成的复合企业服务似乎是一种常见的需求。
我构建了一个快速而肮脏的示例（BTS 2010 / VS 2010），并上传到 GitHubhere https://github.com/nonnb/BizTalkWCFSample（在右下角下载 zip 源代码）
这是从头开始实现这一点所采取的步骤的“食谱”，但我相信您需要获取要遵循的代码。
在 Visual Studio 中创建新的解决方案
添加 WCF 服务项目并发布到 IIS（本示例未涵盖范围）
- 使用默认的VS2010 WCF项目，并调用该项目
WCFService
- Used
basicHttpBinding为了简单起见，但显然可以使用其他绑定
（但需要额外的考虑，例如安全性等）
- 请注意，
NameSpace on ServiceContract, ServiceBehavior，并在网络配置中behaviour namespace已全部设置（否则这些将默认为tempuri)
将 4 个新的 BizTalk 项目添加到解决方案中：
我已经给他们打电话了BizTalkWCF.Orch, BizTalkWCF.Maps, BizTalkWCF.WCFPorts, and BizTalkWCF.Schemas
首先是 WCFPorts
- 右键单击
WCFPorts项目并选择“添加”，然后选择“生成的项目”
- 选择使用WCF服务
- 检查元数据交换 (Mex) 端点
- 提供您的 WCF 服务的 URL（例如
http://localhost:57582/Service.svc)
- 保留命名空间 (BizTalkWCF.WcfPorts)
- 完成向导 - WCF 工件现在应该存在
- 如果您需要导入多个 Web 服务，我建议您为每个服务创建单独的 Visual Studio 解决方案文件夹
因为我们已经在 BizTalk 中拆分了项目（这通常是一个好主意），不幸的是向导会将所有导入的工件标记为内部工件，如果从其他程序集引用它们，则这不是很有帮助。
打开导入的生成的 Orchestration (MyService.odx)（注意，切勿删除或移动此 ODX，因为它包含生成的端口 - 只需将其与生成的 WCF 工件一起保留）。
在编排视图的底部，打开类型。在端口类型下，您应该看到 WCF 接口（IService）。单击它并将属性类型修饰符更改为“公共”
对多部分消息类型执行相同的操作（4 x IService_* - 请注意，服务上的每个 WCF 方法有 2 x 消息类型（一种用于请求，一种用于响应）。
现在应该构建 WCF Ports 项目。
接下来是 Schemas 项目添加 2 x 模式，代表将从 BizTalk 公开（发布）的内容（我将它们称为BizTalkServiceRequest and BizTalkServiceResponse）
此示例只是在底层 WCF 服务上提供了一个简单的外观，因此我在请求和响应上获得了与原始 WCF 服务类似的字段，具有相同的 xs 类型。但请注意，底层 WCF 服务上的“实体”概念已被请求和响应消息所取代。然而，可以跨多个消息重构和重用架构 (xsd:import) 中的公共元素。
我刚刚使用了默认命名空间和“根”节点，但请注意，这些对 BizTalk 服务使用者是可见的，因此在实际项目中，您需要更多地考虑这一点。
请注意，我们没有重用导入/生成的 WCF 服务架构。在综合性企业中，还可以使用第三组模式，即“规范”模式，它们与 BizTalk 服务的使用者和所消费的服务所使用的格式无关（并且还需要更多映射）。
接下来是地图，在传入请求到 WCF 输入架构之间，然后将响应从 WCF 输出架构返回到 BizTalk 服务使用者的另一个映射之间。
在地图项目上，添加对 WCFPorts 项目和 Schemas 项目的 .Net 引用。
将新地图添加到地图项目
对于源架构，找到引用架构 - BizTalkServiceRequest 架构。
对于“目标架构”，选择“WCF 端口架构”（名称被修改得很糟糕，但它将是带有 MyService 的架构 - 而不是数据契约或微软架构）。请注意，您随后需要选择需要使用的包含模式。选择GetDataUsingContract架构。在元素下，将鼠标从源名称元素拖动到目标架构值，然后从IsAddSuffix to the BoolValue元素。
对返回响应消息执行相同的操作 - 显然，这次 WcfResponse 消息是源，公开的 BizTalk 响应是目标。布尔值在响应中没有用，因此仅映射字符串值。
地图现在应该可以编译了。
最后是 Orchestration 项目
- 添加对 Maps、Schemas 和 Ports 项目的引用
- 添加一个新的 Orchestration（我称为 AddService Orchestration）。
- 您需要添加接收端口（添加在左侧）和发送端口（添加在右侧）。
- 发送端口使用现有导入的 WCF 端口（我们之前公开的）。我将发送请求并接收响应。
- 端口绑定选择Direct Binding，并通过过滤表达式进行路由。
- 对于接收端口，您需要创建一个新的端口类型 - 请求响应。接收请求，发送响应，然后再次直接绑定，通过过滤器表达式进行路由。
- 同样，您需要将端口公开
- 您需要在接收端口上设置请求和响应的消息类型（单击请求和响应，然后在架构程序集中找到消息类型）
- 编排中的形状应该是不言自明且简单的 - 基本上只是绑定端口来接收和发送形状，然后在变换形状中使用映射。
- 初始接收形状是激活。
构建+发布
现在一切都应该构建完成，因此是时候发布到 BizTalk （我假设有一个本地服务器）
现在，我们将使用向导发布编排，并使用 IIS 来呈现公开的 Web 服务，但请注意，Biztalk 也可以自行托管。
请记住在所有 4 个 Biztalk 项目的“部署”选项卡中设置应用程序名称（否则它们将出现在默认应用程序中）。另外，请记住，BizTalk 程序集需要签名，因此创建一个 .SNK（签名选项卡）
右键单击该解决方案，然后单击“部署”。 （注意，必须先构建+部署项目，然后才能使用发布向导公开服务）
假设部署成功，您需要配置编排（另一个 Orch 是由 WCF 导入生成的 - 它拥有 WCF 端口）
创建发送静态请求响应发送端口 -WCF basicHttpBinding，将其指向您的 WCF Web 服务 URL。
您可以从 WCF WSDL 获取 SOAP 操作，例如YourNameSpaceHere/IService/GetDataUsingDataContract将过滤器添加到消息的发送端口 (xmlns#root)，例如，YourNameSpaceHere#GetDataUsingDataContract
回到 Visual Studio，您可以现在将 Orch 发布为 Web 服务（工具：BizTalk WCF 服务发布向导）
启用元数据发布。我再次使用 basicHttpBinding 。并创建接收端口，选择应用程序（BizTalkWCFSample）
出现提示时，选择包含业务流程的程序集 (BizTalkWCF.Orchs)
系统还会提示您设置 WCF 服务的目标命名空间 - 保留此记录，就好像您需要重新发布服务一样，您可能希望保持命名空间相同。
最后的位置就是它将在 IIS 中发布的位置。如果您不想为锁定公开的服务安全性而烦恼，请选择“允许匿名访问”。
AFAIK 无法控制自动创建的接收端口的名称。
您现在需要启动 BizTalk 应用程序 - 解决任何突出的配置问题（例如，将 orch 分配给进程）
您需要在 IIS 中建立一个新的 .Net 4 应用程序池（将其命名为BizTalkIsolatedHost),
然后将向导在 IIS 中创建的应用程序移至此应用程序池
您现在应该能够导航到您的 Orchestration“端点”，例如：http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc
总结一下——这一切都值得吗？
从上面可以看出，在 BizTalk 中重新公开 Web 服务需要大量工作，而且除了可能拥有一些 BizTalk 跟踪和重试功能之外，我们还没有真正在 BizTalk 中添加任何价值:) 。在编排组合服务时（一个传入请求需要多个后端服务调用才能完成，并且如果还使用规范模式），将需要考虑更多的模式和映射，以及编排的额外复杂性。
当使用 Web 服务时，您会获得大量工件（模式、地图、
消息、端口等）非常快，因此严格的命名约定至关重要。
我们还没有考虑异常处理、重试等问题。
因此，在计划以这种方式发布 100 个服务之前，只需进行一次健全性检查，我想我们需要考虑其他技术替代方案：
- BizTalk ESB 工具包（特别是如果您的企业中有一定程度的通用性，和/或您可以控制服务使用者）
- 其他 ESB（Mass Transit、NServiceBus、ServiceMix 等，或基于 Camel、Mule、Drools、Rabbit、Windows 服务总线等构建的 DIY 总线），可能具有用于公开 Web 服务“端点”的自定义外观
- 对于批量“服务外观”，微软开始制作一项有前途的技术原型，称为托管服务引擎 http://msdn.microsoft.com/en-us/magazine/dd727511.aspx但不幸的是，这似乎被搁置了。
但是，如果只有少数这样的高价值服务，特别是如果此类服务需要组合和映射多个内部服务，或者使用不同的消费技术（SAP RFC、SQL、SOAP 等），那么 BizTalk 就适合这项工作。
