使用BizTalk Web服务重新发布内部Web服务 [英] Using BizTalk Web Service to re-publish an internal Web Service

问题描述

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

I'm trying to use BizTalk for communicating between two web services. It has to be like this:

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

• Service1 gets an input and sends message through BizTalk to Service2,
• Service2 responds that message, forwards it to BizTalk, and delivers it to Service1.
• Finally Service1 returns the response to user.

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

I'm trying hard to do it for days, but I couldn't manage to build orchestration without compiler errors, and I couldn't find a single piece of example with web services and web ports with typing inputs. I started to believe that this is impossible, at least with BizTalk.

最大的问题是:可能吗?如果是，怎么办?

The big question is: Is it possible? If yes, how?

推荐答案

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

The scope of your question is rather large, and I guess answering it is probably not well suited to the SO "Q+A" format.

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

However, providing a composite enterprise service which is composed of one or more underlying web services appears to be a common requirement.

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

I've built a quick and dirty example (BTS 2010 / VS 2010), and uploaded to GitHub here (download the source as a zip on the lower right)

这是从头开始实现此目标的步骤的食谱"，但我相信您需要获取要遵循的代码.

Here's the 'cookbook' of steps taken to implement this from scratch, but I believe that you'll need to obtain the code to follow.

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

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

• 使用默认的VS2010 WCF项目，并将项目命名为WCFService
• 为简单起见，使用了basicHttpBinding，但显然可以使用其他绑定 (但将需要其他一些注意事项，例如安全性等)
• 请注意，ServiceContract，ServiceBehavior上的NameSpace和behaviour namespace的Web配置中的所有设置都已设置(否则，它们将默认为tempuri)

• Used the default VS2010 WCF project, and called the project WCFService
• Used basicHttpBinding for simplicity, but obviously other bindings can be used (but will require additional concerns such as security etc)
• Note that the NameSpace on ServiceContract, ServiceBehavior, and in the web config for behaviour namespace have all been set (Otherwise these will default to 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解决方案文件夹

• Right click the WCFPorts project and select "Add" then "Generated Items"
• Select Consume WCF Service
• Check the Metadata Exchange (Mex) Endpoint
• Provide the URL to your WCF Service (e.g. http://localhost:57582/Service.svc)
• Leave the namespace (BizTalkWCF.WcfPorts)
• Complete the wizard - the WCF artifacts should now be present
• If you need to import more than one Web Service, I would suggest you create separate Visual Studio solution folders for each

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

Because we've split the project up in BizTalk (which is generally a good idea), unfortunately the wizard will have marked all the imported artifacts as internal, which isn't very helpful if they are referenced from other assemblies. Open the imported generated Orchestration (MyService.odx) (NB never delete or move this ODX as it contains the generated ports - just leave it with the generated WCF artifacts).

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

In the orchestration View, at the bottom, open up types. Under Port types, you should see the WCF Interface (IService). Click it and change the property type modifier to "Public" Do the same for the Multi-part message types (4 x IService_* - note that there are 2 x message types for each WCF Method on the Service (one for request, one for response).

现在应建立WCF Ports项目.

The WCF Ports project should now build.

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

Next up is the Schemas project Add 2 x Schemas representing what will be exposed (published) from the BizTalk (I've called them BizTalkServiceRequest and BizTalkServiceResponse) This sample simply provides a thin façade onto the underlying WCF Service, so I've just got similar fields to the original WCF service on the request and response, with the same xs types. Note however that the concept of an "Entity" on the underlying WCF service has been replaced by request and response messages. It is possible however refactor and reuse common elements in the Schemas (xsd:import) across multiple messages. I've just used the default namespaces, and 'Root' node, but note that these will be visible to your BizTalk service consumers, so in a real project you'll want to give this more thought.

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

Note that we haven't reused the imported / generated WCF Service schemas. In a comprehensive enterprise, a 3rd set of schemas can also be used, 'canonical' schemas, which are agnostic of both the formats used by the consumer of the BizTalk service and consumed service (and more maps would have been required as well).

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

Next up are the maps, between the incoming Request to the WCF Input Schema, and then another map for the Response from the WCF Output schema back to the BizTalk service consumer. On the map project, add .Net references to both the WCFPorts project and to the Schemas project. Add a new Map to the Map project For the Source Schema find the Referenced Schemas - BizTalkServiceRequest schema. For the Destination Schema, select the WCF Ports schema (the name mangled is awful, but it will be the one with MyService - not the datacontracts or microsoft schemas one). Note that you are then required to select which of the contained schemas you need to use. Select the GetDataUsingContract schema. Under the elements, drag the mouse from the source Name element to the destination schema value, and from the IsAddSuffix to the BoolValue element. Do the same for the return response message - obviously this time the WcfResponse message is the source, and the exposed BizTalk response is the destination. The boolean isn't useful in the repsonse, so just the string value is mapped. Maps should now Compile.

最后一个是业务流程项目

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

• Add reference to the Maps, Schemas and Ports projects
• Add a new Orchestration (I've called AddServiceOrchestration).
• You'll need to add an Receive port (added on the left) and Send Port (on the right).
• Send Port uses the existing imported WCF Port (that we made public earlier). I'll be sending a request and receiving response.
• Port binding select Direct Binding, and routed by filter expression.
• For the receive port, you'll need to create a new port type - request response. Receive a request, send a response, and again, Direct binding, with routing via filter expressions.
• Again, you need to make the Port public
• You'll need to set the message types on the receive port for both the request and response (click on request and response and then find the message types in the Schemas assembly)
• The shapes in the orchestration should be self explanatory and straightforward - basically just tie in the ports to receive and send shapes, and then use the maps in transform shapes.
• The initial receive shape is the activation.

构建并发布

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

Everything should now build, so its time to publish to BizTalk (I've assumed a local server) For now we'll publish the orchestration using the Wizard, and will use IIS to front the exposed web service, although note that Biztalk can also self host. Remember to set the Application Name in the Deployment tab on all 4 of the Biztalk projects (else they'll wind up in the default app). Also, remember that BizTalk assemblies need to be signed, so create a .SNK (Signing tab)

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

Right click the solution, and click Deploy. (Note that the project must be built + deployed before you can use the publishing wizard to expose the service) Assuming a successful deploy, you'll need to configure the orchestration (the other Orch is the one generated by the WCF import - it owns the WCF ports) Create a send Static Solicit Response Send Port - WCF basicHttpBinding, point it to your WCF Web Service URL. You can get the SOAP action from the WCF WSDL e.g. YourNameSpaceHere/IService/GetDataUsingDataContract Add a Filter to the send port for the message (xmlns#root), e.g., YourNameSpaceHere#GetDataUsingDataContract

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

Back in Visual Studio, you can now publish the Orch as a WebService (Tools : BizTalk WCF Services publishing Wizard) Enable metadata publishing. I've used basicHttpBinding again. And create the Receive Port, selecting the application (BizTalkWCFSample)

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

When prompted, select the assembly containing the Orchestrations (BizTalkWCF.Orchs) You will also be prompted to set the target namespace of the WCF service - keep a record of this as if you need to republish your service, you'll likely want to keep the namespace the same.

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

The location at the end is where it will be published in IIS. Select "allow anonymous access" if you don't want to be bothered with locking the exposed service security. AFAIK there is no way to control the name given to the auto created receive port.

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

You now need to start up the BizTalk app - address any outstanding config issues (e.g. assigning orchs to processes)

您将在IIS中需要一个新的.Net 4应用程序池(将其命名为BizTalkIsolatedHost)，
然后将在IIS中由向导创建的应用程序移动到该应用程序池 现在，您应该能够导航到业务流程的端点"，例如: http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc

You'll need a new .Net 4 App pool in IIS (Call it something like BizTalkIsolatedHost),
And then move the wizard created app in IIS to this App Pool You should now be able to navigate to your Orchestration 'endpoint', e.g.: http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc

总结-值得吗?

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

As you can see from the above, it is quite a lot of work to re-expose a web service in BizTalk, and we haven't really added any value in BizTalk, other than perhaps to have some BizTalk tracking and retry capability :). When orchestrating a composite service (one incoming request requires multiple back end service calls to fulfill, and if using canonical schemas as well), there will be many more schemas and maps to consider, plus additional complexity with the orchestration. And when working with web services, you get a large number of artifacts (schemas, maps, messages, ports etc etc) very quickly, so a strict naming convention is essential.

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

And we haven't considered things like exception handling, retries, etc.

因此，在计划以这种方式发布100项服务之前，我只是进行了一次健全性检查，我想我们需要考虑其他技术替代方法:

So, just a sanity check before planning to publish 100's of services in this manner, I guess we need to consider other technology alternatives:

• BizTalk ESB工具箱(特别是如果您的企业具有一定程度的通用性，并且/或者您可以控制服务使用者)
• 其他ESB(大众运输，NServiceBus，ServiceMix等，或基于Camel，Mule，Drools，Rabbit，Windows Service Bus等构建的DIY总线)，可能带有自定义外观，用于暴露Web服务端点"
• 对于大量的服务外观"，Microsoft开始对称为[a href ="http://msdn.microsoft.com/zh-cn/magazine/dd727511.aspx" rel ="noreferrer">受管服务的有希望的技术进行原型设计引擎，但不幸的是，这似乎在冰上.

• BizTalk ESB toolkit (especially if there is a degree of commonality in your enterprise, and / or you have control over the services consumer)
• Other ESBs (Mass Transit, NServiceBus, ServiceMix etc, or DIY buses built on Camel, Mule, Drools, Rabbit, Windows Service Bus etc), possibly with a custom facade for exposing web services 'end points'
• For bulk 'service facades', Microsoft started prototyping a promising technology called Managed Service Engine but unfortunately this seems to be on ice.

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

But if there are only a few, high value services like this, especially if such services require composition and mapping of multiple internal services, or use different consumed technologies (SAP RFC, SQL, SOAP, etc) then BizTalk is about right for the job.

这篇关于使用BizTalk Web服务重新发布内部Web服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！