Oracle+BEA 後的 ESB

前幾天才剛閉幕的 Oracle OpenWorld 盛會中，Fusion Middleware 融合中介軟體產品部門的老大 -- 全球資深副總 Thomas Kurian 在 keynote 演講中，突出一個重點 -- 在完成整並 BEA 產品之後，Oracle 中介軟體在針對開放標準支援方面，更為全面而完整，可說居於業界領先的地位；包括對 JavaEE 5.0 和 JAX 一系列 XML API 的支援。此外針對 SOA 相關標準方面，則包括了 WS-ReliableMessaging，WS-Security 和 WS-Addressing，以及（國內許多朋友持續關注，）目前正在 OASIS 進行標準化過程的 SCA（Service Component Architecture；服務元件架構）。

說到這兒，不禁想起，過去一陣子和一些客戶交流時，發現他們在 Oracle 和 BEA 兩家公司正式完成合並之後，關於產品線調整、存廢，和路線圖等相關問題，非常關注、且仍存有不少疑惑，少部分甚至於有「好像除了 Tuxedo 和 WebLogic 之外，其餘的都沒留下來」的錯誤印象。事實上，除了應用伺服器和交易中介軟體之外，在 SOA 和 BPM 的領域，原本兩家公司的產品，便有很高的互補性；換句話說，此次產品線的調整和未來發展路線圖的規劃，不管對原本是 Oracle 或 BEA 的客戶來說，所受的影響和衝擊，都已降到最低。

就拿上面提到的 SCA 標準來講，恰可用來說明 Oracle 新的 SOA Suite 套件中的 ESB 部件的發展方向。原本 Oracle 的 ESB 產品和 BEA 的 AquaLogic Service Bus (ALSB)，都相當重視對 SCA 規範的支援，但先前各自的側重點和優先順序，有所不同 -- Oracle 將重點放在以 ESB 為工具，做服務組裝、編制、打包這方面（這可以從去年早在宣佈收購 BEA 之前即釋出的 11g beta 版 ESB 中即可看出。至於原來的 ALSB 和整個 AquaLogic 產品線，則選擇優先實現圍繞以企業資產庫產品（ALER; 現已更名為 Oracle Enterprise Repository）為中心的 SCA 檢視，方便 SOA 架構師檢視服務間的組合、呼叫關係。現在兩家的產品合併之後，恰好兩相互補，在 SCA 支援上，不但可基於圖形化介面對服務進行組裝，更可配合資產庫，達到 SOA 全生命週期的監管和治理 (governance)。

不管是原來的 Oracle ESB (OESB)，或是原名 ALSB 的 Oracle Service Bus (OSB)，二者都繼續保持戰略性產品的地位。在明年 11g 版本正式推出時，除了計劃將繼續長期支援目前版本中，客戶已經在使用的絕大多數功能之外，同樣重要的是，將二者整合為更緊密的單一化產品。

在 SCA 的部分，如上所述，功能恰好互補、不重疊。除此之外，在服務路由、排程、編制，和異構連線協議（Web services, FTP, MQ, Socket, SMTP, JDBC...）支援方面，以 OSB 為主。格式轉換方面，OESB 的基於 XSLT 的轉換將繼續長期支援，而 OSB 上基於 XQuery 的轉換，包括圖形對映介面，由於更為先進（例如能處理 XSLT 做不到的一變多、將單個訊息拆成多份），是推薦客戶今後儘量採用的方式。

工具介面方面，將本著過去的做法和產品策略，採用基於瀏覽器、基於 Web 的簡易圖形化介面，使 ESB 的主要使用物件 -- 負責服務、IT 運營的人員（而非開發人員），不需要先熟悉 Eclipse 或 JDeveloper 等 IDE 工具，不需要具備程式設計技能，便可快速上手，在 ESB 上進行各種設定的操作。


本文僅代表勞虎個人觀點。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16186206/viewspace-466121/，如需轉載，請註明出處，否則將追究法律責任。