使用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這種實現方案。當初他曾經在兩種實現方案間思量過很久，并最終選擇了面向對象編程的實現方案?，F在看來，使用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：兩種實現方案的比較
通過上面的比較，我們可以很容易的看到：
對于一些功能比較簡單、不需要考慮系統將來的可擴展性的項目，面向對象編程和使用WebSphere Adapter兩種方案都是適用的。當然，面向對象編程這種方案要求開發人員必須熟悉目標應用系統的編程接口，而使用WebSphere Adapter這種實現方案則沒有這種限制。
另外，對于一些功能比較復雜、項目需求可能會不斷變化、需要考慮系統將來的可擴展性的項目，使用WebSphere Adapter這種實現方案無疑是一種比較明智的選擇。
【編輯推薦】
