BPM 與 SOA的演進與展望(下)

BPM與工作流程相關標準組織

想深層了解一個專業的產業發展，透過產業標準組織是一個不錯的方式。對技術底層感興趣的BPM技術人員來說，以下的清單可以作為探索的起點。

組織名稱組織全名與網址與BPM相關之標準說明WfMCWorkflow Management Coalition
http://www.wfmc.org/
Workflow
Reference
Model工作流程系統模組架構的參考模型XPDLXML - Process Definition LanguageWfXMLWorkflow XMLASAP主持人為WfMC工作小組成員之一，但此工作放在OASIS，請參閱OASIS的項目WAPIWorkflow APIOASISOrganization for the Advancement of Structured Information Standards
http://www.oasis-open.org/ebXML –
BPSS
CPA
CPPe-Business using XML –
BP Specification Schema
Collaboration Protocol Agreements
Collaboration Protocol ProfileBPELBusiness Process Execution LanguageBTPBusiness Transaction ProtocolASAPAsynchronous Service Access ProtocolUDDIUniversal Description, Discovery and Integration (從UDDI.org 併入OASIS)WS-CAFOASIS Web Services Composite Application FrameworkWS-RMOASIS Web Services Reliable MessagingUN/CEFACTUnited Union, Centre for Trade Facilitation and Electronic Business
http://www.unece.org/cefactebXML(參考OASIS的 ebXML部分)OMGObject Management Group
http://www.omg.org/UML其中的Activity diagram 可用來描述企業流程的部分構面BPMNBusiness Process Modeling NotationBPRIBusiness Process Runtime InterfacesBPDMBusiness Process Definition Meta-modelBSBRBusiness Semantics of Business RulesOSMOrganization Structure MetamodelBRMBusiness Rules ManagementBPMIBusiness Process Management Initiative
http://www.bpmi.org/BPMN
BPML
BPQL(2005年6月已併入 OMG)W3CWorld Wide Web Consortium
http://www.w3.org/WS-CDLWS-CDL Web Services Choreography Description LanguageWSDLWeb Service Definition LanguageSOAPSimple Object Access ProtocolHTTPHyper Text Transfer ProtocolOAGiOpen Application Group
http://www.openapplications.org/OAGIS -- BODsOpen Applications Group Integration Specification – Business Object DocumentsRosettaNetRosettaNet
http://www.rosettanet.org/RosettaNet -- PIPsRosettaNet – Partner Interface ProcessesSupply Chain CouncilSupply Chain Council
http://www.supply-chain.orgSCOR modelSupply-Chain Operations Reference Model

表一：現行BPM與工作流程技術標準一覽表

 

WfMC 是比較專注於工作流程的組織，它的WfMC workflow reference model是最常被引用的工作流程管理系統的參考模型。雖然WfMC的工作小組數目較少，但因為起步較早，旗下的 XPDL與WfXML標準，有相當多的工作流程廠商支援。WfMC替工作流程的技術發展奠定了早期的基礎，它界定了BPM與工作流程領域的大框架，也持續不斷的推廣BPM與工作流程，讓眾人清楚這個領域的體系與架構。

OASIS與OMG的技術小組數目比較多，工作焦點也不僅限於狹義的工作流程技術。因為涵蓋的範圍較廣，而且背後的支援廠商規模較大，所以整體影響力也較大。OASIS旗下的BPEL取自IBM、微軟等公司，而ebXML則是OASIS與UN/CEFACT這兩個組織共同成立的工作小組。OASIS藉由充沛的技術發展動能，為工作流程技術領域開拓更大的視野，在流程定義格式、流程執行層面，以及複雜的流程互動機制等領域，提供了寶貴的技術解決方案。

OMG在BPM領域掌握了標準記號(notation)，包含UML，以及從BPMI併進來的BPMN。同時，OMG也積極以塑模(model)的角度，切入工作流程定義的其他構面，如共通模型表示法BPDM[ ]、流程語意BSBR、組織架構OSM、業務規則BRM等等。OMG的強項之一就是在塑模(model)技術，它的UML廣受軟體領域接受；在BPM與工作流程的領域，OMG持續發展BPMN與等其他BPM各構面的塑模技術，未來將使BPM的其他構面(如業務規則，或組織架構)也能使用像UML或BPMN這種等級的表示記號來進行塑模，讓複雜企業流程的塑模工作更加容易而清楚明確。

W3C的強項在於 Web 領域，HTTP是最知名的代表作。而XML與Web Services 是BPM在SOA領域的基礎建設。其它相關的BPM技術，如 WS-CAF, WS-RM, WS-CDL等等，都奠基於W3C的 Web Services技術。

OAGi、RosettaNet，以及 Supply Chain Council，則是特定產業領域的代表。它們的貢獻在於替特定產業界定共通的BPM運作規範，也就是說，定義屬於他們產業特色的應用流程參考模型與共通的術語，讓這個特定產業在推展BPM時，就有基本的需求大綱與基礎架構，也讓同產業體系內的廠商可以透過共通的產業模型與共通術語溝通，避免不同BPM應用系統之間產生各自為政而無法互通的障礙。如同前文所述，RosettaNet在電子商務領域已經廣為人知，SCOR模型則在於物流領域。雖然OAGi在國內的能見度沒有 RosettaNet高，但它涵蓋的範圍相當深遠，號稱涵蓋電子商務、製造、物流、航太、汽車、醫藥、零售、能源等32種產業。以OAGi 9.0版為例，就涵蓋61種流程情境(scenario definitions，像是訂單管理、應收帳款、供應鏈整合、銷售管理、客戶服務)與434種商業文件(BODs, 像是訂貨單、維修單、撿貨單、零件物料清單等，在流程當中傳遞的文件)的正規定義。

表一列出的各項技術標準，是以標準組織為分類依據，我們再以其他觀點來呈現其中幾個重要技術標準，以便讀者能夠更清楚了解這些標準的定位。

功能類別功能目的技術標準流程查詢
Discovery透過查詢機制，取得服務流程的基本資料
UDDI
LDAP
DISCO產業間流程互動機制
B2B collaboration使同一個特定應用產業的流程具備基礎的參考模型與術語RosettaNet 的PIPs
ebXML的CPA
OAGIS的BODs
EDI，SWIFT 塑模方式與記號
Modeling
提供標準記號(notation)與塑模技術OMG的UML、BPMN流程定義的語意與格式
Process Definition提供結構化的流程定義儲存格式，並且明確解釋每一個流程定義項目所代表的語意WfMC的 XPDL、WfXML
OASIS的 BPEL，以及ebXML BPSS，ASAP, WS-CAF
W3C的WS-CDL服務介面描述
Services定義結構化的格式，供軟體元件描述它所提供服務的內容與調用方式W3C的WSDL
OASIS的ebXML CPP傳輸介面
Transport
提供訊息的傳輸機制
W3C的HTTP/SOAP
OASIS的WS-RM

表二：依功能分類的BPM/工作流程技術標準一覽表

圖一: WfMC技術小組提供的工作流程相關標準堆疊圖，2003年版本

服務導向的企業

過去幾十年間，企業經營的焦點隨著市場趨勢而演化，60年代談的是提升量產，70年代談的是降低成本，80年代談的是提升品質，90年代談的是產品推出速度，而跨入21世紀，談的是如何給客戶更多樣的服務。不管重心怎麼改變，在21世紀之前，改善的重心仍落在產品實體；直到21世紀，重心已開始從產品延伸到購買產品的顧客，強調顧客是怎麼樣獲得產品與服務。

年代經營管理重心解決方案1960~提升產量
Quantity: Make more自動化生產 1970~成本與價格Cost: Make it cheaper採購與供應鏈
ERP，SCM1980~
產品品質Quality: Make it better品管技術
TQM1990~產品推出速度Lead Time: Make it quicker產品開發管理
PLM，PDM2000~ 服務內容多樣化Service: Offer more服務內容與流程
BPM，SOA

表三：各年代的企業經營管理重心

為了提供多樣化的服務，許多企業活動將被解構後再重組為新的營運模式，而這代表位居幕後支援的IT技術，必須能迅速配合這樣的營運模式改變。也就是說，所有的IT技術與資訊系統，都能夠像變形蟲一樣，隨時解構後再重組，在短時間內提供新營運模式所需的資訊服務，這包括企業後台營運所需的資訊系統，以及面對客戶所需的前台服務介面。

在十倍速的時代，企業無法等待。傳統為了新營運模式而大規模修改 (而非重組) 資訊系統的方式，過於牛步化無法滿足要求。下一節提到的SOA架構，替服務導向的企業，提供了很好的解答。

天生一對的企業流程管理(BPM)與服務導向架構(SOA)

SOA的IT技術本質單純而不難理解，個別的技術元素分別理解還算容易。對於SOA，大家聯想到的就是 Web Services，談到Web Services，我們就直接脫口而出：WSDL、UDDI，以及SOAP，然後就是一系列的WS-＊ 的技術標準。對很多人來說，只了解個別技術單元，並無法領會到SOA世界的美好。就好像只看得到調色盤的每個顏色，卻看不到美麗動人的畫作。所以，讓我們先把無趣的技術名詞擺一邊，這無助於我們了解SOA的美好世界。

首先，我們需先認識SOA世界裡的企業流程運作方式，以及SOA的技術元素可以互相彼此串接而形成豐富的生態；如此，就可知道為什麼BPM與SOA是天生一對 -- SOA 架構總存在美妙的答案來滿足BPM變化多端的環境。

一般來說，真實世界的BPM，具有以下的IT需求特徵：

1. 它的運作是分散式的：多數企業流程都是由多個參與者共同執行，參與者可能來自不同辦公室，甚至不同的地域區域，打破部門藩籬，甚至跨越公司的疆界；因此，跨網際網路環境的應用系統支援，以及網路環境下的安全性，都必須列入考量。
2. 它可以進行工作協調與應用程式整合：大部分的企業流程並不只是執行單一業務功能，而是多個業務功能互相協調後的成果；因此，原本獨立支援某項業務運作的應用系統，也必須跟其他業務的應用系統相互整合。
3. 它是動態的系統：企業流程中的各項元素經常動態改變。工作串連方式會隨著環境改變、人員角色扮演會異動，工作的執行地點也會改變。因此，BPM環境中的應用程式模組，必須演化成快速適應變動的動態系統，可以輕易透過設定或組態的改變行為模式，甚至調整執行地點，以因應企業流程的變動。
4. 它的構成元素種類繁多而複雜：BPM系統內含分布於各模組的企業邏輯與規則、各種不同安裝與監管模式的應用模組，以及眾多模組之間的串聯與相依關係設定。因此，BPM環境中的軟體模組，需要讓模組變得可以被BPM組態機制管理，這包含模組的啟用停用、健康狀態回報，以及系統安全政策，都應有一致的管理方式與技術標準。如此，整個複雜的BPM環境運作才可列入掌握而不致失控。
5. 它可以漸進式地成長：企業可以從最簡單的BPM活動開始著手，再演進到成熟複雜的BPM系統；因此，整個系統架構必須能提供清楚的進步藍圖，允許企業按部就班投入IT資源，並逐漸提升BPM成熟度來執行BPM。

以上五個特徵，剛好可用來陪同我們探索SOA的技術世界。

針對特徵一，SOA 技術架構可提供安全的網路傳輸與執行環境。主要技術有二：一是軟體模組互相通訊時，所需的保密需求，這可由WS-Security來達成。另一個則是組織成員在環境中的權限控管方式，這可在SOA架構內，採用LDAP、整合單一帳號登入、PKI架構與數位簽章等機制來配合。

第二個特徵引發的議題是SOA工作協調與應用系統整合。傳統應用模組在SOA的世界裡，可以採用SOA規定的服務介面(Services Interfaces)對外開放模組的功能。應用模組之間，透過SOA的服務介面標準互傳資料，就是最簡單的Web Services應用案例。此機制的主要意義在於：所有SOA內的應用模組，只要提供SOA的標準服務介面，就可以不受開發語言限制，互相呼叫或傳遞資料。這裡的服務介面，講的就是WSDL(Web Service Description Language)；而SOAP(Simple Object Access Protocol)則是規定應用模組之間互相呼叫或互傳資料時的封包格式。至於WSDL或SOAP的內容與格式應該長怎樣，大部分技術人員可以讓中介軟體或者EAI系統代勞，透過service adaptor 直接把傳統應用模組包成 Web Services模組，並不需煩惱內容的細節。

第三個特徵引發的議題是 SOA的服務組合彈性與鬆散耦合（loosely couple）的特性。SOA內的應用模組若要能輕鬆改變組合方式，或者改變執行位置，就要藉助SOA的兩個技術特性：鬆散耦合，以及UDDI(Universal Description, Discovery, and Integration)機制。因為鬆散耦合，所以某一模組抽離或加入系統，並不影響其他模組；因為有UDDI機制，所以新應用模組加入時，只需跟UDDI伺服器登記新服務的介面與所在地點，即可被其他應用模組搜尋到，並且開始互動。因為有UDDI，所以當某項應用模組遷離位置，原有使用此應用模組的其他模組，可以透過UDDI找到服務的新位置，然後用新位置連結即可。這種特性滿足「經常需要把服務節點拆解再重組」的BPM服務導向經營模式。

第四個特徵談到的是可管理的SOA Web Services。這是系統管理與軟體管理的議題，雖然目前沒有統一的標準來規範管理軟體與被管理模組的行為，但目前稍具知名度的SOA環境（特別是application server）多半會提供系統管理工具給系統管理員使用，協助管理SOA架構下所有列管模組的安裝、移除、啟動、停用，以及應用模組的狀態監控與安全機制。

第五個特徵，談的是SOA 技術架構是模組化又可彈性串接的特性，在原有SOA環境加入新的技術模組，即可漸進式提升BPM技術的成熟度。我們從ZapThink　[ ]整理的SOA藍圖中，可以得知達到不同SOA成熟階段所需具備的SOA技術。舉例來說，假設SOA有階段實施的計畫，那中間過程可以從「點對點整合」開始，進步到「提供鬆散耦合的服務」，再來是「穩定而可搜尋發現的服務」，接著「提供可組裝與再利用的服務」，進而達到最終目標—「全公司的SOA」。當然，也可從藍圖中得知，不同SOA階段所能獲得的投資回報(ROI)，剛開始只能是「降低應用程式的維護成本，達成點對點的整合」，接著是「透過服務再利用提昇效率」，再來是「提升管理能見度與控制力」，最後才是「改善組織的敏捷度」。

結語

其實，即使是資深的BPM/SOA規劃者，想要跟決策主管解釋清楚SOA的博大精深以及其效用，都是很大的挑戰。主要原因在於其中大大小小的技術條目，以及其相當複雜的關聯。雖然大家都知道，畫出一張易懂的圖解，勝過千言萬語，然而好圖難求，幸好今年(2005)十月ZapThink公司推出一張令人深刻的SOA藍圖海報。這張嘔心瀝血之作，讓人能從各個構面、由入門到進階，逐步探索SOA的世界，而且過目難忘，卻又能夠不失BPM/SOA技術的深度與完整度，實在非常難得，在此推薦這張海報作為延伸閱讀，也當作本文的尾聲。

附註

1. T.H. Davenport and J.E. Short, "The New Industrial Engineering: Information Technology and Business Process Redesign,", Sloan Management Review, pp. 11-2, Summer 1990.
2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990.
3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993.
4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997.
5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003.
6. 參閱 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005.
7. Web Services Orchestration，簡單說法：使用流程技術來描述並控制Web Services的調用順序，使多個Ｗeb Services依序發生，執行事先安排的工作順序。
8. Web Services Choreography，簡單說法：在跨流程的情境中，以Web Services技術，描述流程個體之間的訊息傳遞關係(多半是網狀結構)，以及流程狀態的控制與查詢方式。
9. 參閱本文「天生一對的BPM與SOA」小節
10. BPDM的目的在於提供可通用於多種流程塑模方法的中介模型(meta-model)，以便不同塑模方法產生的流程定義可以互相轉譯。如UML、BPMN，或者其他廠商的專屬表示法，能夠對照到此中介模型，然後互相轉譯；或者讓流程定義轉譯成底層的可執行格式，如BPEL原始碼，乃至於J2EE或 .NET的執行碼。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: http://www.zapthink.com/report.html?id=ZTS-GI103

 

                                                                                                                            

本文原刊載於：iThome企業軟體技術應用專刊

作者：華苓科技副總經理 楊基載