三部曲:Web services之規劃策略

李清培

弈飛資訊首席顧問 /台灣微軟特約資深講師

在上一篇文章中，我們談到了以Web services作為存取介面的服務導向應用程式架構，以及其與企業應用程式之間的關聯；其中最重要的關鍵點在於如何利用“服務導向的應用程式架構”滿足企業應用程式強烈的 “彈性”與“整合” 之需求 。這個月，我們將進一步的談談，如何將Web services應用在真實的企業環境，以及其規劃策略。

Web services企業運用設計模式

在談到如何將Web services導入到企業的系統架構中之前，還要再強調一次，雖然在以下的各種應用模式中，使用的是Internet的技術，但Internet只是Web services的手段，而非Web services的目的。Web services不是只為了Internet而設計，重點在於他是一種使用標準技術的分散式應用程式。

分散式應用程式讓企業在建置資訊系統時不論在採購上或建置上都更為彈性，企業可依需要不斷的擴充系統，而不需在初期即一次購足；企業也可以將系統以功能模組的方式分階段建置或升級；企業也可以依實際需求，將資料庫或資訊系統分布在不同的地方，再以網路加以連結。分散式應用程式有助於將商業邏輯集中管理，並取得較佳的安全機制，另外在伺服器與資料庫資源的充分利用以及多樣化的用戶端的設計模式，更是分散式應用程式所帶來的好處。

然而隨著市場全球化以及網路經濟的成形，雖然給了分散式應用程式一個絕佳的揮灑空間。卻也因此突顯了一個嚴重的問題，也就是在上一篇文章中所提到異質平台的問題。理論上，分散式應用程式只要設計得當，便可以將分散在各地的系統與資料整合成一個抽象的大系統，但由於各家系統廠商所使用的技術不同，以及新舊系統技術與設計概念不同，所導致的不相容問題，使得分散式運算的優點大打折扣。因此在發展新一代分散式應用程式時，就企業觀點而言首先必須解決的，是企業內系統整合的問題，包括資料的整合與應用程式的整合，如何讓異質平台或新舊系統間的資料能互通，以及新開發的應用程式能繼續使用舊系統或異質平台的應用程式，以保留就有投資的價值。再來則是跨企業間的程式互通，包括B2B的電子商務，以及供應鏈的整合。最後則是各應用程式的流程整合。而Web services則是符合這些需求的重要技術。

除了解決企業全球化與網路化的整合需求以外，延伸自Web services的特殊技術，也為企業帶來了另一種商業價值，這種價值來至於Web services的商品化，也就是在上一篇題到的軟體服務。這種直接出售Web services的軟體服務，包括功能性的隨選服務 (Services-on-Demand)，以及組成應用程式的軟體積木等。

接下來我們就一一的介紹如何將Web services導入到企業的真實環境，以及其規劃策略與所帶來的好處。

企業應用程式的整合

對於許多企業而言，使用 Web services 的第一個實作通常會是內部應用程式的整合。利用 Web services 延伸或擴充原有應用程式的功能，或將不同系統，以 Web services 加以連結或整合。

企業應用程式整合工作如果加以細分，包括應用程式的整合、資料整合、與流程整合。關於流程整合在後面再來談。應用程式與資料的整合需求對許多企業來講是很重要的議題。當企業合併或併購時，原本不同企業的資訊系統需要整合成一個完整的資訊系統；開發新的系統必須與舊的系統整合；企業因需求與設計考量，將原本集中式大型主機系統改為分散式應用程式系統時也需要整合，尤其當系統或資料庫是分散在各地時，必須透過Internet整合加以整合；再來則是企業再進行軟體採購或委外服務時，為了符合最佳的經濟效率或協力廠商使用技術的限制，常無法取得與原有系統相同技術或平台之解決方案，這時候也需要整合。

企業應用程式整合的市場仍相當龐大，而每個專案動則花費數百甚至數千萬的預算。目前市場上整合的解決方案很多，但大多是一對一的整合，典型的像連結MSMQ與MQSeries的FalconMQ。 Web services 則提供另一種全然不同的方法，利用實作標準介面的方式，進行多點的整合。只要將現有的傳統系統可以包裝成Web Service ，便可與企業內的其他系統整合使用。利用這種技術，將複雜的舊系統包裝在標準的XML之後，以Web services的標準溝通介面，取代原有一對一的整合方式，同時在規劃時，還可以依需要，僅選擇一部分或全部的功能作為整合的介面。

供應鏈的建立與開發

另一個驅動 Web services 發展的主要力量則為 B2B 的商業模式。有人甚至斷言供應鏈整合將會是最具威力的 Web services 應用程式。主要是因為供應鏈影響的範圍廣，而 Web services 提供供應鏈應用程式所需之 XML 及相關之產業標準。在一份由InfoWorld (http://www.InfoWorld.com) 針對CTO所作的調查統計，70%的CTO認為Web services 對企業最有影響的是在B2B電子商務上。B2B應用程式可以像信用卡驗證這樣簡單或者像產業的供應鏈這樣複雜的程式。建置B2B應用程式的挑戰結合B2B背後的廣大市場潛力是驅使Web Service快速改進的原動力。

台灣的B2B計畫，最重要的應該是由經濟部技術處主導的A、B、C、D、E計畫。其中A計畫，讓HP、Compaq、IBM將採購資訊下放到台灣來；B計畫則把華碩、仁寶、英業達等15家台灣廠商的資訊與美國採購商搭上線，讓台灣的製造業在世界PC市場上，保住一年180億美元的市場。A、B計畫的核心，是以「大廠為中心廠，帶動下游供應商加入」的垂直聯結方式，藉由Internet將市場變動的資訊，即時回饋到計畫中的產業，讓廠商可以針對變動來調整庫存。

另一個不同於A、B計畫的，則是由下游零組件大廠明基與資策會合作的「星動計畫」，在這個計畫中，Internet所連結的是一種水平溝通的電子交易平台（Hub），以「水平」的產業平台，取代「垂直」的供應鏈體系。星動計畫是以資策會開發的viaHub作為公共平台，讓參與廠商、供應商之間可以跨越不同的系統平台作RosettaNet的資料存取。

除了製造業以外，傳統各產業之間其實都存著一套共通的電子交換格式EDI以進行B2B的資料交換，不同於Web services的是，這些交換格式都並須建立產業間特殊的交換平台與資料格式或規範，而Web services不需要特定平台，Internet本身就是一個很好的平台，只需依XML的規範，定義各產業的Schema，即可在共通的標準上進行交易，利用Web services建置的好處在於他的建置成本低，參與的廠商利用Web services的標準規範建置溝通介面，只需按照各產業所訂的標準定義描述資料的名詞及內容格式即可，例如一筆訂單資料應包含哪幾個項目，訂單是用Orders還是PO來表示等。另外一個好處在於這樣的規範還可以是跨產業的，B2B不是只有供應鏈而已，還必須考慮金流、物流等，這些都會應用到跨產業的溝通方式。因此，以Web services作為B2B溝通介面的規劃策略，具有相當大的彈性與經濟效益，也因此有些權威人士認為供應鏈整合將會是一個殺手級的Web Service 應用程式。

現有與未來應用程式的擴充

由於目前個人所能取得的數位週邊設備相當豐富，除傳統PC與筆記型電腦以外，PDA、手機、簡訊等，使得用戶端程式的客製化顯得非常重要，其中尤以手機最為嚴重，由於消費性產品的市場化，各家在樣式上求新求變，使程式開發工作更為困難。Web services 繼承自分散式應用程式商業邏輯集中的優點，可以快速開發多樣化的用戶端程式。只要將商業邏輯以Web services呈現，再針對不同用戶端撰寫資料展示的方式就可以了。目前市場上的用戶端程式開發工具，大多數都支援Web services的存取，其中Visual Studio .NET更可以在單一的畫面裡面，完成所有應用程式的開發。

然而對大部分的企業而言，許多的商業邏輯都已寫完，而且行之多年，不可能為了開發一隻手機的程式，而將整個程式重寫。前面提到，Web Service提供一組吸引人的技術，就是將現有的傳統系統包裝成Web Service ，以提供其他應用程式使用。藉由這種方式，不只可以享有Web services所帶來的便利，更可因此延伸原有應用程式的生命週期。

在這裡舉一個典型的例子，在擔任.NET開發技術的講師與顧問的兩年多時間裡，

 最常碰到的問題是有關ASP.NET網頁設計的問題。由於ASP.NET提供像VB開發視窗程式一樣拖曳的視覺化開發環境，使得很多人就習慣性的將兩者拿來比，但事實上這兩者還是有差異的。網頁的程式，由於透過Internet在伺服器上執行完畢後，再將結果傳回用戶端展示層，因此有其先天上的限制。

很多人會希望能符合老闆以及市場形象的需求，使用Web based的架構，(在一些特殊的個案中，企業選擇Web based的原因是因為老闆認為這樣才跟得上時代)但用希望像視窗程式一樣的使用者操作介面，其實透過Web services就可以解決這樣的問題。

另外一種則應用程式擴充的例子，則是將應用程式系統分為核心程式與服務程式，將必要的程式邏輯部分也在核心程式，在以Web services的方式依功能分類，撰寫各個服務程式。可以將核心程式當作是主機板與CPU等重要元件，而各個服務程式則有如週邊設備一樣,可依需要隨時擴增。

降低系統建置的時間與成本

除了解決應用系統整合與溝通上的問題外，對於新系統的開發，Web services也可以降低開發的時間與成本，這一類的設計模式大概可分為幾種狀況。

第一種稱為軟體積木的開發方式，企業直接利用Internet上的Web services，以軟體積木的方式，加快系統開發的速度，尤其對於一些輔助性的功能，或一些共通的商業智慧。在上一篇文章中，我們也舉了Google的例子，您可以直接使用 Google 所提供的 Web services，就可在應用程式中加入此一功能。除此以外，由微軟所提供的.NET My Service也提供了非常多的軟體積木可供使用，其中最為熟悉的應屬Passport驗證機制。

另外對於新市場的開發，企業往往必須重新熟悉這一個市場的商業邏輯或專門的技術，而透過Web services的服務即可快速的修正系統的功能，以加快新市場的開拓。例如企業在進行全球貿易時，除了基本的商務應用程式外，可能還會建立連接貨運倉儲部門與國際貨運公司間的B2B運輸系統。這樣的系統通常是以緊密結合的方式所建立，也就是企業的資料庫裡，必須知道貨運公司的價格、航班、週期、速度等。當企業的業務拓展到新的國家時，如果原有的貨運公司無法到達時，這時候只有兩種選擇，第一是放棄市場，第二是重新洽談另一家貨運公司，重新改寫程式。但如果反過來，這些B2B的關係是建立在Web services的連結上，只要透過UDDI找到所需的服務，便可輕易的進入新市場。

再來則是企業在提供全球技術服務時，也可以利用Web services來達到技術支援的目的。例如目前主要汽車大廠的服務點都以全球部署作為其市場競爭的利器。而針對高階人士設計的筆記型電腦，為因應國際商務的需求，也都強調全球保固的服務。然而這也衍生一個問題，由於服務點遍佈全球，各地的技術水平並不一致，如何達到相同的服務品質，則是一個很大的考驗。

以汽車廠為例，假設今天擁有一部數百萬的進口名車，在台灣要找到維護場並不難，但今天如果在某些落後國家，狀況可能不一樣了，即使原廠所設的服務點，也會應當地的技術人力，而有所不同。幸運的是，目前大多進口名車都採取電腦診斷的方式以進行故障排除，因此只要能提供詳細的檢修步驟，讓維修人員按照步驟完成檢修工作。

然而這樣還不能完全解決問題。由於修護系統的高度機密與價值，不大可能在所有的地方都建置一套這樣的系統，這時又是Web services發揮其強大功能的時候了。這些汽車大廠可依各服務點的規模及技術能力等，建置一般功能的維修檢測系統，以應付一般性的檢修工作，對於重大的或具機密性的技術，則至於原廠或各地區之核心廠。當各小型檢修場無法判讀汽車電腦晶片內的數據時，再透過Web services連接原廠或各地區之核心廠取得相關檢修步驟。如此不但保有技術的機密性外，又可符合全球服務的需求，更重要的是，當擴點需求產生時，可加快建置的時間，而當重要的技術問題產生時，只需更新原廠或各地區之核心廠的資料庫，即可將資料傳送至全球的檢測系統。

軟體租用新模式

以上所舉的例子都是以使用者的角度區看，在上一篇文章中提到服務導向應用成架構實提到，參與這個架構的還包括服務提供者與服務登錄與代理兩個角色。前面也提到Web services本身也可以當作一項產品來販賣。出售服務的架構其實到處都有，只不過型式不同罷了，目前網際網路裡面，線上刷卡代收服務是最典型的例子。

將 Web services 當作交易的標地，可能影響到資訊系統的設計、部署與採購模式。企業可經由外部所提供之軟體服務，取得執行商業行為所需之應用程式功能，而不需全然由內部來開發。透過這種方式，程式開發者不須再使用傳統建立單一、集中式伺服器應用程式的方法，即可快速地建立或延伸現有應用程式的規模。企業因此可節省系統開發所需之時間，加快市場開發速度。

對服務的提供者而言，大概可以有幾種模式，第一種可能在軟體銷售/採購的方式改為租用或隨選服務的模式；這裡提到的租用與隨選服務事實上是有差異的。ISV可以將核心程式及部分的模組直接安裝於客戶端，以租用的方式實施，而為了避免租期與租金的爭議，可保留一小部分的啟動機制至於ISV的伺服器上。在租約期間，客戶透過Web services機制，聯結至ISV啟動其應用程式；租約到期，ISV僅須關閉此一機制即可。至於隨選服務，則針對一些工具服務，或延伸的功能，讓客戶依需要連結使用。

企業也可以利用 Web services 將原有企業的智慧財產或成功經驗，重新包裝出售，以開拓全新的軟體服務市場。對ISV或VAR、OEM等廠商，更是提升商品附加價值的方式。

對於一些電子資訊提供者，也可以改變提供的格式，目前大部分都是透過電子郵件或網頁瀏覽方式，未來也可以利用Web services提供相同的資訊，讓用戶端可以直接加以利用，將Web services當作資料來源，直接提供應用程式存取。例如在設計網頁時，若希望能取得氣象、股票、球賽、產經最新消息，只要將所需之資訊版面空下，利用網頁上的控制項直接連結個資料來源之Web services，即可取得最新的資訊。而服務的提供者則可依訂戶的需求收取不同之費用。

企業流程管理

最後則來談談流程整合的部分，之所以會留到最後在來講，主要上避免在談到流程整合時，只侷限在企業內得整合。利用 Web services 加上流程管理軟體，可以讓企業內部或與外部合作夥伴間建立起天衣無縫的作業流程，更可依需要不斷的加入應用程式模組，而不影響到其他的應用程式，這些模組可以自行開發，也可以直接使用ISV所提供資訊服務。如此不但能提升企業組織的效率並降低企業經營的成本。或許您要問，目前已有很多的流程管理軟體與跨平台整合軟體，位什麼還要有Web services，這是因為這些軟體都是為個別系統間整合所設計，即使主要大廠所提供的流程管理軟體，包括Microsoft、IBM、BEA等，也須為不同的Adapter付出不同的軟體授權費，若採用Web services則不須為不同的系統就要採購另一套整合或流程軟體。

導入時機

看完了以上的文章，或許會懷疑，這樣的技術成熟了嗎？我需不需要導入？要如何導入？而且在前兩年，資訊界還傳著一個很奇怪的說法，雖然各主要大廠及WS-I組織以提供相當完整的規範與技術，但還是有些所謂權威人士會說Web services是個不成熟的技術，還不能導到企業中使用。雖然對於全面性的將Web services應用到全球的網路經濟還有些技術與規範要克服的，但也有不少廠商與政府或非政府機構以成功的導入Web services。若要等一套技術完全成熟在一次導入，那時候可能又已經推出另外一套更新的技術，或許我們把他當作是一種市場競爭的手段罷了，對於技術跟不上速度的廠商，通常會以這種方式以減緩對手搶攻市場的速度。

下回我們再來分析哪些技術是可以導入的，哪些是還有限制的，哪些是目前不可行的，以及導入的步驟。