4

我正在尝试使用 BizTalk 在两个 Web 服务之间进行通信。它必须是这样的：

  • Service1获取输入并通过 BizTalk 将消息发送到Service2,
  • Service2响应该消息，将其转发给 BizTalk，然后将其传递给Service1.
  • 最后Service1将响应返回给用户。

几天来我一直在努力做到这一点，但我无法在没有编译器错误的情况下构建编排，而且我找不到带有输入输入的 Web 服务和 Web 端口的单个示例。我开始相信这是不可能的，至少在 BizTalk 中是这样。

最大的问题是：有可能吗？如果是，如何？

4

1 回答 1

7

您的问题范围相当大，我想回答它可能不太适合 SO“Q+A”格式。

但是，提供由一个或多个底层 Web 服务组成的复合企业服务似乎是一种常见的需求。

我已经构建了一个快速而肮脏的示例（BTS 2010 / VS 2010），并在此处上传到 GitHub （在右下角以 zip 格式下载源代码）

这是从头开始实施此步骤的“食谱”，但我相信您需要获取要遵循的代码。

在 Visual Studio 中创建新解决方案

添加 WCF 服务项目并发布到 IIS（本示例未涵盖范围）

  • 使用默认的VS2010 WCF项目，并调用该项目WCFService
  • basicHttpBinding为简单起见，但显然可以使用其他绑定（但需要额外的考虑，例如安全性等）
  • 请注意，网络配置中的NameSpaceon ServiceContract、和已全部设置（否则这些将默认为）ServiceBehaviorbehaviour namespacetempuri

向解决方案添加 4 个新的 BizTalk 项目：

我称他们为BizTalkWCF.Orch, BizTalkWCF.Maps, BizTalkWCF.WCFPorts, andBizTalkWCF.Schemas

首先是 WCFPorts

  • 右键单击WCFPorts项目并选择“添加”，然后选择“生成的项目”
  • 选择使用 WCF 服务
  • 检查元数据交换 (Mex) 端点
  • 提供您的 WCF 服务的 URL（例如http://localhost:57582/Service.svc）
  • 离开命名空间 (BizTalkWCF.WcfPorts)
  • 完成向导 - 现在应该存在 WCF 工件
  • 如果您需要导入多个 Web 服务，我建议您为每个服务创建单独的 Visual Studio 解决方案文件夹

因为我们在 BizTalk 中拆分了项目（这通常是一个好主意），不幸的是向导会将所有导入的工件标记为内部的，如果它们是从其他程序集中引用的，这不是很有帮助。打开导入的生成编排 (MyService.odx)（注意不要删除或移动此 ODX，因为它包含生成的端口 - 只需将其与生成的 WCF 工件一起保留）。

在编排视图的底部，打开类型。在端口类型下，您应该会看到 WCF 接口 ( IService)。单击它并将属性类型修饰符更改为“公共”对多部分消息类型执行相同操作（4 x IService_* - 请注意，服务上的每个 WCF 方法有 2 x 消息类型（一个用于请求，一个用于回复）。

现在应该构建 WCF Ports 项目。

接下来是 Schemas 项目 Add 2 x Schemas 表示将从 BizTalk 公开（发布）的内容（我称它们为BizTalkServiceRequestand BizTalkServiceResponse）这个示例只是为底层 WCF 服务提供了一个薄的外观，所以我刚刚得到了类似的字段对原始WCF服务的请求和响应，同xs类型。但是请注意，基础 WCF 服务上的“实体”概念已被请求和响应消息所取代。但是，可以跨多个消息重构和重用模式 (xsd:import) 中的公共元素。我刚刚使用了默认命名空间和“根”节点，但请注意，这些对您的 BizTalk 服务使用者是可见的，因此在实际项目中您需要多考虑一下。

请注意，我们没有重用导入/生成的 WCF 服务架构。在综合企业中，还可以使用第三组模式，即“规范”模式，它们与 BizTalk 服务的消费者和消费服务使用的格式无关（并且还需要更多的映射）。

接下来是映射，在传入请求到 WCF 输入架构之间，然后是从 WCF 输出架构返回到 BizTalk 服务使用者的另一个映射。在地图项目上，添加对 WCFPorts 项目和 Schemas 项目的 .Net 引用。将新地图添加到地图项目 对于源架构找到引用的架构 - BizTalkServiceRequest 架构。对于 Destination Schema，选择 WCF Ports 模式（名称 mangled 很糟糕，但它会是带有 MyService 的那个 - 而不是 datacontracts 或 microsoft schemas 之一）。请注意，您随后需要选择需要使用的包含模式。选择GetDataUsingContract架构。在元素下，将鼠标从源 Name 元素拖到目标模式值，然后IsAddSuffix从BoolValue元素。对返回响应消息执行相同操作 - 显然这次 WcfResponse 消息是源，而公开的 BizTalk 响应是目标。布尔值在响应中没有用，因此只映射了字符串值。地图现在应该编译。

最后是编排项目

  • 添加对 Maps、Schemas 和 Ports 项目的引用
  • 添加一个新的编排（我称为 AddServiceOrchestration）。
  • 您需要添加一个接收端口（在左侧添加）和发送端口（在右侧）。
  • 发送端口使用现有的导入 WCF 端口（我们之前公开的）。我将发送请求并接收响应。
  • 端口绑定选择直接绑定，并通过过滤器表达式进行路由。
  • 对于接收端口，您需要创建一个新的端口类型 - 请求响应。接收请求，发送响应，然后再次直接绑定，通过过滤器表达式进行路由。
  • 同样，您需要公开端口
  • 您需要在接收端口上为请求和响应设置消息类型（单击请求和响应，然后在 Schemas 程序集中找到消息类型）
  • 编排中的形状应该是不言自明且简单明了的——基本上只是绑定端口以接收和发送形状，然后在变换形状中使用映射。
  • 初始接收形状是激活。

构建 + 发布

现在一切都应该构建，所以是时候发布到 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 发布为 WebService（工具：BizTalk WCF 服务发布向导）启用元数据发布。我再次使用了 basicHttpBinding。并创建接收端口，选择应用程序 (BizTalkWCFSample)

出现提示时，选择包含 Orchestrations (BizTalkWCF.Orchs) 的程序集 您还将被提示设置 WCF 服务的目标命名空间 - 记录这一点，就像您需要重新发布您的服务一样，您可能希望保留命名空间相同。

最后的位置是将在 IIS 中发布的位置。如果您不想为锁定暴露的服务安全性而烦恼，请选择“允许匿名访问”。AFAIK 无法控制自动创建的接收端口的名称。

您现在需要启动 BizTalk 应用程序 - 解决任何未解决的配置问题（例如，将 orchs 分配给进程）

您需要在 IIS 中创建一个新的 .Net 4 应用程序池（将其称为类似BizTalkIsolatedHost），
然后将在 IIS 中创建的向导移动到此应用程序池您现在应该能够导航到您的编排“端点”，例如： 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 Service Bus 等构建的 DIY 总线），可能带有用于公开 Web 服务“端点”的自定义外观
  • 对于批量“服务立面”，微软开始设计一种有前途的技术，称为托管服务引擎，但不幸的是，这似乎处于冰上。

但是，如果只有少数这样的高价值服务，特别是如果此类服务需要多个内部服务的组合和映射，或者使用不同的消费技术（SAP RFC、SQL、SOAP 等），那么 BizTalk 就很适合这项工作.

于 2013-08-03T20:48:49.917 回答