案例說明

某一家專事中、大型軟體專案開發的廠商，承包了某家具知名度的製造業 ERP (Enterprise Resource Planning) 應用系統開發，開發與建置成本就高達上千萬以上，企業流程(Business Process) 的客製化 (Customization)需求很高，所以不容易直接以現成的 ERP 產品來套用，而必須為該製造業廠商量身訂製，從頭開發一個新的系統。

客戶單位對系統平台的需求是應用伺服器 (Application Server) 採 J2EE(Java2 Enterprise Edition) 開放式平台的解決方案，主要理由是可以跨作業系統，同時企業系統的核心是採用當時 Java 陣營所力推的 EJB (Enterprise Java Bean) 企業元件標準規格，對於大量交易處理的能力與分散式元件 (Distributed Component)的溝通，均可以達到一定的效能與穩定度。 不過，客戶同時提出另一個要求：客戶端 (Client)端的圖形使用者介面 (GUI, Graphic User Interface) 必須符合 “Rich Client” 的特色，以提供大量豐富又便捷的圖形元件，如此才有可能滿足操作人員 (Operator) 對系統高度的互動性要求。

客戶的系統要求，成為系統開發合約的前提與必要條件，所以承包單位必須提出讓客戶可以接受的實體平台的架構解決方案，該軟體廠商內部的頂尖開發人員，技術水平都相當不錯，為了能同時滿足客戶在前端與中間層 (Middle Tier) 的要求，然後再經由他們的評估並確定技術可行後，就提出了如下圖 1 的三層式 (3-Tier) 實體的平台架構。

前端考量到要能提供豐富多樣化的表單畫面，所以採取了 Delphi 的表單設計，而 Delphi是建基在微軟的 COM 元件規格上。請注意，中間層的 J2EE 應用伺服器是以 Java 為主要的程式開發與執行環境，而Java 可是不與其它的程式語言直接溝通的，Delphi 要能與之溝通，要嘛就採取第三者協力廠商(3rd Party)所提供的 “COM-to-Java Bridge” 的橋接方式，或者採取最簡單的方式，也就是利用 “Web Service” ，透過 HTTP 協定來連結兩個異質的系統。對了，又考量到專案的 “最後期限(Deadline)” ，開發時間永遠是這麼的緊迫，所以他們又採購了價值上百萬，在當時算蠻具規模的元件開發廠商(姑且稱之為 X 廠商)所研發的 “J2EE 快速開發平台” ，並且提供了許多所謂的 “服務性元件框架 (Service Component Framework)”，供開發廠商 “可重用 (Re-use)” 這些便捷的服務性元件。

圖1、”人面獸身” ERP 系統的三層式架構

筆者當時任職於某一家軟體顧問公司，該軟體廠商也由於某種機緣，而順帶委請我們評估這樣的系統架構規劃的可行性。筆者當時的老闆對這樣的系統架構，給了一個還真是傳神的批判：人面獸身的系統。

當然，為了說明與讓該軟體廠商的執行長瞭解為什麼這種人面獸身的系統風險很高，筆者的老闆就要求筆者評估並列出未來可能會發生的問題點，並且在風險評估會議中提出看法與理由。

先從開發廠商的角度思考其假設點

筆者真的很佩服，該軟體開發廠商的技術研發團隊，能想出如此具有創意又有些異想天開，同時還需要展示高度的異質系統整合技術才有可能完成的系統。但問題是，這是一個建置成本高達上千萬的 ERP 系統！！ 系統的穩定度與彈性度是未來在應付該製造業廠商的企業製程自動化時首重的維護考量，是否有必要大費周章，前端採用 Delphi 平台、後端採用 J2EE 平台的異質系統整合方式？ 這樣的系統整合未來是否會衍生出系統維護與彈性、穩定度等的問題呢？

• 為何要採用 Delphi 的表單設計？

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

• 為何是採用 EJB 來實作企業邏輯？

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

• 為何要採購 “X” 廠商的快速開發平台與框架？

  這家頗具規模的元件開發廠商，知道開發 EJB 的痛處 (筆者早期甚至曾經利用 UltraEdit文書編輯器寫一個 “Entity Bean”，光寫那麼一個 “咖啡豆” 就要 400 多行程式碼以上，真是個夢魘)，所以特別貼心開發了 EJB 的 “快速開發平台” 的產品，只要以精靈(Wizard)導引的方式，就可以協助開發者快速連結 “X” 廠商的 “企業服務元件框架 (Business Service Component Framework)，開發者甚至不需要知道 EJB 內部運作的細節，的確能減輕專案開發的時程。

釐出假設點的茫點 – 找出潛伏的問題

先站在承包廠商的角度，來思考為何是採取圖1 的架構設計考量後，再來就是仔細分析，每一個假設點是否會衍生出潛伏的問題？ 而這些問題，未來是否會是系統維護重大的致命傷？ 畢竟，”做出來” 是一回事，但爾後系統是否能正常地持續運轉，還要應付企業製程的修改與開發，穩定度與彈性度更是系統維護的關鍵之道。

• 茫點一、利用 Web Service 的連結必然是 “無狀態(Stateless)” 的設計

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

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

  “Web Service” 是一種寬鬆連結(Loose Coupling) 的異質系統資訊交換的技術，卻不是適用在緊密式的連結(Tight Coupling)環境，例如客戶端與中間層的溝通。未來是否 “Web Service” 會升級為緊密式的連結技術規格，那是以後的事，但不會是現在，可千萬不要過度濫用 “Web Service” 的技術。

• 茫點二、採用了 “X 廠商” 的 EJB 服務框架後，如果，公司倒了怎麼辦？

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

  封裝是好事，可以降低複雜度，但問題是，EJB 的規格仍舊持續修訂，本身不太算是一種很穩定的規格，所以，建基在 EJB 規格之上的 “X 廠商” 的 EJB 服務框架，也必須隨時視 EJB 規格的修訂而跟著改版。甚至如果遇到最不幸的事，”X 廠商” 倒了的話，那麼，這個 ERP 系統未來要如何維護？ 是否可以抽換掉該 “X 廠商” 的服務框架而不會影響到 ERP 系統的核心主幹呢？

  難！難！難！，筆者在系統建構初期的平台架構設計考量時，若需要用到 3rd Party的服務元件或框架，從不指望他們能 “基業長青”，而是必須要有配套的設計考量，在第一個時間點就要思考到未來要能 “抽換掉” 這些元件，又不致於影響到系統的主幹，如同壁虎的 “斷尾求生”。但從客戶端的表單元件，全面性地直接連結到 3rd Party 的服務框架，筆者是不作這種事的，因為未來根本就換不掉！！

層次(Tier)之間的溝通，請回歸到單純化

筆者針對上述的架構設計，僅列舉出最重要的兩點關鍵，就足以判斷，這樣的系統，在未來上線後，注定會是個災難。千萬不要搞得那麼技術性且複雜化，高竿的技術人員，學會了如何拿鐵鎚敲釘子後，就喜歡把別人的頭當作木板給敲下去，卻顧不得別人被你的鐵鎚敲了之後的痛楚。

客戶單位的 MIS 決策部門也要能理解與理智，從理想倒推回現實，知道現實平台技術所能達成理想的手段與其瓶頸之所在，不能昧於現實，勉強而為，但也不是妥協，而是務實。 「逐二兔不得一兔」，專心得一兔，之後，再慢慢地、有耐心地來獲取另一隻兔子吧。

客戶端與中間層的溝通，就是單純化！！ 採用同一個平台的技術！！ 若採用 Delphi 的表單設計，那麼，中間層就採用微軟的 COM+/.NET 的系統平台；若重視的是開放式中間層的 J2EE 平台，那麼，前端的使用者介面就請採用 Java 的 “Total Solution” 吧。