為什麼需要Web服務?

來源:互聯網
上載者:User
web|web服務  
架構Web Service: 為什麼需要Web服務?  
  


   
內容:

面臨的挑戰
錯誤的解決方案: 複雜系統對接的解決方案
正確的解決方案: Web服務和商業Web
Web服務是未來?
什麼是Web服務?
參考資料
作者簡介


相關內容:





柴曉路 (fennivel@uddi-china.org)
Chief System Architect
2001年7月9日

本文是架構Web服務的系列文章的首篇,從Web服務的商業需求開始,來探討為什麼要使用Web服務。首先,作者分析了目前電子商務應用所面臨的挑戰: 務實和追求經濟利益是當今電子商務的需求。然而目前廣泛應用的電子商務應用的體系架構使得這一商業需求很難實現,複雜的應用串連和程式碼造成了應用的高維護代價和更新代價。而作為現有技術的革新(而不是革命)的Web服務卻正好能解決這一問題,成為目前應用環境中最為合理的解決方案。
Web服務似乎是一個嶄新的名詞,現在去瀏覽各大主流技術論壇,無一不在關注Web服務的發展。但是到底是麼是Web服務呢?很多技術人員初次接觸Web服務,會有一個錯覺,認為這是一個新的系統架構,新的編程環境。是的,Web服務是一個新的概念,但他的系統架構,他的實現技術卻是完完全全繼承已有技術的,絕對不會使現有的應用推倒重來,而是現有應用的面向Internet的一個延伸。

在本系列中,作者將從什麼是Web服務,為什麼需要Web服務開始,就Web服務的構建模式,結合一個執行個體,詳細闡述了Web服務的架構過程。

本文所引用的資源主要包括兩類,一類是Web服務的技術資源網站,包含了大量Web服務的技術資訊,另一類是Web服務“stack"系列技術規範,他們是一個整體的技術體系,包括UDDI、SOAP、WSDL、XML等。本文的最後給出了這些資源的連結,有興趣的讀者可以通過這些資源連結找到所需的內容。

面臨的挑戰

我們知道,過去十年的對IT產業/COM的"瘋狂投資"的時代已經過去了,那是一個實驗的年代。而現在,整個業界跨入了務實的階段,當今電子商務發展的重心已經完全從過去的.COM的模式轉向到傳統企業的電子商務化的進程中來。既然是企業的電子商務化,模式是否嶄新是次要的,而是否能為企業帶來經濟利益則是主要的。在規劃企業的電子商務應用的時候,企業管理員和系統架構師更多的關注該電子商務應用是否能為企業帶來直接的經濟收益、是否有利於削減掉某方面的開支成本、是否能夠最佳化資源使用,這些完完全全是由企業的商業利益驅動的,在這一輪的電子商務發展中,技術完全是為商務服務的,任何脫離商業需求的"新"技術則必然是毫無用武之地。

在IT投資銳減的日子裡,系統架構師們小心翼翼、廣泛考證,在對企業自身運作機制的務實的仔細調研中,總結出了一些(比較少量的,只有7種)當前最有價值進行實施的電子商務應用,它們是:

企業門戶(Portal):企業門戶與一般資訊門戶有本質的區別,企業門戶主要是為企業的重要客戶、夥伴和自身的員工服務的。它應當具有個人化(這裡的個人化並不僅僅是頁面),應當提供一系列的線上服務,使得客戶、夥伴和員工們得以使用企業門戶獲得必要的知識/資訊,得以通過企業門戶與公司專屬應用程式進行互動及交易處理。

網上連鎖商店(Storefront):為了拓展產品和服務的市場,拓廣銷售渠道以及增加銷售額,企業應當建立具有自身品牌識別的網上連鎖商店。這裡需要注意的是,所謂網上連鎖商店並不是說使用各種語言在各個國家分別建立網上商店,這隻是其中的一個形式,更多的方式應當是將企業的網上商店能夠加入到各種各樣的網上實體中,比如門戶網站、行業交易市場(e-Marketplace)、都市引擎等,使企業的銷售渠道遍布整個Web空間。

集團內連網(Intranet)與知識庫(Knowledge Base):集團的全球內連網能夠使企業的僱員可以在全球範圍內進行有效交流和協作,充分利用企業的全球資源,以提升整體的生產力。集團的知識庫能夠為員工的協作提供豐富有效工作中所需要的知識,以最大可能地提高員工的單位產出。

供應鏈(Supply Chain)管理:為提升企業的整體競爭力,企業往往需要保持並提升自身與其供應商的關係,採取流水線形式的採購方式並盡量減少運作成本,而要做到這一點,則必須要建立私人的交易通道和供應鏈關係的電子商務應用才能達到這一目標。

客戶服務(Customer Service):通過建立這樣的面向客戶的服務門戶或自助式銷售網站能夠實現跨區銷售,提升客戶的親近程度和滿意程度,並減少服務成本。

分銷(Distribution)管理:建立分銷管理應用能夠使企業迅速地拓展分銷渠道並挖掘新的市場機會。同時,企業還能裁減培訓成本、服務成本和產品分銷成本,並減少倉儲費用。

提供ASP(Application Service Provider)服務:通過在Web上部署ASP服務,企業能夠獲得新的額外的收入。而提供的ASP中的A(Application)應當是企業核心競爭力的數字化表現,一般情況下,其範圍可能就包含了前面提到的6種電子商務應用中的5種:企業門戶、網上連鎖商店、供應鏈管理、客戶服務以及分銷管理。

為了實施這些電子商務應用,不外乎幾種手段:由自己的IT部門具體計劃並實施,外包給軟體公司或方案提供者計劃並實施,當然解決方案或實施計劃中可能會包含平台軟體或專用軟體模組的採購。然而,無論自身的IT部門還是外包的方案提供者,其給出的實施計劃都是應用正式運營前的。一旦應用被部署之後,由於商務環境和商務需求的不斷改進和不斷變化,這些電子商務應用不可避免地需要被修訂、需要被更新,以符合新的電子商務流程。而到最後,企業的管理員甚至會想為企業的員工、客戶以及夥伴分別定製具體應用以獲得最大的商業利益並保持競爭力。

在這些應用程式更新的可能中,下面三個可能是最主要的也是最常發生的:

經常會增加新的電子商務應用,這常常會每幾個星期或每幾個月發生一次;
經常會對電子商務的流程變更,這常常每周或每幾天發生一次;
經常應使用者的需求而變更,這甚至每個小時都會發生,尤其是當需要為每個客戶、每個夥伴或每個企業員工都定製其首選的電子商務應用的時候。
毫無疑問,e化的企業必須直面這一問題的挑戰,經常的應用程式更新是當今電子商務應用部署所面臨的最大問題,如何提升企業的響應能力,削減響應開支,提升企業的競爭力,是所有的e化企業必須面對的問題。

錯誤的解決方案: 複雜系統對接的解決方案

為了達到這一保持企業核心競爭力的目的,大部分企業都在努力奮鬥著,毫無疑問他們在IT上投入了極多的資金和資源,那麼他們的選擇是否正確呢?在商務上,無疑是正確的,"沒有電子商務將等於無商可務",可是方法呢?他們採取了正確的方法了嗎?

讓我們首先來看一看目前大多數企業是如何操作的?

目前,在構建前面我提到的那些電子商務應用的時候,程式員們一般都是採用"獨立解決方案"來實施的。也就是說,對於每個應用,他們都是為每個需要的企業資源或外部資源編寫串連代碼,以使得應用得以運行。這些資源套件括:傳統系統(legacy systems)和資料庫、Web應用及Web資源,以及正在不斷湧現的Web服務。


程式員還需要編寫更多的代碼以使得大量的使用者能夠訪問每個應用,例如通過公司的Web網站,例如使用公司內部的傳統型應用程式等等。由於這些應用都是"辛苦"編程的產物,幾乎很難再定製。當需要融入新的電子商務流程,需要為額外的使用者群提供訪問介面,需要繼承不同的電子商務應用以為使用者提供更完整的增值服務,所有的這一切不得不從最初的系統設計開始做起。為什麼會這樣?因為所有的應用都是從一次性開發的角度實施的,應用的沒一個更改都需要由特定的程式員來完成。這樣,通過跨應用整合的方式實現電子商務應用的重用變得異常地困難。

由於每個應用都有其自己特有的基礎架構,這些應用在部署、更改和維護上的代價都異常高昂。企業不得不會每套應用配置特有的專業技術人員,並保持與不同技術供應商或解決方案供應商的密切聯絡。同時這些應用即不能被方便地繼承,也不能隨著企業商務的規模擴充而方便地實現應用的規模擴充。

我們很清楚地認識到,即使是只有一個電子商務應用,其建立、維護和定製的代價及複雜度就已經是如此驚人了。何況要涉及多個這樣的應用,其代價之高是可象而知的。

讓我們來考察當企業部署若干個這樣的電子商務應用的情形:

第一個應用,企業的為之付出的總的費用應該是該應用的開發和部署費用、以及運營時態的維護和更新費用。

第二個應用,應用的開發和部署費用是一樣的,但是企業需要為之花費額外的整合費用,同時由於整個公司專屬應用程式環境變得更加複雜,其運營時態的維護和更新費用可能呈指數形式增加。

同樣,當第三個、第四個應用被部署後,企業所支出的費用可能是高得驚人。

這樣的電子商務應用的實際運營狀況非但無法令企業商務規模迅速增長,甚至會造成相反的影響作用,因為此時,IT部門不得不僱傭更多的員工並花費更多的資金來管理這些複雜而紛亂的應用,並維護多種承載應用的基礎架構。

早先出現的電子商務技術,比如EDI、web EDI (也許是基於XML的)、內容伺服器、應用伺服器、EAI(Enterprise Application Integration),以及那些為建立企業門戶以及其他單個電子商務應用(上面提到的7種應用)而設計的獨立解決方案都無法解決這個問題。它們之所以無能為力,是因為它們不無例外地都是基於複雜應用串連的、不具備良好整合能力的應用開發模式,它們都是通過程式碼實現複雜應用串連以串連使用者、電子商務應用以及其他資訊系統的。這樣的實現方式即無法有效地解決經常發生的電子商務流程的更改而觸發的大額費用,也無法有效地解決各類使用者的定製需求。

正確的解決方案: Web服務和商業Web

在本節中,我將描述一個能解決以上所有問題的解決辦法。


  
電子商務需要擺脫獨立解決方案的實現模式,需要捨棄複雜系統串連的實現方法。一個有效電子商務應用絕對不應該是僅僅基於程式員以及那些複雜的代碼的。對於電子商務而言,傳統的由程式員主導的由裡向外的開發模式應當被由使用者主導的由外向裡的開發模式取代。冗長的串列的開發迴圈應當被即時的,快速的應用裝配所取代。同時這樣的應用應當天生就具備高可定製性。如果探究其商業本質,這是來自經過時間考驗的商業技術概念:"即時製造"以及"規模可伸縮"等概念,我們需要做的就是將傳統的商業概念延伸到電子商務中去。

看了上一段的描述,大家可能會認為這需要一個技術上的更本性變革,其實,不然。

基於XML技術的Web服務正是解決這一問題的最佳手段。Web服務的使用將改變目前的開發模式和應用部署的費用規模。各種Web服務分表實現了一定的電子商務功能,通過將各種電子商務的Web服務進行組合和整合以建立動態電子商務應用。Web服務能夠統一地封裝資訊、行為、資料表現以及商務流程,而無需考慮應用所在的環境是使用何種系統和裝置。

通過使用Web服務,企業能夠以前所不可能的方式通過抽象和混合將自身的電子商務組件化。當一個企業的核心競爭力被組件化之後,那麼這些核心競爭力就能夠很方便地在不同的企業之間共用,同時架構跨企業的電子商務應用,形成商務Web。

在商務Web中,將不需要為使用一個電子商務應用而購買這個電子商務應用所承載的應用軟體。Web服務是一種無需購買並部署的組件,這種組件是被一次部署到Internet中,然後到處可用的一種新型組件,所有應用只需要能夠連入Internet,就可以使用和整合Web服務。通過採用Web服務,開發的代價顯著降低了,程式員無需與多種平台進行互動,他只需要與一種組件進行互動,即Web服務,同時Web服務的調用介面完全採用標準的XML及相關技術,在代碼實現上代價也有顯著下降。通過採用Web服務,部署和整合的費用大大降低,流程的更改也無需更改大量代碼,甚至通過工具的支援,更本無需更改程式碼。同時隨著新的Web服務技術,如WSDL/UDDI/WSFL的大量使用,Web服務在運行時態進行動態裝配將成為現實,同時每個使用者甚至可以應使用者的需要而即時裝配。

Web服務是未來?

全球權威IT行業研究評論機構Gartner Group對未來5年的Web服務的發展狀況做了預測:

2001年,Web服務的架構開發工具將被各大開放商開發完畢。開發人員能夠購買到這些面向服務的開發工具。同時他們將會開始構建實際使用的Web服務。

2002年,商業Web服務將大量出現,大量的面向消費者的B2C Web服務將被使用。

2003年,UDDI註冊中心應Web服務的發展,變得越來也重要,其中的商業資料也越來越豐富。私人的UDDI註冊中心將被投入使用以支援內部的服務資訊的交換。而政府的Web服務(e-Government)應用也將會不斷出現。

2004年,各類企業將會普遍接受基於Web服務的商務應用模式,而服務集中的計算模式將會進入青年期。私人的UDDI註冊中心仍然在各類應用中處與優勢地位。新的收入模式和商業渠道將到處可見。40%的金融財務服務事務將使用Web服務模式。而35%的線上政府服務將以Web服務的形式提供。

2005年,公用的UDDI註冊中心作為公用商務資訊的交換器制而獲得大量的使用。動態服務同樣將大量投入使用。

同時我們看到各大技術供應商都按照Gartner Group的預測陸續地推出Web服務的構建工具:Microsoft的Visual Studio .NET,IBM的Web Service Toolkit,SUN的Sun ONE等等。基於Web Service的公用技術標準SOAP/WSDL/UDDI/WSFL或是已經成為事實行業標準,或是正在制訂的進程中,各大技術供應商和傳統商業企業都投入到了標準的制定和應用的架構中去。作為Web服務的體系架構的領導者IBM和Microsoft也開始在全球推廣Web服務技術。我們有理由相信Web服務將成為將來動態商務Web的主流技術。

什麼是Web服務?

我們已經從商業需求的角度和技術實現的可行性上討論了Web服務的可行性和必要性。由於大部分的讀者是技術人員,所以我相信大家對Web服務的各種實現技術會非常有興趣,對Web服務的架構過程也一定更有興趣,對如何在某個具體的Case中使用Web服務架構一定非常有興趣,我將在本文章系列的後續部分中逐一描述並提供答案。

參考資料

Web Service 技術/評論網站
WebServices.ORG, Web服務的綜合類技術網站。
IBM developerWorks/Web Service Zone, IBM的Web服務技術資源中心
MSDN Online Web Services Developer Resources, Microsoft的Web服務的開發人員資源網站
ITPapers/Web Service, ITPapers的Web服務評論文章
解決B2B電子商務應用互動和整合的InterOP Stack系列技術標準規範
UDDI執行白皮書, UDDI-China.org, UDDI.org
UDDI技術白皮書, UDDI-China.org, UDDI.org
UDDI程式員API規範, UDDI-China.org, UDDI.org
UDDI資料結構參考, UDDI-China.org, UDDI.org
Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000
SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000
作者簡介

柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統架構師、XML技術顧問。UDDI-China.org主要核心成員。2000年獲複旦大學電腦科學碩士學位,曾在國際電腦科學學術會議(ICSC)、亞太地區區XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、電腦科學期刊等各類國際、國內重要會議與期刊上發表論文多篇。專長於基於XML的系統整合和資料交換的技術研究,同時對資料庫、物件導向技術及CSCW等技術比較擅長。2001年加入UDDI Advisor Group,參與了UDDI Specification V2的開發。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。