SOA(Service Oriented Architecture) 和 BPM(Business Process Management) 近年來成為IT界的兩大熱門話題。美國研究機構 Gartner Group 曾指出，企業在面對快速變動與高度競爭的環境中，必須建立堅強的IT架構，以快速因應各種可能發生的商務狀況。Gartner Group並於2004年6月更進一步指出，企業現在必須重新思考公司內部的IT架構，並打下以SOA為基礎 BPM 為中心的企業 IT 地基，這是現今任何一個企業要成為即時企業(RTE, Real-Time Enterprise)過程中不可或缺的決定性步驟。

SOA 的基礎概念，定義及特質

由於 SOA 的興起與 Web Services 相關技術成為標準的潮流密不可分，因此常常將 Web Services 與 SOA 架構的實現畫上等號。然而， SOA架構的實現不限於 Web Services；在過去也曾一度風行 CORBA 、微軟推行的 DCOM 或 Java 中的 RMI 、 JNDI 等都是可以實現 SOA 架構的方式。但是，在如微軟、昇陽或 IBM 等平台的提供者，都相繼推出開發 Web Services 的工具，甚至是如 SAP 、 Seibel 或 PeopleSoft 等應用系統的提供者，也推出新一代以 Web 服務為導向的應用系統風潮之下，不可否認的 Web Services 將會是實現 SOA 的最佳途徑。 ( 圖一 )

事實上，在今日企業的 IT 環境中，不管過去是因為雞蛋不要放在一個籃子的心理，或是由於要在各個領域中選擇最好的產品使用，企業的 IT 環境多已不是由一家軟體廠商獨霸的局面；在考量確保過去 IT 的投資，又可持續保有 IT 架構的發展與發揮 IT 系統所應帶來的效益， SOA 架構的導入，已在多數企業的心中醞釀。根據 Gartner Group 的研究指出，全球 2000 大的企業中，絕大部分將會在 2007 年前導入 SOA 的解決方案。

SOA 與 BPM 的相互關係 , 及其各自扮演的角色

商業流程管理系統 (BPM) 則是近來 IT 界的另一熱門，一方面訴求流程導向思考，縮短 Business 和 IT 的差距，另一方面則訴求在減少程式開發時間以提昇生產力。然而過去在面對企業內部現有的各種不同應用系統之下，在實際開發執行上，常常耗費龐大心力在整合現有資源，且各家開發的連結整合方式又各有不同，開放與共用資源難以實現。 Web Services 技術的興起，提供了標準開放式的整合技術，帶給商業流程管理系統（ BPMS ）新的發展能量，一時之間以 Web Services 為中心的流程描述語言，如 IBM 的 WSFL 和微軟的 XLANG 等紛紛提出，並整合成為 BPEL(Business Process Execution Language) ，成為未來 BPMS 目標支援的標準流程語言。

其實分析 SOA 和 BPM ，可以發現兩者在概念上是相互呼應的；如 BPM 是管理流程的定義與監控流程的執行，而流程 (Business Process) 的特性在於鬆散耦合 (Loosely Coupled) ，流程中的任何部分是可以被取代或強化而不失原有流程的目的，而流程的組合基礎則在於步驟 (Activity) ，步驟在於完成特定的功能 (Function) 。

反觀在 SOA 架構中，是以服務為基礎，而每個服務在解決特定的問題，提供特定的服務，但是面對商務上或應用上遭遇的問題來看，單一的服務多只能滿足部份功能，而解決的方法在於將各個服務串連起來，並進而管理串連的方式與監控執行的狀況，如做好接單的工作就需要串連信用額度查詢，庫存查詢，與建立訂單至 ERP 等功能的服務。

因此，從 IT 角度而言， BPMS 為 SOA 提供了快速串連各個服務的實現，並提供了管理與監控的能力，而串連方式的改變即是流程的改變；若從商務或應用的角度而言，SOA 讓 BPM 在實現流程的執行上更為容易了，流程步驟的改變可藉由連結不同的服務而達成，在連結服務的方式標準化之下，不再頭疼於整合問題。

Ovum Research 指出 SOA 使企業導入 BPM 更為順利並更快速產生效益，而 Gartner Group 則說 BPM 對 SOA 所提供的組合式的應用願景，有著密不可分的夥伴關係，這都在說明 SOA 和 BPM 不管在技術方面或商務應用方面，都扮演著相輔相成的角色 ( 圖二 ) 。

SOA 的建構在 BPM 和 Web Services

SOA 的核心概念底層在將軟體轉化為可重複使用與分享的服務，因此， SOA 架構的建立，首先在分析各個應用系統中，有哪些功能是必要開放成為服務的；一般直覺的方法就是看看有哪些功能是重複出現在不同的系統中，而據此決定哪些功能是要包成服務。而另一種方式，則是從流程中著手，藉由 IT 與 Business 部門的合作，進行流程內涵的審視與分析，一方面由流程實務需求上，確定哪些功能需要被建構成服務，另一方面可藉由審視流程的機會，進行流程的改進。

一旦服務功能被確認出來後，我們可以使用 Facade 的設計模型方法，在這些功能中劃分出幾個服務的介面，然後透過程式設計工具 (IDE) ，如 JBuilder 、 IBM WSAD 或 .Net Studio 等，將這些介面轉換成 Web Services ，並產生 WSDL 服務描述語言。其次，可藉由 BPMS 的流程設計工具，依流程需要將各個服務設定為流程中的步驟，而將各個服務串連一起。現在部份 Web Services Capable 的 BPMS 並可將所設計的流程，發佈成為 Web Services ，提供具有複雜邏輯的流程服務。

實作案例分析

國內企業目前對 Web Services 的應用，多用於 B2B 的整合，然而 SOA 觀念與架構的建立，已於國內企業中悄悄開展進行了，筆者所接觸的案例已成功地協助不少客戶，從流程的設計、分析與建構中，逐步訂出 ERP 系統所需提供的各項功能，依 BPMS 的橋接器平臺 (Adapter Framework) 封裝方式，封裝並發佈於整合管理器（ Integration Manager ）中，成為可被呼叫使用的服務，並支援 JMX 的管理 ( 圖 3) ，然後在流程設計師中描述出各項功能在流程中所服務的步驟與各步驟的互動關係，協助客戶快速達成設定目標。

圖 3:BPM 系統中的整合管理伺服器架構

以一家上市電子零件流通企業為例，由於已導入了 BPM 系統，並逐步將公司的流程納入 BPM 系統內管理與支援，已將部分常用的 ERP 功能，如信用查詢，庫存查詢，建立訂單等，建立在整合管理器（ Integration Manager ）中成為橋接器步驟 (Adapter Activity) 可呼叫使用的服務。

在下游客戶的要求下，能夠快速地在原有公司的出貨通知流程中，從業務助理在Portal中提出申請，經過信用查詢把關，相關人員的簽核同意，到啟動ERP中Outbound Delivery 的流程中，輕鬆的加入一個 Web Services 的工作步驟，經由客戶提供的 Web Services 介面，即時地將出貨通知傳至下游的連接器客戶的資訊系統內 ( 圖 4) ，提供客戶需要的即時資訊，與客戶的 Web Services B2B 系統同時上線。這個案例一方面展現出 SOA 和 BPM 結合的快速反應能力，更重要的是提升客戶端的觀感和滿意度。

其實在企業追求營運效率，降低營運成本的同時， SOA 是提供了一個很好的 IT 架構藍圖，然而，沒有落實 BPM 的導入，將 Business 人員和 IT 人員結合起來，為共同目標而努力，找出對的事情，再落實至 IT 做有效率的執行，否則 Business 與 IT 部門的各行其事，常會錯放目標，汲汲於將有問題的做事方法更有效率化，而平白消耗公司資源，那麼即使導入了 SOA ， 發揮的效益也將侷限在 IT 系統的整合方便化。