使用BizTalk Web Service重新发布内部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 (在右下角下载源代码为zip)

这是从头开始实施此步骤的"烹饪手册",但我相信您需要获取要遵循的代码.

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

添加WCF服务项目并发布到IIS(此示例中未涵盖的范围)

• 使用默认的VS2010 WCF项目,并调用该项目 WCFService
• 用于basicHttpBinding简单,但显然可以使用其他绑定(但需要其他问题,如安全性等)
• 请注意,NameSpaceon ServiceContract,ServiceBehavior和在web配置中behaviour namespace都已设置(否则这些将默认为tempuri)

在解决方案中添加4个新的BizTalk项目:

我已经打电话给他们BizTalkWCF.Orch,BizTalkWCF.Maps,BizTalkWCF.WCFPorts,和BizTalkWCF.Schemas

首先是WCFPorts

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

因为我们已经在BizTalk中拆分了项目(这通常是一个好主意),不幸的是,向导会将所有导入的工件标记为内部,如果从其他程序集引用它们则不是很有用.打开导入的生成的Orchestration(MyService.odx)(NB永远不会删除或移动此ODX,因为它包含生成的端口 - 只留下生成的WCF工件).

在业务流程视图的底部,打开类型.在端口类型下,您应该看到WCF接口(IService).单击它并将属性类型修饰符更改为"公共"对多部分消息类型执行相同操作(4 x IService_* - 请注意,服务上的每个WCF方法有2个消息类型(一个用于请求,一个用于响应).

现在应该构建WCF Ports项目.

接下来是Schemas项目 添加2个模式,表示将从BizTalk公开(发布)的内容(我称之为BizTalkServiceRequest和BizTalkServiceResponse)这个示例只是在底层WCF服务上提供了一个精简的外观,所以我只是有类似的字段到请求和响应的原始WCF服务,具有相同的xs类型.但请注意,底层WCF服务上的"实体"概念已被请求和响应消息替换.但是,可以在多个消息中重构和重用模式(xsd:import)中的公共元素.我刚刚使用了默认名称空间和"Root"节点,但请注意,这些对于BizTalk服务使用者来说是可见的,因此在实际项目中,您需要更多地考虑这一点.

请注意,我们没有重用导入/生成的WCF服务模式.在综合企业中,还可以使用第三组模式,即"规范"模式,这些模式与BizTalk服务的消费者和消费服务所使用的格式无关(并且还需要更多的映射).

接下来是传入的请求到WCF输入模式之间的映射,然后是从WCF输出模式返回到BizTalk服务使用者的响应的另一个映射.在地图项目中,将.Net引用添加到WCFPorts项目和Schemas项目中.向Map项目添加新Map对于Source Schema,找到Referenced Schemas - BizTalkServiceRequest架构.对于目标模式,选择WCF端口模式(名称损坏很糟糕,但它将是MyService的一个 - 而不是数据交换或微软模式之一).请注意,您需要选择需要使用哪些包含的模式.选择GetDataUsingContract架构.在元素下,将鼠标从源Name元素拖动到目标模式值,然后从元素拖动IsAddSuffix到BoolValue元素.对返回响应消息执行相同操作 - 显然这次WcfResponse消息是源,并且公开的BizTalk响应是目标.布尔值在repsonse中没用,所以只映射字符串值.地图现在应该编译.

最后是Orchestration项目

• 添加对Maps,Schemas和Ports项目的引用
• 添加一个新的Orchestration(我称之为AddServiceOrchestration).
• 您需要添加一个接收端口(在左侧添加)和发送端口(在右侧).
• 发送端口使用现有的导入WCF端口(我们之前公开).我将发送请求并收到回复.
• 端口绑定选择直接绑定,并通过过滤器表达式路由.
• 对于接收端口,您需要创建一个新的端口类型 - 请求响应.接收请求,发送响应,再次,直接绑定,通过过滤器表达式进行路由.
• 同样,您需要将端口公开
• 您需要在接收端口上为请求和响应设置消息类型(单击请求和响应,然后在Schemas程序集中查找消息类型)
• 业务流程中的形状应该是自我解释和直截了当的 - 基本上只是在端口中绑定接收和发送形状,然后在变换形状中使用地图.
• 初始接收形状是激活.

构建+发布

现在一切都应该构建,所以是时候发布到BizTalk了(我假设一个本地服务器)现在我们将使用向导发布业务流程,并将使用IIS来展示暴露的Web服务,尽管注意到Biztalk也可以自我主持人.请记住在所有4个Biztalk项目的"部署"选项卡中设置"应用程序名称"(否则它们将在默认应用程序中结束).另外,请记住需要对BizTalk程序集进行签名,因此请创建.SNK(签名选项卡)

右键单击解决方案,然后单击"部署".(请注意,必须先构建和部署项目,然后才能使用发布向导公开服务)假设部署成功,则需要配置业务流程(另一个Orch是由WCF导入生成的Orch - 它拥有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应用程序 - 解决任何未完成的配置问题(例如,将orch分配给进程)

您需要在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就适合这项工作.