关于在BizTalk上实现服务注册的发布问题

 

关于在BizTalk上实现服务注册的发布问题如下：

 

一、实现目标：

 

为了实现不同应用系统数据的整合，由于不同应用系统提供的Web服务方法、参数、返回数据的XMl都不相同。我们需要统一不同应用系统提供的Web服务的接口，同时统一不同应用系统返回的XML数据格式。

 

二、目前的实现方式

 

目前我们通过BizTalk业务流程中调用其它业务系统的Web服务，并通过 “映射”实现返回数据的转换。最后将BizTalk业务流程发布成统一的Web服务。

 

三、举例场景：

以待办事项举例说明，应用系统A上存在待办事项服务接口，操作方法如下:

getTasks (string userid, int index, int count,….);

应用系统B上存在待办事项服务接口，操作方法如下：

getB(string id, int indexRecord, int showRecordCount,…..)

 

上述两业务系统的服务接口描述与操作方法均不一致，我们的目标是将上述两个服务接口注册发布到BizTalk上，通过BizTalk业务流程发布成统一的WebService，并返回相同格式的结果，比如标准方法：

getTasks(string functionName, string uid, int index, int count)

 

 

 

四、实现流程如下图：

 

 

该业务流程主要工作是：

1)         接收Web服务的消息；

2)         根据接受到的消息，构建调用OA Web服务的请求消息；

3)         调用OA Web服务并接收返回结果；

4)         根据返回结果构建统一的XML消息返回。

 

该业务流程中存在如下端口：

1. OAProxyPort(右侧)：接收-发送端口，最终该业务流程发布成标准的WebService取决于此端口，如下：

 

属性如下：

 

 

1. OAPort(左侧)：发送-接收端口，实现调用第三方应用系统接口，这里比如说A应用系统的方法getTasks()

 

属性如下：

 

1. 中间的主要流程依次为接收标准参数消息、构建第三方接口请求消息、调用第三方业务系统接口，接收调用返回结果，构建标准的返回结果。

 

 

 

五、问题：

显然，此方案从业务上可以解决我们的目标。但是针对发布出的标准WebService进行压力测试之后，发现对比直接调用第三方应用系统接口，平均响应时间要相差10~20倍，我们以10个线程的并发就可以看出，如下：

1. 调用BizTalk发布出的WebService

 

1. 调用第三方应用系统发布出的WebService

 

 

1. 上述两者在平均响应时间上相差几乎10倍（2022.14ms与186.7ms）
2. 就单次调用情况而言，响应时间相差也比较大，我们分析了在BizTalk上的实例运行情况，发现每一次调用的过程分别为：

接收管道->业务流程->发送管道->接收管道->发送管道，其中位于业务流程的调用耗时比较长，尤其是在初始化调用过程中。

1. 最终的问题是：
   1. a.       使用BizTalk业务流程发布构建的方式来达到预期目标的可行性是否有问题？
   2. b.       如果该方案是可行的，有没有好的性能优化方法以提升服务响应性能？