帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
服務導向架構(SOA)商業應用趨勢
 

【作者: 梅伯信(Barry Mei)】   2006年07月10日 星期一

瀏覽人次:【8158】

「服務導向架構」(Service-Oriented Architecture;SOA)透過定義明確、自給自足、可在電腦網路上隨處呼叫的服務元件,建立企業流程與應用程式。SOA架構可提供前所未有的商業效益,不但軟體功能可以重複使用,而且商業流程精確有效,亦容易彼此搭配使用維護。這些潛在效益,使SOA在企業應用上炙手可熱。服務元件的組織架構,對於SOA系統的品質有重大影響。因此,如何架構SOA的基礎服務元件,協助開發人員設計一套有用的SOA服務,便是相當重要的課題。


在服務導向架構(SOA)中,一個服務乃是指服務提供者所執行的一個工作單元,以達到一個或多個服務消費者所預期的結果。每個服務提供定義明確、自給自足的功能,採取例如與執行環境之間鬆散耦合的方式。這個功能完全透過介面契約與行為屬性來描述,隱藏實際建構方式,在網路上隨處可用。


SOA的基本要件包括服務提供者、服務儲存庫、服務仲介者、服務消費者等等,都以服務規格定義(service definition)作為描述、存取、傳輸、瞭解各項服務的要素。


轉換企業架構型態的現代SOA逐漸嶄露頭角,關於服務發掘與服務設計的方針也逐漸成型。在這個SOA逐漸成熟的階段,一些重要SOA建構方式的概念與實務經驗相當值得注意。關於服務設計的各個層面,我們將探討一些通用的軟體工程理念與考量點,以落實SOA的關鍵層面為重點,例如如何建立商務的歸屬、如何發掘及設計服務內容、以及如何實現SOA企業架構轉型工程。


我們以國際物流服務供應商──德國郵政公司廣泛採用SOA的實務經驗為例。德國郵政公司的SOA架構以商務為重心,該公司建立了多個SOA流程與方法,將SOA的潛在效益付諸實現。此外,該公司還採用一套相當精細的企業級服務平台,稱為SOPware(服務導向平台),這套平台以甲骨文(Oracle)的Fusion Middleware Suite為主,提供商務服務仲介所需的支援架構。如此一來,各個業務部門不需要擔心服務建構與供應的技術細節,而能輕鬆快速地組合高階商務服務與流程。


起跑點:服務發掘(Service Discovery)與套件管理(Portfolio Management)

商務服務與技術服務之異同

SOA架構的主要特色,在於能透過商務推動IT發展,又能透過更具彈性的IT來提昇商務運作。雖然SOA的基本概念能用來建立更有效率的IT運作,但SOA更大的優點在於能讓業務營運快速建立高競爭力的商務應用軟體,並使這些軟體能經得起環境變遷的考驗。相較之下,技術服務通常內含於商務服務的支援架構中。雖然這些技術服務也相當重要,但一套良好的SOA建構體系應該明確劃分商務服務以及技術服務的區別。


為了完全發揮SOA的轉型效益,商務人員應該負責找出商務服務的適用範圍,並描述這些商務服務的特性。包含德國郵政公司在內的多家企業,都採用商務領域(business domain)的概念來建立商務歸屬。


建立SOA之商務歸屬(Business Ownership)

為了建立一套共通的語言,讓商務人員與IT人員能藉此討論相關服務、界定商務服務的歸屬,我們應該先檢視商務營運的基本結構與相互關係 。首先,將一家公司的商務範圍劃分為多個商務領域,每個商務領域都內含緊密相關的功能與資料,例如可劃分為客戶、產品、合約等領域。為了設計出最佳的領域劃分方式,發揮長期的穩定性效益,並在各層面建立紮實的SOA根基,我們必須先了解這家公司的經營方式,如(圖一)所示。



《圖一 簡化的高階商務領域基本架構示意圖》
《圖一 簡化的高階商務領域基本架構示意圖》

德國郵政公司的實務經驗顯示,判定主要的商務物件以及彼此的相互關係,是建立領域架構的重要第一步,接下來可以更深入分析各個商務流程以及彼此的互動關係,建立更精確的領域規格,以及某些主要領域中的次領域。領域架構應該和實際商務情境以及未來可能的商務情境加以比對,以檢查領域架構是否紮實。


設計商務領域必須對業務有深入的了解,同時也需要仰賴某些直覺。就以「客戶」與「客戶關係」兩個領域來說,第一個領域主要管理其他領域所需的主要客戶資料,而第二個領域則追蹤長期客戶關係的各個層面。如果仔細分析基本的業務關係,可發現兩者其實有基本的差異。客戶領域提供的資訊,變動頻率不高,但需要提供一個客戶各層面的360°視角,而且客戶資料的使用方式,在大多數領域都相當近似。相較之下,客戶關係領域所提供的功能則有相當多的變異,而且變更頻率頗高。只要客戶與該公司有新的交易,或是該公司的CRM策略有所演變,都會使客戶關係領域產生變化。除此之外,負責客戶關係的商務人員,使用這些資訊的方式也各不相同,例如有些人將其應用於即時交叉銷售(real-time cross-selling);有些人則使用這些資訊來提供更佳的客戶服務。


另一重要考量則是,如果要使用SOA轉變整個企業IT架構,商務人員必須對商務架構有所歸屬,該業務的歸屬者同時也需負責定義商務領域的範圍,並負責提供意見,判斷該業務領域該提供哪些業務服務,以及該領域需要哪些服務(所需服務則由其他領域提供)。這樣的做法可以建立一套整體的商務及IT規範,包含資料歸屬的明確定義。在德國郵政公司,來自商務IT機構的企業架構工程師與服務設計師,可協助商務歸屬者敲定服務的細節,但最終的責任還是要由商務人員來負擔,如(圖二)所示。



《圖二 商務服務架構作為流程與應用間的抽象層示意圖》
《圖二 商務服務架構作為流程與應用間的抽象層示意圖》

商務領域以及商務服務,可形成企業流程架構與應用架構之間的一個抽象層,其效益相當明顯:透過領域與相關服務的概念,將流程與應用程式拆解開之後,變遷週期就可以各自獨立管理。IT系統(包括應用層與基礎架構層)可以變更或替換,只要服務合約保持穩定,就不會影響商務流程。反過來說,如果許多建構元件(商務服務)已經就位,可供重複使用時,商務流程就可以相當輕鬆地變更或擴充。


服務發掘(Service Discovery)

雖然在某些方面,服務與元件相當類似,但服務也類似小型的應用程式,需要以管理應用程式的類似方式加以管理。如(圖三)所示:德國郵政公司制定了五個服務設計流程,提供服務套件的建構與改進基礎。這些流程也可廣泛應用於任何其他產業。



《圖三 服務設計流程示意圖》
《圖三 服務設計流程示意圖》

要建立與管理一套商務服務套件,第一步先要進行服務的發掘。為了找出一個商業領域應該提供哪些服務,首先要調查全部的商務物件與其相互關係。商務物件(例如客戶、發票、住址等等)並不是IT物件,商務物件是業務營運所需的要件,完全以商業詞彙加以敘述,不牽涉任何IT系統的細節。例如「客戶」領域的一項重要服務可能是Customer Information(客戶資訊),而這項商務服務的基本操作方式可能是「建立、讀取、更新、刪除」等類型,但這個領域也可能有更複雜的功能,需要結合數個基本的服務運作,例如客戶領域可能包含一個Customer Address Consistency(客戶地址一致性)服務,可以檢查客戶資料是否存在、檢查客戶的正確名稱,並檢驗(甚至更正)客戶的地址。其它還可能需要的服務,可透過主要商務物件的特定組合而得知(例如合約與相關的發票)。


這種由上而下的服務發掘,可以再搭配兩種額外的方式。第一種是追蹤商務流程、追查這些流程與商務環境之間的主要互動方式,然後將類似的功能集合起來。這種方式有助於發掘實用性服務,這是單以由上而下方法所容易忽略的。這種商務流程導向的方式,可有效檢查服務的完整性,並顯示特定服務的重覆使用性,但運用這種方式時也需要小心:不同的商務流程(尤其是不同商務人員所制定的流程)常會用不同的語意來表達相同(或近似)的概念。要使服務套件合乎實用,一項重要條件就是要對商務詞彙的語意進行透徹而嚴格的分析(包含商務詞彙的翻譯與協調)。值得注意的一點是,如果單用這種方式,常可能造成服務的定義過於微細瑣碎。


除此之外,也可以透過用途導向的服務發掘方式,來尋找有哪些IT基礎架構應用程式(例如大型主機或舊型應用程式)的功能和資料;至今仍有商務應用程式在使用當中,然後將這些程式外加服務介面的包裝,在未來的商務應用程式中繼續使用這些服務。雖然這種由下而上的方式可以搭配其他兩種服務發掘方式,但由於各服務之間的語意缺乏協調,因此這種方式無法帶動長遠的SOA轉型,只能用於諸如在行政環境中證明SOA一般性運作的階段。


在服務發掘過程一開始,可先投資小量的成本,結合上述的各種方法,建立一些概念性的服務(例如只有規格,沒有實際建構內容),然後逐步進行服務的實際建構,嚴格遵守每個專案的商務優先度與商務案例。因此,商務分析師以及企業商務架構工程師,在整個商務服務發掘的過程中,就扮演相當重要的角色。


實現改革:透過SOA轉變企業架構

建構服務套件

德國郵政公司的服務發掘過程,產生了將近100個候選的商務服務(每個服務平均有五到十個操作功能),這些服務根據商務價值、重複運用性、IT複雜度降低能力等因素排定優先順序。這些候選服務可做為後續服務套件管理過程的基礎,讓服務的定義更為妥善,並帶動特定服務的細節規格、建構方式、重複使用與生命週期管理。


在建立整個服務套件的過程中,有許多重大問題需要解決,例如服務的歸屬、建構與維護這些服務的資金來源、生命週期的管理等等。究竟應特別注重SOA服務,或特別注重專案的執行,兩者之間應求取平衡,其中有多種不同的服務實踐風格可供運用。例如,可以先在企業內部建立大部分可能有用的服務,然後再進行一系列SOA專案來建構或使用這些服務。這種較為服務導向的方式首先建立一套豐富的服務套件,並制定紮實的長期策略,同時需要某種程度的先期投資(尤其是服務設計方法學以及服務仲介平台)。另一種較為專案導向的方式,則是以某些專案所需的服務為優先,不強調這些服務將如何共用,這種方式可提供短期的投資報酬,但可能影響長期的SOA效益。


德國郵政從一開始,就強調架構的轉型應該根據SOA原則逐步演進,這種演進方式以較小的IT專案著手,具備明顯的商務案例以及有限的範圍,以提供短期的商務效益(策略性),並符合企業整體的最終應用目標(根據商務領域所制定的SOA藍圖)。這些專案必須有其商務歸屬者,且無論使不使用SOA,這些專案都必須執行,因此這種演進法可在服務導向與專案導向方式之間取得良好的平衡,如(圖四)所示。



《圖四 SOA逐步演進示意圖》
《圖四 SOA逐步演進示意圖》

制定服務規格

每個專案所建構的服務,都需要針對服務的各種特性擬定細節。德國郵政公司採用三步驟的服務規格法。第一步驟得自於服務發掘過程,提供一個「企業服務說明」搭配德國郵政的企業架構模型。這個企業商務物件與服務模型,旨在說明服務架構的邏輯觀點,其中包含商務領域、物件與服務。在這個模型中,各種服務以介面加以描述(UML為其正式語言),服務操作的相關說明,則參照模型中的商務物件與其他資料類型。


第二步驟為詳細的商務服務規格,其中包括:擬定服務介面的細節、分析IT專案的特定層面(例如服務範圍的可能限制),然後進行服務的實踐或獲取。商務服務的規格在服務設計過程中相當重要,因為這些規格是該服務所牽涉的人員之間基本的溝通方式。在擬定服務規格時,應該考慮下列幾大類的資訊:


  • ●定義:服務與服務操作的名稱,每項操作的輸入與輸出參數,可接受的呼叫方式(例如同步、非同步等等),服務的分類(商務服務、技術服務、基礎架構服務等等;或是流程導向、商業邏輯、資料存取等服務)。


  • ●QoS/SLA:這一類資訊主要關於服務的效能品質,包含負載量與回應時間、可用性、故障備援反應、可能的SLA等實用細節。


  • ●限制因素與方針:包含服務呼叫之前與之後的條件,可接受或預期的輸入/輸出參數範圍(包含傳回的錯誤訊息),各項操作的呼叫順序,安全性規範與其他重要的方針也可以包含在此之列。


  • ●歸屬:關於服務的歸屬、誰必須負責維護該服務等相關資訊。


  • ●版本資訊:這一類資訊包含該服務過去、現在、未來所規劃的版本與狀態,以及不同版本之間的相容性問題等資訊。


  • ●操作行為與使用形式:這一類資訊對於複雜而不明顯的服務特別有用,其中包含該服務各種不同的建議使用方式等相關資訊。



服務規格的最後一步是「技術服務規格」,特別探討服務仲介平台的相關要求,而其他先前所未提及的技術規格(例如特定的資料流量、訊息大小等等)也在此詳細說明。將服務加以適當分類,也有助於該服務在設計與建構上應用業界最佳慣例。


一項服務的功能、品質與方針,定義了服務供應者與消費者之間的合約型態,這也就是所謂的服務契約。目前產業界並沒有全體通用的服務規格標準,但WSDL與UDDI已經儼然成為基本服務規格的描述與發表標準。此外,現在也有愈來愈多的試驗採用WS-I(Web Services Interoperability)規格,讓服務能更廣泛地重複使用。


規格的重複修訂,可以產生更精緻、更紮實的細節,具體說明服務的介面與功能性,讓服務規格可符合目前的需求以及未來預估的需求,使服務更具彈性及成本效益。服務規格的重複修訂,通常需要商務服務歸屬者、商務分析師、技術分析師三者之間密切的配合。


服務的最佳粗細度?

SOA開發人員常常爭論服務的最佳粗細度,雖然服務粗細度目前並沒有一致的量化標準,但可以沿用元件設計的理念,例如:呼叫該服務所影響的功能點或資料元素數目。如果一個服務在商務應用程式中呼叫的次數太頻繁,或通常只有一小部分的功能被使用,則該服務可能劃分太粗。如果一個服務需要太多的參數,則該服務可能太低階、劃分太細。雖然這些觀察乃是以實際的服務建構結果為基礎,這個問題仍可透過有效的服務套件與生命週期管理過程來解決:服務套件的適用性可隨時間大幅成長,首先針對高價值的服務運作來著手,然後逐步加以擴充、演進。一項服務若能達到適當的粗細程度,將可發揮最高的簡便性、重複使用性以及可管理性。最適當的服務並不一定要以粗細度來區分,而應以能否發揮最高商務價值來考量。


德國郵政公司通常將較粗的服務首先加以建構,這些服務都是較穩定的基本服務,從一開始就可以確立。漸漸地,服務消費者愈來愈多,需求也愈來愈精細,因此可以建構較細的服務運作。這些精細的服務運作可提供良好的基礎,用以制定一套更豐富、更複雜的服務運作。例如,可將服務彼此結合(複合式服務運作)或搭配成一套流程(搭配式服務運作)。


服務建構與生命週期管理

雖然服務的建構在大多數層面與軟體開發相差不多,不過仍有兩大差異。


第一點,根據所選定的服務仲介平台,其服務介面程式碼不一定要人工撰寫,如果有合適的服務設計工具鏈,可以透過工具自動產生。德國郵政公司根據模型導向架構法,採用一套服務設計工具鏈,起點為企業商務物件與服務模型,接著將這個模型轉變為專案商務物件與服務模型(PBSM)。PBSM的細節在專案規格中進一步敲定之後,工具鏈可以產生德國郵政公司SOPware服務仲介平台的程式碼骨幹,以及服務規格說明文件。服務規格採用適當的工具建立模型,而XML與XMI則是廣獲肯定的標準化交換語言。


第二點,在建立或獲取服務仲介平台時,必須謹慎考量該平台是否支援服務測試,因為服務本身需要鬆散耦合的環境。以德國郵政為例,服務模組的測試採用DevBox,該元件為SOPware的一部分,可提供服務呼叫程式庫,並可在開發人員的本機電腦上模擬服務供應者。除此之外,德國郵政也設立了一個服務架構測試實驗室,該實驗環境提供了所有服務與服務供應者,以供SOA應用程式的整合測試之用。


雖然服務介面將成為企業架構中的穩定要素,服務將會逐步成長,因為愈來愈多的服務運作將加入系統中,不過隨著幕後的服務供應者逐漸改變,服務的建構方式也會變遷。儘管SOA架構可以將變遷的影響降到最低,服務的生命週期還是需要管理,其中包括版本控制、商務服務儲存庫(包括服務模型與規格)、以及可在建構與執行期提供服務實體存取的技術服務儲存庫(服務登錄庫)。


技術考量:服務平台與標準

從以上得知,商務服務可以將商務變遷與IT變遷有效解離,但服務仲介所需的IT基礎架構(或其中某些要件)也有需要變動的時候,許多企業在EAI或舊型中介軟體之中糾纏不清,無法切實配合商務所需的腳步而變遷。當某些技術已經過時而無法因應效能成長需求時,仰賴特定工具的EAI配接器與介面,由於需要專屬的中介軟體協定,因此不能輕易地加以轉移,在這種情況下,原先預計藉由科技所實現的彈性也不復存在。


採用標準化的服務仲介方式或可解決以上課題。例如新發表的Java標準JBI(Java Business Integration)、或是類似德國郵政SOPware的方式(其也是採用JBI)。SOPware之中採用了另一個抽象層,特別將商務服務邏輯與其下的IT基礎架構互相解離。這個抽象層完全採用J2EE(也可選用.NET)、XML、WS-I等標準。在2001年完成開發的SOPware,經過技術進展與功能擴充過程,幾乎所有的基礎架構元件(例如應用伺服器、MOM、目錄伺服器、轉型引擎等等)都已經經過有效的更新升級,但開發介面仍然不受影響。關於服務的仲介方式,開發人員只需知道簡單的XML語法API,即可開發服務或呼叫服務,相關的技術細節與工具則隱藏於幕後。程式設計師可以專心建構商務邏輯,不需要浪費時間撰寫低附加價值的基礎架構碼。對於德國郵政而言,這種策略提供最佳的彈性與投資保障,這不僅針對商務邏輯而言,對IT基礎架構也有傑出的效益。


結語

雖然有許多科學原則可作為服務發掘與設計的指引,但如同許多架構研究一般,業界老手的直覺經驗在整個發展過程中相當有益,尤其對於初期開發過程更為顯著。SOA的實踐,需要快速而簡易的建構方式:商務人員應該以商務邏輯為重,而不應該操心通訊協定與傳輸方式,因此採用功能完整的SOA平台可說是相當實用。此外,採用開放式標準與模組化技術元件,可以讓SOA資產的重複使用率更高、TCO更低,並可避免被廠商牽著走,也可降低採用SOA技術的風險。


簡而言之,SOA=語意整合+鬆散偶合+系統化演進。SOA可作為商務人員與IT人員之間的共通語言,消除許多企業長期存在的代溝,突破交流瓶頸,讓商務流程與IT基礎架構發揮更高的彈性。(作者為美商甲骨文Oracle台灣分公司解決方案協理)


相關文章
甲骨文預測:2020-2025年十大雲端趨勢
服務導向裝置的下一步?
完善、整合-從手機功能的變化發展看資料庫效能的擴展
企業績效管理(BPM)概述
商業智慧平台面面觀
comments powered by Disqus
相關討論
  相關新聞
» 數智創新大賽助力產學接軌 鼎新培育未來AI智客
» 鼎新攜手群聯首發AI私有化方案 揭開數智工廠ESG、AIoT運行新模式
» 鼎新攜手微軟、群聯雲地混合 助力企業彈性發展AI應用
» AWS推出生成式AI服務 協助開發者快速打造應用程式
» NTT DATA與來毅合作 導入Oracle NetSuite ERP系統加速國際布局


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.3.133.133.39
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw