Web services設計模式--企業觀點

後章:Web services之導入與平台選擇

 

李清培

弈飛資訊首席顧問

台灣微軟特約資深講師

 

在前幾篇文章中，我們由商業世界與電腦世界的關係談起，再談到Web services 的發展背景與商業行為之改變，接著則進一步介紹Web services的應用程式架構，並談到如何以服務導向的觀念，將商業行為對應到資訊系統服務架構，上一篇文章中我們也針對Web services在商業行為上的應用以及其規劃策略作了一些說明，然而，看完了以上的文章，或許會懷疑，這樣的技術成熟了嗎？我需不需要導入？以及要如何導入？以下我們就來介紹如何導入Web services以及不同平台與開發工具之比較。

導入時機與步驟

新技術的導入，往往決策本身就是個很大的挑戰，需不需要導入、何時導入等問題就可以讓決策人員傷透腦筋。當然有些企業可能因企業文化或營業項目的需要，總是一味的追求新的東西，只要有新的技術就照單全收，這一種適合以技術服務或IT顧問服務為主要營業項目的公司。另一種模式則恰好相反，是屬於極度保守的，通常要等到同業都作了，或是有更新的技術發表(原本的新技術已經變成舊技術了)，甚至舊技術已經找不到資源了，才想到要更新，這種做法通常是對資訊技術依賴不大，或公司年代久遠，舊系統資料龐雜不易更新的企業。在擔任企業SQL Server 2000的技術支援經驗中，有幾個升級個案便是從NT 3.51加SQL 4.2 直接升級到Windows 2000 與 SQL 2000。當然也有一些是想由DOS系統升級上來的案例。不過，一般會對這篇文章有興趣的，就算不是新知的絕對追求者，也不大可能是極度保守的人，至少都是對新技術具有一定接受度的朋友；當然絕大部分也不會是所有新技術都照單全收的。因此，既不能照單全收，也不能枯等坐失良機，那麼何時才需要導入Web services呢？要回答這個問題，以下幾項參考依據可供您在作決策的參考：

u         企業應用程式架構，使用元件或物件的程度。

u         開發部門對“存放與轉寄”的訊息架構(Store and Forward)是否了解。

u         是否想將一些客製化的應用程式產品銷售到開放市場。

u         使用Web services是否能為企業帶來市場競爭優勢。

u         使用Web services的開發模式，是否可以為企業降低成本。

以上問題可以歸類為兩大部份，首先是評估企業對物件導向/訊息架構的使用成熟度，這一部份將會牽涉到Web services的實作能力。雖然物件導向程式已經發展多年，許多的ISV也都宣稱以物件導向的方式在開發應用程式，但在個人輔導企業的過程中，常常發現有些企業應用程式，仍然是功能函數導向的設計方式，只是利用物件將一些函數整合在一起而已。另一方面則是評估導入Web services對企業所帶來的實質利益在哪，任一項技術的導入，都必須有其價值存在，不是為了導入而導入。如果您的企業已經具有開發、建置、或使用Web services的能力，而且也清楚的了解Web services能為企業帶來什麼，那麼現在就是最好的導入時機。如果您的開發人員還不具有開發Web services所需的技能，也找不到相關可提供技術支援的合作夥伴，或是您還無法明確的了解Web services未來在企業應用程式中所佔的角色，那麼目前先不要急著導入。

以上的判斷方式是來自於企業內部的內省；另一個判斷的方式則是來自外在的，例如產業的趨勢，或合作夥伴的要求等。尤其當企業對Web services的應用還不是很明確的時候，參考業界的案例或產業的趨勢，也是一個很好的方法。雖然目前台灣真正完全導入Web services的不多，但全球已有許多成功的案例可供參考。在上一篇文章中，我們也介紹了幾種Web services的應用與設計模式，如果將全球使用Web services的方式加以分類，大致可分為三大類：第一類為利用Web services強化內部商業流程的效率與降低成本的做法，最典型的就是用在企業應用程式整合(EAI)上，或是利用Web servcies延伸舊有應用程式的功能或提供Internet的存取介面，以減少開發網際網路應用程式所需的時間與成本；第二類是利用Web services處理B2B的交易，也就是在第二篇服務導向應用程式所說的Services-Bus的觀念。Web services在B2B市場中所具有的最大優勢在於它比目前所有的EDI應用程式都要簡單，大幅降低了許多程式的複雜性，而且架構更為標準與彈性。可以預期的，隨著B2B市場的擴大，Web services在網際網路技術的覆蓋率將越來越高；第三類則為利用Web services 提供個人或公共服務。實務上企業利用外部所提供的專業性軟體積木來開發應用程式，或提供軟體積木給其他企業使用的不多；而提供免費公共服務的則以微軟的.NET My Services為代表；除此之外，前面介紹過的Google所提供的搜尋引擎Web services也是很典型的一種軟體服務。企業可參考上一篇所介紹的各種應用模式，如果其中某一種模式恰巧可以解決企業目前所面臨的問題，或著可以預期地為企業帶來相當的利益，或許您也可考慮導入Web services。

經過上述由內而外的考量之後，下一步就是決定是否要導入Web services。如果答案是肯定的，接下來再依據自身的能力，選擇適當的建置方式，並著手進行規劃與規範訂定，最後再依據規範及所選擇的建置方式，選擇適合的平台與工具進行實作。接下來就來談談建立Web services的方法。

建立Web services的方法

雖然說企業在導入Web services之前，必須先衡量自身掌握Web services的能力，但並不代表企業必須由無到有去實作Web services。我們一再強調Web services的好處在於開放的標準與彈性，標準的東西讓企業應用程式系統可以跨平臺的整合，而彈性的架構意味著可以依企業需要，以模組化的方式加以組合。只要依循產業的標準，就可以將不同平臺的應用程式系統，不管是硬體也好、軟體也好，都能夠整合在一起，既可保障企業原有的投資，更可改善工作流程提供生產力。也因此在Web services的實作上就有很多的方法可以選擇，以下介紹幾種可行的方案以供參考。

首先可以依企業的技術背景選擇系統或軟體供應商所提供的應用程式伺服器平台，這些專門為Web services所設計的應用程式伺服器平台通常包括一整套的開發、展示、與部署工具，以協助開發人員快速建立Web services，同時各供應商通會在平臺中提供一些加值的軟體服務，可能包括流程管理軟體、安全機制、交易處理機制等底層服務，以減少開發人員的負擔，並降低程式的複雜性。目前市場上的應用程式平台可分為兩大類，一種是提供完整的開發環境、硬體設備、及專業的服務，這一種模式比較像傳統垂直整合的SI公司做法，其中以IBM、Sun、HP為代表，詳細部分在後面市場概況再作說明。另一類則以Microsoft與BEA為代表，以水平整合的方式，提供完整強大的開發環境及相關的底層架構為主，並不以銷售硬體為主要獲利來源，因此企業可以有更彈性的選擇，尤其當Web services走向標準後，實在沒有道理在綁在某一種硬體、平台或程式語言上，應該是一種跨硬體、跨平台、跨語言的解決方案才對。

第二種方式，若企業具有強大的開發能力，則可以選擇直接採購或取得適當的開發工具，自行開發Web services應用程式。目前除各家大廠所提供的SDK外，最主要的還是由開放原始碼的Apache XML專案所提供的許多開發工具。不過選擇這種方式企業必須自己有能力處理不同應用程式間整合的問題，同時還必須進一步的自行加強或建置應用程式伺服器的環境，包括底層服務、流程管理與其他加值服務。通常選擇這種做法的結果，都會再結合第三種做法，或是回到前面再找系統廠商協助，也因此有些硬體廠商會先以開放原始碼的方式先導入，事後再收取高額的顧問服務費。因此除非開發團隊的技術能力夠強，或是系統實在是很簡單，否則還是不要選擇這一種方式。

第三種做法就是委外服務的做法，可以直接請IT顧問廠商協助開發，或直接交由合作廠商代為開發。

最後還有一種做法雖然目前不大可能，但未來卻很有遠景，也就是之前提到過的軟體積木或軟體服務。由ASP業者將軟體元件或商業智慧以Web services的方式提供給客戶使用，並收取一定的服務費。但礙於目前交易機制、安全機制、商業智慧、目錄登錄機制、及收費機制等還未完全建立，應此還不適合在開放市場中直接銷售Web services。由ASP業者提供軟體積木或軟體服務，企業只要依其需要加以組裝即可。或許有人認為這不大可行，在微軟以前，也沒有人相信軟體可以獨立於硬體而單獨銷售。然而當軟體與硬體的分開銷售的模式形成後，也使得資訊市場由傳統的垂直整合轉變為水平整合的競爭環境。

選擇平台及開發工具

若您已準備要開始建置Web services的解決方案，那麼，在資訊系統的建置上，平台與開發工具的選擇亦是一個重要的課題，這一方面是否具有像Web services一樣的彈性呢？這個答案是肯定的，很多人一聽到平台的選擇，立刻想到.NET與J2EE的競爭，這樣就完全背離了Web services的精神。Web services 特色之一就是要讓應用程式之間很容易的整合及溝通，而不論所使用的是哪一種語言與平台，在傳統的垂直整合市場中，我們幾乎毫無選擇的只能向一家公司購買整個解決方案，從硬體設備、作業系統、應用程式、網路設備和服務，每家廠商都有自己的垂直整合方案，即使號稱所謂跨平台的規範，在各個系統廠商客製化，最佳化、或特殊化的結果的結果，整合不同廠商既困難也不經濟，更不趕輕言更換系統。因為整個解決方案從硬體到軟體是環環相扣，牽一髮動全身。再加上軟硬體規格綁死的狀況下，無論建置、服務、與維護成本都高得離譜。尤其以硬體見長的台灣，似乎無法因此取得相對的優勢。

在資訊產品形成規模經濟之後，垂直整合的的架構不再是唯一的選擇。客戶可以在每一個環節上，由硬體設備、晶片、處理器等，到系統軟體、應用軟體、開發工具及系統整合服務等，都可依企業的需求選擇適合自己的產品，雖然原有大型垂直整合廠商仍佔有大部分的市場，但已紛紛改變策略，開始分割並重新包裝原有解決方案，提供客戶彈性的整合。您不需再像以前被大型系統業者牢牢的綁死，取而代之的是一種超彈性的選擇。未來在規範標準化後，市場的競爭不在於哪一個平台超越另一個平台，而是在於誰能提供快速、安全、與準確的實作能力。

選擇.NET或J2EE

目前在實作Web services所使用的平台架構包括.NET與J2EE，相關支援的產品與開發工具也非常多。對於慣用 Java 的開發人員，.NET 可能看起來類似 Java 平台；它們都提供結構化的方法來建立應用程式，都將語言編譯成中繼程式碼，而且都提供應用程式開發所需的龐大 API 程式庫。不過，.NET 的核心目標不同於 Java 平台。

在概念上，Java是由Java 平台 (Runtime 和 API) 和 Java 語言所組成。Java 平台的目的是支援使用 Java 語言撰寫的應用程式，並將它編譯成 Java Bytecode。雖然有人將其他語言編譯成 Java Bytecode，但也只是學術上的研究而已。Java 的理想一直都是在多重平台上使用單一語言。

而.NET 則是由.NET Framework (Runtime 和 API) 和支援程式設計語言的所組成。.NET Framework 的目的是支援使用任何語言撰寫的應用程式，並將它編譯成 MSIL。.NET 的目標是多重語言共用單一平台，由於MSIL所使用的CLI規範是開放的，目前支援.NET的語言早已超過25種。

目前所發表有關.NET與J2EE的比較上，大多數的評比項目.NET都略佔上風，其中VeriTest在2002 年 5 月所作的一份報告顯示「在無快取的狀況下，Microsoft 的 .NET 應用程式在效能上明顯優於 Java 應用程式，在 5,000 位虛擬使用者的狀況下快了超過 10 倍，在快取狀況下效能快了超過 2 倍。」(VeriTest(R) Benchmark and Performance Testing Microsoft(R) .NET Pet Shop http://www.gotdotnet.com/team/compare/veritest.aspx)。另外一份代表性的報告則是由一直支持J2EE，並以J2EE作為其企業核心技術的Middleware公司所作的報告，其結果.NET仍然是優於J2EE。雖然 Java 的理想“Write Once, Run Everywhere”非常吸引人，但目前大多數應用程式都只針對單一作業系統來設計，而且實務上，因為 Java Framework 受限於廣泛性和豐富性，程式\開發人員必須經常使用專屬類別來存取平台上的功能，各家應用伺服器廠商在市場競爭的環境下，也必須針對自己的硬體、系統、資料庫等作最佳化，因此常有些專屬的類別庫，這些不同供應商實作之間的不相容性持續困擾著真正的跨平台工作，開發人員必須在想要支援的每個平台上測試其程式碼。因此，有些開發人員半開玩笑地戲稱 Java 為「撰寫一次即可隨處偵錯」平台。而.NET所提出來的概念則是提供快速的整合開發環境，協助系統及Web services建置，利用Web services的loosely couple模式，達到“Write Once, Connect Everywhere”的目的。所以如果真的要把Web services的競爭當作是.NET與Java的一場戰爭，目前看來，.NET是暫時領先的。

 資料來源：Middleware Company

http://www.middleware-company.com/j2eedotnetbench/

 

資料來源：Middleware Company

http://www.middleware-company.com/j2eedotnetbench/

 

 

Web services的市場概況

嚴格上來說，並沒有所謂的Web services市場，Web servies只是“應用伺服器”市場的一部分而已。什麼是應用伺服器呢？應用伺服器可以說是一個產品的集合名詞，提供應用程式開發、部署所需之軟體，並包括延伸的加值功能，以利於系統建立、部署、與維護。目前實場上的應用伺服器主要由幾家大廠提供，其中IBM、Sun、Oracle提供J2EE-based的應用伺服器，BEA則提供可在不同平台執行的Web services平台及開發工具，Microsoft則提供在Intel-based硬體平台上所能執行的應用程式平台、程式語言、開發工具、及其他流程管理及內容管理等加值軟體。Microsoft的策略稱為.NET、Sun的Sun ONE、HP的Netaction、Oracle的Dynamic services等 ...，各家都想成為市場主流。這場競爭的賭注其實相當大，根據Giga Group的預測，應用伺服器市場的獲利在2001年約17億美元，但2003年預估將高達90億美元。而競爭激烈的原因不只是金額成長而已，而是因為資訊決策者對系統平台的忠誠度問題，通常選定平台或解決方案後很少再更改了，而目前應用伺服器市場的競爭都是為了看到Web services的龐大市場而準備。如前面所說，Web services所牽涉的不只是一些通訊協定、目錄、登錄等標準的實作而已，建立Web services還需要有其他額外的流程、開發、整合、安全、維護、管理等元素，應用伺服器正好補足這些不足。

使用All-In-One的應用伺服器開發Web services好處在於應用伺服器的供應商已經幫我們處理了很多整合與最佳化的部分。開發人員不需要再花時間去處理這些問題。大部分的應用程式伺服器都包括建立應用程式所需之開發工具，並可直接編譯、部署、展示，同時還可搭配一些流程管理軟體。這些整合的產品套件可以節省很多的開發時間，並消除程式開發的複雜性，縮短程式開發週期並降低成本。

目前幾家主要的供應商中，IBM、Sun、HP銷售策略是利用整合的開發套件，帶動其硬體的銷售，其模式類似於傳統垂直整合的銷售模式。BEA及Microsoft則以銷售應用伺服器軟體解決方案為主，其目標不在於銷售硬體，因此選擇上較為彈性。BEA的Weblogic可以在不同的系統環境上執行，相同的Microsoft Windows 2003 Server內建的應用伺服器，則可以在所有Intel-based的Server上執行，其硬體則來自於Compaq、Dell、HP及其他硬體廠商。這兩家都不以硬體收入作為其獲利方式。不同的是BEA則另外以提供開發部署的專業服務，以獲取利潤。在這一方面，Microsoft雖然有數千個專業的服務人員，但主要在處理一些進階的技術部份，對一般企業的開發則由全球數十萬通過認證的技術人員及合作夥伴提供服務，Microsoft的策略是將這一部分的利潤分享給合作夥伴，這是各家在市場上策略的不同。

根據CIO雜誌所作的市場調查顯示，選擇微軟.NET平台作為Web services的開發平台的佔46.5%，選擇IBM Websphere佔19%，選擇Sun ONE的佔8.9%。(CIO Magazine Tech Poll Jan 2003)

(http://www.cio.com/info/releases/020303_techpoll.pdf)

以下兩張圖則是Gatner公司對目前各家廠商在Web services市場上的影響力所作的評估，特別要注意得是，從2001年到2002年市場上已經作了很大的改變，然而就實作能力而言還是以Microsoft、IBM與BEA為主流。

結論

雖然前面不斷的展現Web services的威力以及為企業所帶來的競爭優勢，然而最後還是要說，Web services並不是萬靈丹。企業必須先經過審慎的規劃、評估，再依據自己的需求，決定Web services的導入時機，同時在規劃Web services架構的時候，除注意商業規則與企業需求以外，還必須注意程式開發的環境、商業流程以及流程管理；再來則是資訊表示的方式與系統整合，如此才能設計出符合企業需求且具彈性的應用程式系統架構。在選擇開發方式則建議選擇一套為Web services所設計的應用伺服器平台，以降低開發成本與風險，至於平台，由於Web services是一套標準的規範，因此平台的獨特性並不是那麼重要，最重要的是所能提供的實作能力與相關資源、服務等，這也是我選擇.NET平台作為主要研究對象的原因。

 

後記：

要完成這一篇文章實在不容易，早在去年六月份即已擬好大綱，卻一直苦無時間撰寫，而資訊技術的更新，一日數變，因此在撰寫過程中，整體架構也稍微作了一些調整，雖然已盡力做好文章的構思，但還是有許多個人的疏漏與偏見，還請賜教。 (cpli@i-Freelancer.net)