web-services - 使用BizTalk Web服务重新发布内部Web服务

Question

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


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


我花了好几天的时间来努力，但是没有编译器错误我就无法构建业务流程，并且找不到包含输入内容的Web服务和Web端口的单个示例。我开始相信，至少对于BizTalk，这是不可能的。

最大的问题是：可能吗？如果是，怎么办？

Answer 1

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

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

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

这是从头开始实现此步骤的“菜谱”，但是我认为您需要获取遵循的代码。

在Visual Studio中创建新的解决方案

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


使用默认的VS2010 WCF项目，并将项目命名为WCFService
为简单起见，使用basicHttpBinding，但显然可以使用其他绑定
（但需要额外的关注，例如安全性等）
请注意，NameSpace，ServiceContract和ServiceBehavior的Web配置中的behaviour namespace都已设置（否则，它们将默认为tempuri）


将4个新的BizTalk项目添加到解决方案中：

我称它们为BizTalkWCF.Orch，BizTalkWCF.Maps，BizTalkWCF.WCFPorts和BizTalkWCF.Schemas

首先是WCFPorts


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


因为我们已经在BizTalk中拆分了项目（通常是个好主意），所以不幸的是该向导将所有导入的工件标记为内部，如果从其他程序集中引用它们则没有太大帮助。
打开导入的生成的Orchestration（MyService.odx）（NB永远不要删除或移动此ODX，因为它包含生成的端口-只需将其保留为生成的WCF工件即可）。

在业务流程视图的底部，打开类型。在端口类型下，您应该看到WCF接口（IService）。单击它，然后将属性类型修改器更改为“公共”
对多部分消息类型执行相同的操作（4 x IService_ *-请注意，服务上每种WCF方法都有2 x消息类型（一种用于请求，一种用于响应）。

现在应该建立WCF Ports项目。

接下来是Schemas项目
添加2个表示将要从BizTalk公开（发布）的架构（我将它们称为BizTalkServiceRequest和BizTalkServiceResponse）
此示例只是为基础WCF服务提供了一个较薄的外观，因此在请求和响应上，我刚刚获得了与原始WCF服务类似的字段，并且具有相同的xs类型。但是请注意，基础WCF服务上的“实体”概念已由请求和响应消息代替。但是，可以跨多个消息重构和重用模式（xsd：import）中的公共元素。
我刚刚使用了默认的名称空间和“ Root”节点，但是请注意，这些名称将对BizTalk服务使用者可见，因此在实际项目中，您需要多加考虑。

请注意，我们尚未重用导入/生成的WCF服务架构。在一个全面的企业中，也可以使用第三套模式，即“规范”模式，这些模式与BizTalk服务的使用者和已使用的服务的使用者所使用的格式无关（也将需要更多的映射）。

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

最后是业务流程项目


添加对Maps，Schemas和Ports项目的引用
添加一个新的业务流程（我称为AddServiceOrchestration）。
您需要添加一个接收端口（在左侧添加）和发送端口（在右侧）。
发送端口使用现有的导入的WCF端口（我们之前已公开）。我将发送请求并接收响应。
端口绑定选择直接绑定，并通过过滤器表达式进行路由。
对于接收端口，您需要创建一个新的端口类型-请求响应。接收请求，发送响应，然后再次通过过滤器表达式进行直接绑定。
同样，您需要公开港口
您需要在接收端口上为请求和响应设置消息类型（单击请求和响应，然后在“模式”程序集中找到消息类型）
编排中的形状应具有自我解释性和直接性-基本上只需要捆绑端口即可接收和发送形状，然后在变换形状中使用地图。
最初的接收形状是激活。


构建+发布

现在一切都应该构建，因此可以发布到BizTalk了（我假设是本地服务器）
现在，我们将使用向导发布业务流程，并将使用IIS来管理公开的Web服务，尽管请注意Biztalk也可以自托管。
请记住，在所有4个Biztalk项目的Deployment选项卡中设置Application Name（否则，它们将在默认应用程序中显示）。另外，请记住，需要对BizTalk程序集进行签名，因此请创建一个.SNK（“签名”选项卡）

右键单击解决方案，然后单击“部署”。 （请注意，必须先构建和部署项目，然后才能使用发布向导公开服务）
假设部署成功，则需要配置业务流程（另一个业务流程是由WCF导入生成的业务流程-它拥有WCF端口）
创建一个发送静态请求响应发送端口-WCF basicHttpBinding，将其指向您的WCF Web服务URL。
您可以从WCF WSDL获取SOAP操作，例如YourNameSpaceHere/IService/GetDataUsingDataContract
将过滤器添加到消息的发送端口（xmlns＃root），例如YourNameSpaceHere#GetDataUsingDataContract

回到Visual Studio，您现在可以将Orch作为WebService发布（工具：BizTalk WCF Services发布向导）。
启用元数据发布。我再次使用了basicHttpBinding。并创建接收端口，选择应用程序（BizTalkWCFSample）

出现提示时，选择包含业务流程（BizTalkWCF.Orchs）的程序集
还将提示您设置WCF服务的目标名称空间-记录下来，就好像您需要重新发布服务一样，您可能希望将名称空间保持不变。

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

现在，您需要启动BizTalk应用-解决所有未解决的配置问题（例如，将流程分配给流程）

IIS中需要一个新的.Net 4应用程序池（称为BizTalkIsolatedHost之类的东西），
然后将在IIS中由向导创建的应用程序移动到该应用程序池
现在，您应该能够导航到业务流程的“端点”，例如：
http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc

总结-值得吗？

从上面可以看到，在BizTalk中重新公开Web服务是很多工作，除了可能具有一些BizTalk跟踪和重试功能外，我们没有在BizTalk中真正增加任何价值：) 。编排组合服务时（一个传入请求需要多个后端服务调用才能完成，并且如果也使用规范的架构），将考虑更多的架构和映射，以及编排的其他复杂性。
使用网络服务时，您会得到大量的工件（方案，地图，
消息，端口等），因此严格的命名约定至关重要。

而且我们还没有考虑异常处理，重试等问题。

因此，仅是在计划以这种方式发布100项服务之前进行完整性检查，我想我们需要考虑其他技术替代方案：


BizTalk ESB工具包（特别是如果您的企业存在一定程度的通用性，并且/或者您可以控制服务使用者）
其他ESB（大众运输，NServiceBus，ServiceMix等，或基于Camel，Mule，Drools，Rabbit，Windows Service Bus等构建的DIY总线），可能具有用于暴露Web服务“端点”的自定义外观
对于大量的“服务外观”，Microsoft开始制作一种称为Managed Service Engine的有前途的技术的原型，但不幸的是，这似乎正在酝酿之中。


但是，如果只有少数这样的高价值服务，特别是如果此类服务需要多个内部服务的组合和映射，或者使用不同的消耗技术（SAP RFC，SQL，SOAP等），那么BizTalk就是正确的选择。