使用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产品与以其它企业应用程序及数据源的连接和集成。
图1：WebSphere Adapter
开启探索之旅
开始我们故事的之前，不妨先介绍一下故事的主人公——Peter，他是一家软件公司的开发人员，是个java编程的高手，曾经参与过多个重大项目的开发工作，有着丰富的项目开发经验。
最近，Peter收到公司的通知去参加一个重要的客户项目的实施。这是一个SOA业务整合的项目，客户希望通过采用IBM的基于SOA的业务整合解决方案，对现有的若干应用系统进行集成，并完成对业务流程的整合和优化。系统的整体架构如下所示：
图2：系统架构
这是一个比较典型的应用系统集成的解决方案。其中，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很快设计出了下面的系统架构。
图3：实现方案
在接下来的几天里，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在内的各种主流数据库平台
图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用了不到两天时间便完成了所有的开发工作，测试的结果也非常令人满意。
故事后的思考
我们的故事有了一个圆满的结局，而里面的一些问题却值得我们进一步的思考：在实施SOA业务整合解决方案时，究竟应该选用什么样的实现方案来实现各异构系统间的连接？
我们不妨对故事中提到的两种实现方案（使用WebSphere Adapter和面向对象编程）做一个简单的比较：
表1：两种实现方案的比较
通过上面的比较，我们可以很容易的看到：
对于一些功能比较简单、不需要考虑系统将来的可扩展性的项目，面向对象编程和使用WebSphere Adapter两种方案都是适用的。当然，面向对象编程这种方案要求开发人员必须熟悉目标应用系统的编程接口，而使用WebSphere Adapter这种实现方案则没有这种限制。
另外，对于一些功能比较复杂、项目需求可能会不断变化、需要考虑系统将来的可扩展性的项目，使用WebSphere Adapter这种实现方案无疑是一种比较明智的选择。
【编辑推荐】
- TechTarget调查表明SOA势头正劲
- 化解云计算与SOA冲突的三把利器
- IBM加大对SOA、SaaS、云计算、Web2.0投入
- 详解为SOA而生的应用服务建模
- 中小企业如何进行敏捷SOA治理？
文章题目：使用WebSphere Adapter走出面向对象编程沼泽
网页路径：http://www.shufengxianlan.com/qtweb/news8/464258.html
网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联