使用WebSphere Adapter走出面向对象编程沼泽

SOA业务整合中的连接性

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

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

开启探索之旅

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

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

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

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

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

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

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

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

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

顺利开局

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

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

逐渐陷入沼泽

需求变化

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

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

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

渐入困境

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

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

致命打击

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

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

使用WebSphere Adapter摆脱困境

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

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

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用了不到两天时间便完成了所有的开发工作，测试的结果也非常令人满意。

故事后的思考

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

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

表1：两种实现方案的比较

通过上面的比较，我们可以很容易的看到：