軟體架構設計鮮思維－異質平臺整合的問題與盲點

作者：王克明
信仁軟體設計顧問中心軟體架構師、機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問

某專事中、大型軟體專案開發的廠商，承包了某家具知名度的製造業ERP（Enterprise Resource Planning）應用系統，開發與建置成本高達上千萬以上，企業流程需要高度客製化，不容易直接套用現成的ERP產品，必須量身訂製新的系統。

客戶方面對系統平臺的需求，包括使用J2EE（Java2 Enterprise Edition）與EJB（Enterprise Java Bean）的應用伺服器（Application Server），理由是可以跨作業系統，同時系統的核心採用EJB（Enterprise Java Bean）標準，對於大量交易處理的能力與分散式元件的溝通，均可以達到一定的效能與穩定度。不過，客戶同時提出另一個要求：圖形使用者介面必須符合「Rich Client」的特色，以提供大量豐富又便捷的圖形元件，滿足操作人員對系統高度的互動性要求。

前端考量到要能提供豐富多樣化的表單畫面，所以採取了Delphi的表單設計，由於Delphi是建立在微軟的COM元件規格上，但中間層的J2EE應用伺服器卻以Java為主要的執行環境，不與其他的程式語言直接溝通的。Delphi與Java的溝通除了採取第三者協力廠商所提供的「COM-to-Java Bridge」的橋接方式，或者利用Web Services，透過HTTP協定來連結兩個異質的系統。

筆者當時的老闆對這樣的系統架構，給了一個還真是傳神的批判：人面獸身的系統。當然，為了說明與讓該軟體廠商的執行長了解為什麼這種人面獸身的系統風險很高，我們在風險評估會議中提出看法與理由。

先從開發廠商的角度思考其假設點
這是一個建置成本高達上千萬的ERP系統，系統的穩定度與彈性度是未來在應付該製造業廠商的企業製程自動化時首重的維護考量，這樣的系統整合未來是否會衍生出系統維護與彈性、穩定度等的問題呢？

"為何要採用Delphi的表單設計？"
Java最為人所詬病之處，在於客戶端的UI設計並不容易滿足傳統採用主從架構（Client/Server）的客戶單位，那些系統的操作者，永遠需要互動性最高的圖形介面，要能簡單、迅速、確實。隨時想要資料，點選個按鍵，就會從資料庫撈資料送到前端處理，而ERP系統更是箇中翹處。通常一個表單畫面，密密麻麻的數十個欄位的資料輸入與查詢，才能完成一個表單的送出處理。然而，Java的Swing圖形元件，因為跨平臺的考量，相對就很難達成提供豐富又能簡單設計的表單元件，而且強而有力的表單設計開發工具，仍是相當地貧乏。4GL的表單設計，如 PowerBuilder、Delphi等，才有可能滿足這些主從用戶的胃口。

"為何是採用EJB來實作企業邏輯？"
除了高度交易的處理與分散式元件處理的考量外，為何要採取EJB的元件設計？不過，ERP的系統應不至於需要高度的交易處理，利用EJB「Session Bean」來達成分散元件的溝通，有必要嗎？真的需要兩臺以上的機器來分散ERP資訊系統的負荷嗎？嗯，EJB規格的「Entity Bean」可以達成與資料庫內表格資料的同步，這勉強算是一個理由，但永續性的機制可說是泛Java陣營的強項，如「JDO」、「Hibernate」等永續性框架，均可以很方便地達成Java物件與資料庫的同步。或者難道有人還真的相信因為是用了EJB才能達成所謂企業元件的可重用性嗎？這可麻煩了，可重用性可不是建立在所謂這些如COM+、EJB等業界規格上的。況且，元件可不是為了要能被可重用，反而是要能被可抽換，這樣才能達成整體系統的可重用，這可千萬不要搞混啊。

"為何要採購「X」廠商的快速開發平臺與框架？"
這家頗具規模的元件開發廠商，知道開發EJB的痛處，所以特別貼心開發了EJB的「快速開發平臺」的產品，只要以精靈（Wizard）導引的方式，就可以協助開發者快速連結 「X」 廠商的「企業服務元件框架（Business Service Component Framework）」，開發者甚至不需要知道EJB內部運作的細節，的確能減輕專案開發的時程。

釐出假設點的茫點—找出潛伏的問題
先站在承包廠商的角度，來思考為何是採取圖中的架構設計考量後，再來就是仔細分析，每一個假設點是否會衍生出潛伏的問題？而這些問題，未來是否會是系統維護重大的致命傷？

"Web Services必然是無狀態的設計"
利用Web Services連結後端的系統後，一完成查詢，客戶端（Delphi）就馬上與後端的系統（J2EE Server）連線中斷，不會保存後端的資訊。這是Stateless的特性，好處是可以節省系統資源。但前述已提及，ERP的系統是需要讓客戶端與後端的系統密切保持溝通，最好就是能一直連線，如此才有可能盡善盡美地為客戶端來服務，可以就近「撈」資料處理，這是一種「Stateful」的設計。然而，傳統Client/Server最為人詬病之處，就是在於因為一直都是讓表單持續連線著資料庫，而造成系統的資源不足，負荷過重，也就無法同時服務數百人以上的使用者。事實上，精專系統平臺特性的軟體架構師，會懂得如何搭配Stateful與 Stateless的元件設計，讓客戶端以為有專屬的持續連線服務（Stateful），同時又能兼顧著有效節省與運用系統的資源（Stateless）。

但是利用Web Services的連結，就只能是Stateless，如此客戶端的UI元件呼叫伺服端的元件後，連線馬上中斷，無法保存其對話的過程資訊。這不合理，Rich Client的表單在按下送出之前，是需要維持著與後端系統的連線溝通（通常筆者會設計「Stateful」的控制物件為每一個客戶端服務並保存對話資訊），來取得局部欄位的資訊，這就是所謂的客戶端與伺服端的對話過程。

"X廠商倒了怎麼辦？"
仔細觀察中間層內，有兩個主要的套件：「X’s EJB Service Framework」、「EJB Container」，兩者構成了一種相依性（Dependency）的關係，而客戶端的表單是透過Web Services來連接X廠商所提供的EJB服務框架，這也形成了一種封裝（Encapsulation）的效果–客戶端的表單元件看不到「EJB Container」。

封裝是好事，可以降低複雜度。問題是，如果遇到X廠商倒了的話，那麼，這個ERP系統未來要如何維護？是否可以抽換掉該X廠商的服務框架而不會影響到ERP系統的核心主幹呢？

層次之間的溝通，請回歸到單純化
客戶端與中間層的溝通，就是單純化！採用同一個平臺的技術！若採用Delphi的表單設計，那麼，中間層就採用微軟的COM+/.NET的系統平臺；若重視的是開放式中間層的J2EE平臺，那麼，前端的使用者介面就請採用Java的解決方案吧。