1. 概述

本文将通过一个根据实际项目经验提炼出来的小故事，来探讨在SOA业务整合项目中如何根据实际需求选取合适的产品技术，实现WebSphere 平台与其他应用程序的连接和集成。文章对使用WebSphere Adapter产品和采用面向对象编程这两种实现方式的优劣和适用范围做了相应的分析和比较。

2. SOA业务整合中的连接性

SOA业务整合能够让企业充分利用其在开发人员、IT硬件、数据库和应用程序方面的现有投资，通过对现有资源的重组整合从而提高生产率，实现业务灵活性与创新。连接性是实现SOA业务整合的重要前提，只有首先完成对现有应用系统的连接互通，才能进一步考虑业务流程的整合和优化。IBM在SOA的连接性实现方面提供了若干产品的支持，其中就包括WebSphere Adapter。

IBM WebSphere Adapter

IBM WebSphere Adapter是IBM提供的SOA业务整合解决方案中用来实现连接性的一款非常重要的产品，它遵循J2EE Connector Architecture （简称JCA）1.5 规范，为开发人员提供了一系列连接各种异构企业信息系统（Enterprise Information System，EIS）及数据源的适配器套件，从而使开发人员可以轻松地实现WebSphere产品与以其它企业应用程序及数据源的连接和集成。

图1：WebSphere Adapter

3. 开启探索之旅

开始我们故事的之前，不妨先介绍一下故事的主人公 - Peter，他是一家软件公司的开发人员，是个java编程的高手，曾经参与过多个重大项目的开发工作，有着丰富的项目开发经验。

最近，Peter 收到公司的通知去参加一个重要的客户项目的实施。这是一个SOA业务整合的项目，客户希望通过采用IBM的基于SOA的业务整合解决方案，对现有的若干应用系统进行集成，并完成对业务流程的整合和优化。系统的整体架构如下所示：

图2：系统架构

这是一个比较典型的应用系统集成的解决方案。其中，Peter将负责实现WebSphere平台和应用系统A间的连接和通信。

4. 使用WebSphere Adapter 还是采用面向对象编程？是个问题！

Peter加入项目组后，便首先对项目的整体情况和自己负责的子模块做了一些研究。他发现应用系统A底层采用了DB2数据库进行数据存储，因为当时设计时没有考虑到将来的可扩展性，所以系统并没有提供很好的编程接口供外部程序访问。

经过仔细的分析过后，Peter发现实现WebSphere平台对应用系统A的数据库的访问有两种实现方案可供选择：

1）使用WebSphere Adapter产品。像我们前面介绍的那样，WebSphere Adapter可以实现WebSphere平台与其它各种应用系统和数据源（包括数据库）的快速集成。采用这种实现技术的好处是可以避免大量的编程工作，绝大部分的配置工作都可以通过图形化的工具来完成。而Peter对这种实现方式的顾虑在于，他需要花一定时间去学习和熟悉该产品的功能和具体用法，另外它是否能支持一些比较复杂的数据库操作。

2）面向对象编程。通过编写java代码，使用JDBC接口实现对目标数据库的访问。这是Peter比较熟悉的一种实现方式。它的好处在于开发人员可以根据实际需求编写任意的代码实现，具有很强的灵活性。而这种方式相应的代价就在于开发人员需要进行较多的编程工作。

二种实现方式似乎各有利弊，到底应该选哪个呢？这是个问题！

5. 顺利开局

经过反复的思考之后，Peter最后决定采用面向对象编程这种实现方案，因为他对自己的java编程能力还是相当有信心的。于是，Peter很快设计出了下面的系统架构。

图3：实现方案

在接下来的几天里，Peter埋头苦干，很快便完成了程序的主体框架和主要功能的实现。单元测试进行的也很顺利，实现的功能基本都已经达到了预定的目标。在Peter看来，项目的进展颇为顺利，他只要再对子模块的实现做一些后续的完善工作，并完成整个项目的集成测试，就可以大功告成了。Peter 不禁有些得意，甚至已经开始盘算着完成这个项目后去海边好好的度个假了，殊不知，他正在慢慢的陷入一个看不见的沼泽之中。

6. 逐渐陷入沼泽

需求变化

这天早晨，Peter一到公司便被项目经理叫到了办公室。原来，项目的需求有点变化，Peter负责的那个子模块的功能需要增加，不仅要实现对应用系统A的若干数据库表的数据写入，还要能够完成相应的修改和删除操作。在Peter看来，增加这些功能简直是小菜一碟，自己以前的实现代码很多地方很重用，只需稍微修改一下便可搞定。于是，他花了一个下午，在原来的代码基础上增加了几个方法便搞定了。

在接下来的几天里，Peter所负责的子模块不断地有新的功能需求加入进来，随着功能不断增多，其实现的代码量自然也是不断地膨胀，已经由最初的200行左右增加到了5000行左右。

随着代码的日益臃肿，一些代码的bug开始逐渐出现了，并且有逐渐增长的趋势。这让Peter开始感到有些隐隐的不安。

渐入困境

第天一大早，项目的测试人员便跑过来找Peter。原来，客户对系统的整体性能做了一个初步的测试，而测试结果非常不令人满意。测试人员经过仔细分析后发现，Peter负责的那个子模块是整个系统性能低下的罪魁祸首。这天Peter工作到半夜，终于找到了其中的原因。原来，他在每次数据库操作之前都要创建数据库连接，操作过后再关闭该连接，频繁的数据库连接新建和关闭操作造成了系统性能的大幅下降。Peter决定把数据库连接的管理功能抽取出来，采用连接池机制，这样可以实现数据库连接的共享，避免频繁的新建和关闭操作，从而解决系统的性能问题。在Peter对代码做了一番修改之后，性能问题是解决了，可是测试人员很快发现原来的一些正常功能受到了破坏。

事情似乎进入了一个恶性循环，解决一个现有的问题时稍不小心就会引起更多新的问题。

致命打击

就在Peter已经忙得焦头烂额时，一个噩耗传来：项目需求又有变化，应用系统A的数据表结构要进行调整，而且需要增加对另外几个数据表的访问。这意味着Peter原来的实现代码大部分需要重写。这让Peter几乎绝望，项目目前已经接近尾声，他很清楚现在做这样大规模的代码改动不仅时间上不允许，而且风险很大。

Peter濒临崩溃，整个项目也将面临失败的危险。

7. 使用WebSphere Adapter摆脱困境

就在Peter感到束手无策之时，忽然想起了WebSphere Adapter这种实现方案。当初他曾经在两种实现方案间思量过很久，并最终选择了面向对象编程的实现方案。现在看来，使用WebShere Adapter或许是一种更恰当的选择。

于是，Peter去WebSphere Adapter的信息中心，对其功能做了一番仔细研究。他发现其中有一款WebSphere JDBC Adapter可以专门用来实现对各类数据库的访问，它的底层通过JDBC编程接口实现和数据库的通信，可以支持包括DB2在内的各种主流数据库平台。

图4：WebSphere JDBC Adapter

Peter发现，用户可以通过WebSphere JDBC Adapter轻松地实现对目标数据库中各类数据表、视图、别名和存储过程的访问，而且它还支持用户自定义的SQL语句的执行。另外，它还提供了连接管理、事务支持、事件唯一性保证等各种功能来满足用户的不同需求。这些功能正是Peter在项目中所需要的。

图5：WebSphere JDBC Adapter 功能

另外，WebSphere Adapter的使用也是相当的便捷，所有的配置操作都可以在IBM的集成开发环境WebSphere Integration Developer中完成，几乎不需要任何额外的编程工作。下面就是WebSphere JDBC Adapter的一个服务配置向导界面：

图6：WebSphere Adapter 服务配置向导

这些发现让Peter有些欣喜若狂，于是，他很快对原来的实现方案进行了调整，用WebSphere JDBC Adapter取代了面向对象编程的方式来实现对应用系统A的访问。新的实现方案如下所示：

图7：新的实现方案

新的实现方案进展的相当顺利，Peter用了不到两天时间便完成了所有的开发工作，测试的结果也非常令人满意。

8. 故事后的思考

我们的故事有了一个圆满的结局，而里面的一些问题却值得我们进一步的思考：在实施SOA业务整合解决方案时，究竟应该选用什么样的实现方案来实现各异构系统间的连接？

我们不妨对故事中提到的两种实现方案（使用WebSphere Adapter 和面向对象编程）做一个简单的比较：

	面向对象编程	使用WebSphere Adapter
专业技能要求	较强的Java语言编程能力熟悉目标应用系统的编程接口	熟悉WebSphere Adapter的使用无需了解目标应用系统的编程接口
实现复杂性	实现相对比较复杂	实现相对比较简单
易用性	差。需要大量的Java编程，需求的增加会使项目的实现代码变得非常复杂。	良好。几乎不需要编程，所有开发工作通过图形化的界面完成。
可靠性	新开发的Java代码需要项目的测试人员进行全面的测试，否则可靠性无法保证。	良好。产品的所有功能都已经通过专业测试人员的测试，可靠性强。
灵活性	灵活性差。任何需求的变化都需要大量的代码重写。	良好。可以通过调整产品的配置，很好的适应需求的变化。允许用户根据需求进行定制。
可扩展性	用户可以根据需求任意扩展。	在一定范围内允许客户对现有的功能进行一定程度上的扩展。
事务支持	需要额外的开发实现。	支持，无需额外的开发工作。
连接管理	需要额外的开发实现。	支持，无需额外的开发工作。