简介： 在现代企业集成环境中，为了使应用程序集成变得更灵活、更简单、可扩展性更强，越来越多的企业选择了面向服务的体系结构（Service Oriented Architecture，SOA），而 WESB（WebSphere Enterprise Service Bus, WebSphere 企业服务总线）作为 SOA 中服务提供者和请求者之间的连接服务的中间层也被越来越多的企业所使用。WID（WebSphere Integration Developer）是使用 SCA（Service Component Architecture）模型来开发和集成应用的工具。对于企业来说，采用 WID6.2.0.1 以后版本所提供的基于团队开发模式来进行中介模块开发，可以达到事半功倍的效果。本文重点阐述如何利用 WID 的此功能进行基于团队模式的开发。
WESB
WebSphere Enterprise Service Bus (WebSphere 企业服务总线 ) 是从 WebSphere Application Server Network Deployment 的基础上发展而来的。WESB 提供了基于标准的 Web Services 连接性、JMS 消息传递和面向服务的集成，是一种灵活的连接器中间结构，全面支持面向服务架构的开发。
WID
WebSphere Integration Developer 是使用 SCA 模型来开发和集成应用的工具，它基于 Eclipse 技术，并面向 WebSphere Process Server 和 WebSphere ESB Server 运行时环境。
Mediation module 和 Mediation flow
Mediation module 是 WID 中可以创建的一种 WebSphere 业务集成工程，可以被部署到 WebSphere ESB 或者 WebSphere Process Server 上。Mediation module 通常包含一个或多个 Mediation flow 来提供处理服务请求者与服务提供者之间的数据传递。Mediation Flow 能够对在服务端点之间进行交换的消息执行路由，变换和日志等操作，从而来实现企业的业务执行功能。
在企业的应用开发中，由于业务功能的繁琐，一个 Mediation flow 往往会实现多个接口 (interface)，且每个接口都包含了不同的方法 (operation)，而这些方法可能会分配给不同的开发人员来实现。在 WID 的 6.2.0.1 版本以前，一个 Mediation flow 所有的 operation 实现，只能由一个开发人员来开发维护，或者由一位开发人员做完一部分以后，再移交给下一位开发人员，这样导致了开发效率比较低下。从 WID 的 6.2.0.1 版本开始加入了一个新的功能—基于团队的开发模式，该功能让 WESB 开发人员们更有效，更快捷的实现 Mediation flow 的开发工作。
在以前版本的 WID 开发过程中，一个 Mediation flow 所有 operation 的实现都放在一个 .medflow 文件里，而新的基于团队开发模式则把一个 Mediation flow 按照 operation 来分解成多个文件来维护，每个 operation 对应一个 .mediation 文件，如 图 1 所示。项目负责人建立起模块后，就可以把这些 operation 的实现工作分配给不同的开发人员，开发人员可以同时进行开发工作，并且每个开发人员只需要负责维护自己的 operation 文件就可以了，各个 operation 文件之间互不影响，这样做大大提高了开发效率。
WID 基于团队开发模式的简单流程图如 图 2 所示，这个流程图向我们展示了基于该模式进行项目开发各个阶段的主要任务。
这里假定一个简单的网络销售的场景。该网络销售管理系统具有产品下单和产品派送两个功能，产品下单功能是指生成顾客购买产品的订单，而产品派送功能主要是根据顾客的订单进行产品分配。这两个功能是可以独立进行开发的。该实例的目标对象主要是对用 WID 开发 WESB 模块具有一定了解的开发人员。使用的 WID 版本是 7.0.0.0。
1. 创建一个 library，命名为 SaleLibrary。在 SaleLibrary 中创建 6 个 Business Object，分别命名为 Customer、Item、BookRequest、BookResponse、DispatchRequest 和 DispatchResponse，如 图 3 所示。
2. 在 SaleLibrary 里创建两个接口，命名为 SaleInterface 和 ServiceInterface，其中包含的 operation 如 图 4 和 图 5 所示。
图 4. SaleInterface 接口
图 5. ServiceInterface 接口
3. SaleLibrary 完成以后，我们接着创建一个 Mediation Module，命名为 SaleModule，选择添加 SaleLibrary 作为 required library。
4. 在 SaleModule 里创建一个 Mediation Flow，命名为 SaleMediation，添加 SaleInterface 作为 source interface，以及 ServiceInterface 作为 target reference。接着选择“Save the mediation flow as multiple files”选项，如 图 6 所示，然后点击“Finish”。
图 6. “Save the mediation flow as multiple files”选项
我们可以从 Mediation Flows 编辑视图的属性中看到 SaleMediation flow 已经保存为“多个单独文件”的形式，如 图 7 所示。同样也可以通过这个属性设置转变成默认的方式，即把该 flow 保存为一个文件。
5. SaleMediation 建完以后，我们打开 Mediation Flows 编辑视图，分别为 bookOperation 和 dispatchOperation 添加目标服务。bookOperation 选择 bookService 作为目标调用服务 , 而 dispatchOperation 选择 dispatchService 作为目标调用服务。这样，SaleMediation flow 的基本框架已经创建完成。
6. 在 Business Integration 视图中选择 SaleMediation，点击右键选择“show files”，打开 Physical Resources 视图能看到该 mediation 对应的文件，如 图 8 所示。我们可以看到每个 operation 都各自生成一个 .medflow 文件，SaleMediation_SaleInterface_bookOperation.medflow 和 SaleMediation_SaleInterface_dispatchOperation.medflow。
其中值得注意的一点是，当创建完一个 mediation 后，需要编辑其中一个 operation（可以没有任何实现，只是添加目标服务）并保存，才会为每个 operation 生成一个 .medflow 文件。
7. 至此，模块负责人的创建工作基本完成，可以把该模块作为 Repository 提交到 CVS 服务器上了。然后把两个 operation 的实现任务分给开发人员 A 和开发人员 B。开发人员 A 负责实现 bookOperation 的产品下单流程，开发人员 B 负责实现 dispatchOperation 的产品派送流程。开发人员 A 和开发人员 B 此时就可以从 CVS 服务器上下载模块资源到本地，同时进行开发工作了。
8. 开发人员 A 需要实现 bookOperation，即产品下单的功能，request flow 和 response flow 的实现分别如 图 9、图 10 所示。
图 9. BookOperation Request flow
在 图 9 的 request flow 中，客户端传入 customer_ID（用户 ID）、item_ID（产品 ID）和 quantity（购买数量），调用“itemQuantityCheck”这个 Custom Mediation primitive。“itemQuantityCheck”根据传入的 item_ID 检查其对应的产品库存量，如果库存量检查 OK 则调用 bookService 服务，生成一条有效的订单记录，即把该订单记录的状态设成 true；如果库存量检查 FAIL 不足则并把该订单记录状态设成 false，直接返回客户端。
图 10. BookOperation Response flow
在 图 10 的 response flow 中，直接把调用 bookService 服务的结果返回了客户端。
9. 与此同时，开发人员 B 在实现 dispatchOperation，即产品派送功能，request flow 和 response flow 的实现分别如 图 11、图 12 所示。
图 11. DispatchOperation Request flow
在 图 11 的 request flow 中，客户端传入 customer_ID（用户 ID）、item（产品信息）和 status（订单状态），调用“checkStatus”这个 Message Filter Mediation primitive。“checkStatus” 根据传入的 status 判断是否进行派送工作，
- 如果状态是 true，调用“checkCustomer”这个 Service Invoke Mediation primitive 检查客户相关信息，如果检查通过则调用“customerLog”这个 Message Logger Mediation primitive 记录该订单的相关信息，最后调用“dispatchService”服务进行产品派送工作；否则输出错误信息。
- 如果状态是 false，那么把结果的 dispatch_ID（派送 ID）设成 null，然后返回给客户端。
图 12. DispatchOperation Response flow
在 图 12 的 response flow 中，调用“dispatchStatusLog”这个 Message Logger Mediation primitive 记录派送服务完成的相关信息，最后把该结果返回给客户端。
10. 由于 Operation 的开发工作是同时进行的，假设开发人员 A 比开发人员 B 提前完成了自己的开发工作，于是先向 CVS 服务器上提交了自己的实现文件。首先，开发人员 A 同步本地的模块，在 Business Integration 视图中右键点击该模块选择“Team”中的“Synchronize with Repository”选项，打开同步视图，如 图 13 所示。
从 图 13 中我们可以看到开发人员 A 实现的 bookOperation 对应的 SaleMediation_SaleInterface_bookOperation.medflow 文件有改动，而另一个 dispatchOperation 对应的 .medflow 文件并没有变化。开发人员 A 发现没有资源冲突，于是提交了自己的实现文件。
11. 此时，开发人员 B 的开发工作也完成了，于是也开始同步本地的模块，如 图 14 所示。
从 图 14 中我们可以看出开发人员 A 已经把 bookOperation 的相关实现提交了，而且开发人员 B 实现的 dispatchOperation 对应的 SaleMediation_SaleInterface_dispatchOperation.medflow 文件也没有冲突，所以对这些文件进行更新和提交操作就可以了。不过，我们也看到了 SaleMediation.mfcex 文件有冲突发生，那是因为两个 operation 中都添加了便签（Note, 如 图 11 中的黄色框区域），这就需要手工进行合并操作了。完成以上操作后，开发人员 B 也完成了把 dispatchOperation 的实现资源提交到 CVS 服务器的工作。
以下几点是在同步资源的时候可能会发生文件冲突的情况：
- 添加，删除，或者编辑 source interfaces，source operations，target interfaces 或者 target operations 会引起 .mfc 文件变化。
- source operation 被删除时，其对应的 .medflow 文件也会被删除。
- Promoted properties 会引起共通的 .medflow 文件变化。
- 添加，删除，或者编辑便签会引起共用的 .mfcex 文件变化。
所以，为了避免冲突太多，建议每天先同步更新本地资源再进行开发。
12. 至此，Mediation 的 operation 并行开发工作已基本完成，项目负责人可以从 CVS Server 下载资源进行模块的整合实现了，如 图 15 所示。这样，这个简单的网络销售管理模块就开发完成了。
我们通过这个实例向读者简单介绍了利用 WID 基于团队的开发模式新功能进行团队并行开发的过程。这个新功能使开发人员更加快捷的开发 Mediation flow，提高了开发效率。
原文链接:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1007_gaozt_intermediary/1007_gaozt_intermediary.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-671155/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-671155/
扫一扫
118
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
