技術(shù)刨析：傳統(tǒng)應(yīng)用與Web服務(wù)的接口

申請免費試用、咨詢電話：400-8352-114

技術(shù)刨析：傳統(tǒng)應(yīng)用與Web服務(wù)的接口

Web應(yīng)用的不斷發(fā)展，使人們發(fā)現(xiàn)在Web應(yīng)用和傳統(tǒng)桌面應(yīng)用(比如企業(yè)內(nèi)部管理系統(tǒng)、辦公自動化系統(tǒng)等)之間存在著連接的鴻溝。他們不得不重復(fù)地將數(shù)據(jù)從Web應(yīng)用遷移到傳統(tǒng)桌面應(yīng)用，又從傳統(tǒng)桌面應(yīng)用將數(shù)據(jù)遷移到Web應(yīng)用。這成為阻礙Web應(yīng)用進入主流工作流的一個巨大障礙。

Internet的發(fā)展，以及基于Internet的B2B電子商務(wù)的不斷發(fā)展，為各種類型的商業(yè)實體提供了發(fā)現(xiàn)新客戶、供應(yīng)流、新服務(wù)的各種機會，體現(xiàn)了Internet巨大的價值。但是，在B2B的高速發(fā)展中，有一個主要的屏障阻礙了電子商務(wù)向開放的全球一體化的貿(mào)易模式發(fā)展。

目前，大多數(shù)電子商務(wù)的應(yīng)用與基于Web的商業(yè)服務(wù)在處理購買者、供應(yīng)商、交易市場和服務(wù)提供者的聯(lián)系方式上各不相同。如何將這些應(yīng)用方便、低代價地連接在一起，從而實現(xiàn)大范圍的、跨企業(yè)實體的商務(wù)應(yīng)用系統(tǒng)對接，這是擺在開發(fā)人員面前的一大問題。不同的應(yīng)用(尤其是不同企業(yè)的)使用的開發(fā)語言不同，部署的平臺不同，通訊協(xié)議和對外交換的數(shù)據(jù)格式也有差異。如何解決語言差異、平臺差異、協(xié)議差異和數(shù)據(jù)差異帶來的高代價系統(tǒng)集成是這個問題的關(guān)鍵。

從1998年開始發(fā)展的XML及其相關(guān)技術(shù)，被證明有可能解決以上這個問題。近期開始蓬勃發(fā)展的Web服務(wù)技術(shù)(Web Services Technology)正是基于XML技術(shù)、針對這一問題的最佳解決方案。XML Web服務(wù)是當(dāng)今IT業(yè)界關(guān)注的焦點。Web服務(wù)技術(shù)主要目標(biāo)就是在現(xiàn)有各種平臺基礎(chǔ)上構(gòu)筑一個通用的平臺無關(guān)、語言無關(guān)的技術(shù)層，各種不同平臺之上的應(yīng)用依靠這個技術(shù)層來實施彼此的連接和集成。如果需要用一句話來概括Web服務(wù)技術(shù)與傳統(tǒng)Web應(yīng)用技術(shù)的差異的話，就是傳統(tǒng)Web應(yīng)用技術(shù)解決的問題是如何讓人來使用Web應(yīng)用提供的服務(wù)，而Web服務(wù)技術(shù)則要解決如何讓計算機系統(tǒng)使用Web應(yīng)用所提供的服務(wù)。我們知道，在PC的軟件系統(tǒng)中除桌面應(yīng)用外，還有很多底層的Service(可以參照Windows NT/2000中的對應(yīng)概念)為應(yīng)用提供基礎(chǔ)服務(wù)。Web服務(wù)同樣也可以看成是為應(yīng)用提供基礎(chǔ)服務(wù)，不同點在于可以被自由地部署在Internet上，使用Web服務(wù)技術(shù)實施訪問。

構(gòu)筑Web服務(wù)的技術(shù)家族主要成員有XML Schema、SOAP、WSDL和UDDI，它們都是完全基于新一代Internet種子技術(shù)XML的。XML Schema為在不同系統(tǒng)(Web服務(wù))之間交換數(shù)據(jù)提供了一個核心的數(shù)據(jù)建模工具。SOAP為在不同系統(tǒng)之間實施平臺無關(guān)的交互定義了一套基本的元規(guī)則，WSDL則是描述Web服務(wù)界面的基本工具，依靠Web服務(wù)的交互界面就能被系統(tǒng)自動處理。UDDI是在動態(tài)服務(wù)集成解決方案中的首次嘗試。這組技術(shù)使得底層平臺對應(yīng)用交互是透明的，并且應(yīng)用的互操作能力得到了前所未有的提升。

Web服務(wù)技術(shù)帶動了現(xiàn)代計算機技術(shù)的革命。

商業(yè)需求驅(qū)動Web服務(wù)

現(xiàn)在，電子商務(wù)發(fā)展的重心已經(jīng)從過去的.COM的模式，轉(zhuǎn)到傳統(tǒng)企業(yè)電子商務(wù)化進程中來。既然是企業(yè)的電子商務(wù)化，模式是否嶄新是次要的，能否為企業(yè)帶來經(jīng)濟利益是主要的。在規(guī)劃企業(yè)電子商務(wù)應(yīng)用的時候，企業(yè)管理人員和系統(tǒng)架構(gòu)師更多關(guān)注的是該電子商務(wù)應(yīng)用是否能為企業(yè)帶來直接的經(jīng)濟收益、是否有利于削減某方面的開支、是否能夠優(yōu)化資源使用等，這些都是由企業(yè)的商業(yè)利益驅(qū)動的。在這一輪的電子商務(wù)發(fā)展中，技術(shù)完全是為商業(yè)服務(wù)的，任何脫離商業(yè)需求的“新”技術(shù)必然是毫無用武之地。

系統(tǒng)架構(gòu)師們廣泛考證，在對企業(yè)運作機制經(jīng)過務(wù)實的調(diào)研后，總結(jié)出了7種當(dāng)前最有價值進行實施的電子商務(wù)應(yīng)用，它們是：

1. 企業(yè)門戶(Portal)；

2. 網(wǎng)上連鎖商店(Storefront)；

3. 集團內(nèi)聯(lián)網(wǎng)(Intranet)與知識庫(Knowledge Base)；

4. 供應(yīng)鏈(Supply Chain)管理；

5. 客戶服務(wù)(Customer Service)；

6. 分銷(Distribution)管理；

7. 提供ASP(Application Service Provider)服務(wù)。

為了實施這些電子商務(wù)應(yīng)用，不外乎采用下面幾種手段：由自己的IT部門具體計劃并實施；外包給軟件公司或解決方案提供商計劃并實施，當(dāng)然解決方案或?qū)嵤┯媱澲锌赡軙脚_軟件或?qū)Ｓ密浖K的采購。然而，無論自身的IT部門還是外包的解決方案提供商，給出的實施計劃都應(yīng)該是正式運營前的。一旦應(yīng)用被部署后，由于商務(wù)環(huán)境和商務(wù)需求的改進和不斷變化，這些電子商務(wù)應(yīng)用不可避免地需要被修訂和更新，以符合新的電子商務(wù)流程。而到最后，企業(yè)的管理人員甚至?xí)霝槠髽I(yè)的員工、客戶及合作伙伴分別定制具體應(yīng)用，以獲得最大的商業(yè)利益，并保持競爭力。

在這些應(yīng)用更新中，下面三個可能是最主要的、也是最常發(fā)生的：

1. 增加新的電子商務(wù)應(yīng)用，這常常會每幾個星期或每幾個月發(fā)生一次；

2. 對電子商務(wù)的流程進行更改，這常常每周或每幾天發(fā)生一次；

3. 應(yīng)用戶的需求進行更改，甚至每個小時都會發(fā)生，尤其是當(dāng)需要為每個客戶、每個合作伙伴或每個企業(yè)員工都定制首選的電子商務(wù)應(yīng)用的時候。

經(jīng)常的應(yīng)用更新是當(dāng)今電子商務(wù)應(yīng)用部署所面臨的最大問題。如何提升企業(yè)的響應(yīng)能力，削減響應(yīng)開支，提升企業(yè)的競爭力，是所有的信息化企業(yè)必須面對的問題。

復(fù)雜系統(tǒng)對接是不妥的解決方案

為了達到保持企業(yè)核心競爭力的目的，大部分企業(yè)在IT上投入了極多的資金和資源，那么他們的選擇是否正確呢？在商務(wù)上無疑是正確的。“沒有電子商務(wù)將等于無商可務(wù)”，可是他們采取的方法正確嗎？

首先讓我們來看一看目前大多數(shù)企業(yè)是如何操作的。

目前，在構(gòu)建電子商務(wù)應(yīng)用的時候，程序員們一般都是采用“獨立解決方案”來實施的。也就是說，對于每個應(yīng)用都是為需要的企業(yè)資源或外部資源編寫連接代碼，使應(yīng)用得以運行。這些資源包括：傳統(tǒng)系統(tǒng)(Legacy Systems)、數(shù)據(jù)庫、Web應(yīng)用及Web資源，以及正在不斷涌現(xiàn)的Web服務(wù)。

程序員還需要編寫更多的代碼，使大量的用戶能夠訪問每個應(yīng)用。例如通過公司的Web站點，使用公司內(nèi)部的桌面應(yīng)用程序等等。由于這些應(yīng)用都是“辛苦”編程的產(chǎn)物，幾乎很難再定制。當(dāng)需要融入新的電子商務(wù)流程時，需要為額外的用戶群提供訪問界面，需要繼承不同的電子商務(wù)應(yīng)用，為用戶提供更完整的增值服務(wù)。所有的這一切，都不得不從最初的系統(tǒng)設(shè)計開始做起。因為所有的應(yīng)用都是從一次性開發(fā)的角度實施的，應(yīng)用的每一個更改都需要由特定的程序員來完成。這樣，通過跨應(yīng)用集成的方式實現(xiàn)電子商務(wù)應(yīng)用的重用變得異常困難。

由于每個應(yīng)用都有其自己特有的基礎(chǔ)架構(gòu)，這些應(yīng)用在部署、更改和維護上的代價都異常高昂。企業(yè)不得不為每套應(yīng)用配置特有的專業(yè)技術(shù)人員，并保持與不同技術(shù)供應(yīng)商或解決方案供應(yīng)商的密切聯(lián)系。這些應(yīng)用既不能方便地繼承，也不能隨著企業(yè)商務(wù)的規(guī)模擴展而方便地實現(xiàn)應(yīng)用的規(guī)模擴展。

我們很清楚地認識到，即使只有一個電子商務(wù)應(yīng)用，創(chuàng)建、維護和定制的代價，以及復(fù)雜度就已經(jīng)是如此驚人了，何況要涉及多個這樣的應(yīng)用，其代價之高是可想而知的。

讓我們來考察當(dāng)企業(yè)部署若干個這樣的電子商務(wù)應(yīng)用的情形：

第一個應(yīng)用，企業(yè)的為之付出的總的費用應(yīng)該是該應(yīng)用開發(fā)和部署費用，以及運營時態(tài)的維護和更新費用。

第二個應(yīng)用，應(yīng)用的開發(fā)和部署費用是一樣的，但是企業(yè)需要為之花費額外的集成費用，同時由于整個企業(yè)應(yīng)用環(huán)境變得更加復(fù)雜，運營時態(tài)的維護和更新費用可能呈指數(shù)形式增加。

同樣，當(dāng)?shù)谌齻€、第四個應(yīng)用被部署后，企業(yè)所支出的費用可能是高得驚人。

這種電子商務(wù)應(yīng)用的實際運營狀況，非但無法令企業(yè)商務(wù)規(guī)模迅速增長，甚至?xí)斐上喾吹挠绊憽Ｒ驗榇藭r，IT部門不得不雇傭更多的員工和花費更多的資金來管理這些復(fù)雜而紛亂的應(yīng)用，并維護多種承載應(yīng)用的基礎(chǔ)架構(gòu)。

早先出現(xiàn)的電子商務(wù)技術(shù)，比如EDI、Web EDI (也許是基于XML的)、內(nèi)容服務(wù)器、應(yīng)用服務(wù)器、EAI(Enterprise Application Integration)，以及那些為創(chuàng)建企業(yè)門戶和其它單個電子商務(wù)應(yīng)用(上面提到的7種應(yīng)用)而設(shè)計的獨立解決方案，都無法解決這個問題。之所以無能為力，是因為它們都是基于復(fù)雜應(yīng)用連接的，不具備良好集成能力的應(yīng)用開發(fā)模式，它們都是通過程序代碼實現(xiàn)復(fù)雜應(yīng)用連接、電子商務(wù)應(yīng)用及其它信息系統(tǒng)的。這樣的實現(xiàn)方式既無法有效地解決經(jīng)常發(fā)生的因電子商務(wù)流程的更改而觸發(fā)的大額費用，也無法有效地解決各類用戶的定制需求。

Web服務(wù)和商業(yè)Web

電子商務(wù)需要擺脫獨立解決方案的實現(xiàn)模式，需要舍棄復(fù)雜系統(tǒng)連接的實現(xiàn)方法。一個有效的電子商務(wù)應(yīng)用不應(yīng)該是僅僅基于程序員和那些復(fù)雜的代碼的。對于電子商務(wù)而言，傳統(tǒng)的由程序員主導(dǎo)的、由里向外的開發(fā)模式，應(yīng)當(dāng)被由用戶主導(dǎo)的、由外向里的開發(fā)模式取代。冗長的、串行開發(fā)循環(huán)，應(yīng)當(dāng)被即時的、快速的應(yīng)用裝配所取代，并且這樣的應(yīng)用應(yīng)具備較高的可定制性。

基于XML技術(shù)的Web服務(wù)正是解決這一問題的最佳手段。Web服務(wù)的使用，將改變目前的開發(fā)模式和應(yīng)用部署的費用規(guī)模。各種Web服務(wù)分別實現(xiàn)了一定的電子商務(wù)功能，將各種電子商務(wù)的Web服務(wù)進行組合和集成，以創(chuàng)建動態(tài)電子商務(wù)應(yīng)用。Web服務(wù)能夠統(tǒng)一封裝信息、行為、數(shù)據(jù)表現(xiàn)，以及商務(wù)流程，而無需考慮應(yīng)用所在的環(huán)境使用何種系統(tǒng)和設(shè)備。

使用Web服務(wù)，企業(yè)能夠通過抽象和混合將自身的電子商務(wù)組件化。當(dāng)一個企業(yè)的核心競爭力被組件化之后，這些核心競爭力就能夠很方便地在不同的企業(yè)之間共享，同時架構(gòu)跨企業(yè)的電子商務(wù)應(yīng)用，形成商務(wù)Web。

在商務(wù)Web中，不需要因為使用電子商務(wù)應(yīng)用而購買所承載的應(yīng)用軟件。Web服務(wù)是一種無需購買并部署的組件，這種組件是被一次部署到Internet中，然后到處可用的一種新型組件，所有應(yīng)用只需要能夠連入Internet，就可以使用和集成Web服務(wù)。采用Web服務(wù)開發(fā)的代價顯著降低了，程序員無需與多種平臺進行交互，只需要與一種組件進行交互，即Web服務(wù)。Web服務(wù)的調(diào)用界面完全采用標(biāo)準(zhǔn)的XML及相關(guān)技術(shù)，代碼實現(xiàn)上的代價也顯著下降。采用Web服務(wù)部署和集成的費用大大降低，流程也無需更改大量代碼，甚至通過工具支持根本無需更改程序代碼。隨著新的Web服務(wù)技術(shù)，如WSDL/UDDI/WSFL的大量使用，Web服務(wù)在運行時態(tài)進行動態(tài)裝配將成為現(xiàn)實，甚至可以應(yīng)用戶的需要實時裝配。

Web服務(wù)技術(shù)

Web服務(wù)是一種部署在Web上的對象(Web Object)，因此具有對象技術(shù)承諾的所有優(yōu)點。Web服務(wù)的基石是以XML為主的開放Web服務(wù)技術(shù)，因此具有比任何現(xiàn)有的對象技術(shù)更好的開放性。

Web對象

從外部的使用者的角度而言，Web服務(wù)是一種部署在Web上的對象/組件，它具備以下特征：

1. 完好的封裝性。Web服務(wù)既然是一種部署在Web上的對象，自然具備對象的良好封裝性。對于使用者而言，它能且僅能看到該對象提供的功能列表。

2. 松散耦合。這一特征也是源于對象/組件技術(shù)，當(dāng)一個Web服務(wù)的實現(xiàn)發(fā)生變更的時候，調(diào)用者是不會感到這一點的。對于調(diào)用者來說，只要Web服務(wù)的調(diào)用界面不變，它的實現(xiàn)任何變更都是透明的，甚至當(dāng)Web服務(wù)的實現(xiàn)平臺從J2EE遷移到了.NET，或者是相反的遷移流程，用戶都可以對此一無所知。

從前，分布式的應(yīng)用程序邏輯需要使用分布式的對象模型，諸如：微軟的分布式組件對象模型(DCOM)、對象管理集團的公用對象請求代理程序體系結(jié)構(gòu)(CORBA)或Sun的遠程方法調(diào)用(RMI)。通過使用這種基本結(jié)構(gòu)，開發(fā)人員仍可擁有使用本地模型所提供的豐富資源和精確性，并可將服務(wù)置于遠程系統(tǒng)中。這些系統(tǒng)有一個共同的缺陷，就是它們無法擴展到互聯(lián)網(wǎng)上。它們要求服務(wù)客戶端與系統(tǒng)提供的服務(wù)之間必須緊密耦合，即要求一個同類基本結(jié)構(gòu)。這樣的系統(tǒng)往往十分脆弱，如果一端的執(zhí)行機制發(fā)生變化，那么另一端便會崩潰。例如，如果服務(wù)器應(yīng)用程序的接口發(fā)生更改，那么客戶端便會崩潰。

對于松散耦合而言，尤其是在Internet環(huán)境下的Web服務(wù)，需要有一種適合Internet環(huán)境的消息交換協(xié)議。XML/SOAP正是目前最為適合的消息交換協(xié)議。

3. 使用協(xié)約的規(guī)范性。這一特征從對象而來，但相比一般對象其界面規(guī)范更加規(guī)范化，也易于機器理解。首先，作為Web服務(wù)，對象界面所提供的功能應(yīng)當(dāng)使用標(biāo)準(zhǔn)的描述語言來描述(比如WSDL)。其次，由標(biāo)準(zhǔn)描述語言描述的服務(wù)界面應(yīng)當(dāng)是能夠被發(fā)現(xiàn)的，因此這一描述文檔需要被存儲在私有的或公共的注冊庫里面。同時，使用標(biāo)準(zhǔn)描述語言描述的使用協(xié)約不僅僅是服務(wù)界面，還被延伸到Web服務(wù)的聚合、跨Web服務(wù)的事務(wù)和工作流等。這些又都需要服務(wù)質(zhì)量(QoS)的保障。再次，我們知道安全機制對于松散耦合的對象環(huán)境的重要性，因此需要對諸如授權(quán)認證、數(shù)據(jù)完整性(比如簽名機制)、消息源認證及事務(wù)的不可否認性等，運用規(guī)范的方法來描述、傳輸和交換。最后，在所有層次的處理都應(yīng)當(dāng)是可管理的，因此需要對管理協(xié)約運用同樣的機制。

4. 使用標(biāo)準(zhǔn)協(xié)議規(guī)范。作為Web服務(wù)，其所有公共的協(xié)約完全需要使用開放的標(biāo)準(zhǔn)協(xié)議進行描述、傳輸和交換。這些標(biāo)準(zhǔn)協(xié)議具有完全免費的規(guī)范，以便由任意方進行實現(xiàn)。一般而言，絕大多數(shù)規(guī)范將W3C或OASIS作為最終版本的發(fā)布方和維護方。

5. 高度可集成能力。由于Web服務(wù)采取簡單的、易理解的標(biāo)準(zhǔn)Web協(xié)議作為組件界面描述和協(xié)同描述規(guī)范，完全屏蔽了不同軟件平臺的差異，因此無論是CORBA、DCOM，還是EJB都可以通過這一種標(biāo)準(zhǔn)的協(xié)議進行互操作，實現(xiàn)在當(dāng)前環(huán)境下最高的可集成性。

Web Services “Stack”

前面，我們已經(jīng)簡單地介紹了為了完成在松散耦合的環(huán)境下的對象訪問，以及在基本對象訪問之上的諸如事務(wù)、工作流、安全機制等。實現(xiàn)一個完整的Web服務(wù)體系需要有一系列的協(xié)議規(guī)范來支撐。

圖1展示了整個Web服務(wù)技術(shù)體系Web Services“Stack”。其中，底部兩層的是先前已經(jīng)定義好的并且廣泛使用的傳輸層和網(wǎng)絡(luò)層的標(biāo)準(zhǔn)IP、HTTP、SMTP等。中間部分是目前開發(fā)的Web服務(wù)的相關(guān)標(biāo)準(zhǔn)協(xié)議，包括服務(wù)調(diào)用協(xié)議SOAP、服務(wù)描述協(xié)議WSDL和服務(wù)發(fā)現(xiàn)協(xié)議UDDI、WS-Inspection，以及服務(wù)工作流描述語言WSFL、Web服務(wù)的安全協(xié)議和路由協(xié)議等。右邊部分是各個協(xié)議層的公用機制，這些機制一般由外部的正交機制來完成。

　　圖1 Web服務(wù)技術(shù)體系

從以上這個技術(shù)層次圖可以看到，Web服務(wù)追求的第一目標(biāo)是簡單性。

首先，這些協(xié)議本身都是簡單的，無論是HTTP、FTP等傳統(tǒng)的TCP/IP系統(tǒng)的網(wǎng)絡(luò)協(xié)議，還是SOAP、WSDL、UDDI、WSFL等基于XML的協(xié)議，設(shè)計原則中的一個重點就是力求簡單性。相信大家如果對XML、SOAP等有深入了解的話，一定會深深體會這一點。

其次，一個可以使用的Web服務(wù)應(yīng)當(dāng)按照需要選用若干層次的功能，無需所有的特性。比如在目前狀況下，一個簡單應(yīng)用可能只要使用WSDL/SOAP就可以架構(gòu)一個符合規(guī)范的Web服務(wù)了。

最后，所有的機制完全是基于現(xiàn)有的技術(shù)，并沒有創(chuàng)造一個完全的新體系。無論是HTTP、FTP等現(xiàn)有的網(wǎng)絡(luò)協(xié)議，還是SOAP、WSDL等基于XML而定義的協(xié)議都是遵循繼承原有的被廣泛接受的技術(shù)，這樣才能使得Web服務(wù)被廣泛接受。

Web服務(wù)體系架構(gòu)

Web服務(wù)技術(shù)是為在Internet環(huán)境下，松散耦合的Web服務(wù)之間互相調(diào)用、互相集成而設(shè)計的技術(shù)框架。以XML/SOAP/WSDL/UDDI為主干的Web服務(wù)技術(shù)，賦予了Web服務(wù)一個與傳統(tǒng)對象調(diào)用技術(shù)相似但又不太相同的體系架構(gòu)。

在討論體系架構(gòu)之前，我們先弄清楚兩個概念，即Web Services和Web Service。從英文字面上來看，兩個術(shù)語沒有什么差別，一個是復(fù)數(shù)，一個是單數(shù)。然而在Web服務(wù)的專業(yè)領(lǐng)域，Web Services是指整個架構(gòu)Web服務(wù)的技術(shù)框架，比如包括XML/SOAP/WSDL/UDDI等。而Web Service是指使用Web Services構(gòu)架出來的Web服務(wù)實例。本文中，Web Services對應(yīng)的中文名稱是Web服務(wù)技術(shù)，Web Service則翻譯為Web服務(wù)。

對于Web服務(wù)而言，其標(biāo)準(zhǔn)的、或者說是典型的體系架構(gòu)應(yīng)當(dāng)如圖2所示。

　　圖2 體系架構(gòu)

在Web服務(wù)的體系架構(gòu)里，有服務(wù)提供者、服務(wù)注冊中心和服務(wù)請求者三個角色。服務(wù)提供者是提供最終Web服務(wù)的供應(yīng)商，它實現(xiàn)了一個Web服務(wù)，并放置在在線服務(wù)器上，供別人使用。服務(wù)注冊中心是Web服務(wù)的注冊地，匯集了很多在線的Web服務(wù)。一般來說服務(wù)提供者將Web服務(wù)安置到在線服務(wù)器之后，會將Web服務(wù)發(fā)布到服務(wù)注冊中心中去，從而使得服務(wù)注冊中心中包含了越來越多的Web服務(wù)的技術(shù)信息。

對于想要使用Web服務(wù)的服務(wù)請求者來說，一般首先去查詢服務(wù)注冊中心，嘗試在服務(wù)注冊中心中尋找所需要的Web服務(wù)。當(dāng)發(fā)現(xiàn)了合適的Web服務(wù)之后，將從服務(wù)注冊中心獲取這些Web服務(wù)的技術(shù)信息引用，通過這些引用找到真正的Web服務(wù)及其相關(guān)的技術(shù)信息，從而完成服務(wù)請求者和服務(wù)提供者之間的技術(shù)綁定。

對于這三個角色之間任意兩者的交互，使用的都是Web服務(wù)的交互方式(服務(wù)注冊中心也是以Web服務(wù)的形式來運行的)。一般來說，可以使用SOAP。這些被調(diào)用的Web服務(wù)，其調(diào)用界面都是使用WSDL來描述的。

Web服務(wù)和EAI

問題再一次回到電子商務(wù)應(yīng)用的集成上。根本是企業(yè)內(nèi)部的EAI(Enterprise Application Integration)與企業(yè)之間的B2Bi(B2B Integration)，EAI是兩者中的基礎(chǔ)。

Web服務(wù)提供了一個分布式的計算技術(shù)，在Internet或者Intranet上通過使用標(biāo)準(zhǔn)的XML協(xié)議和信息格式來展現(xiàn)商業(yè)應(yīng)用服務(wù)。使用標(biāo)準(zhǔn)的XML協(xié)議，使得Web服務(wù)平臺、語言和發(fā)布者能夠互相獨立。這是EAI解決方案的一個理想的候選者。

通過開放的Internet標(biāo)準(zhǔn)，Web服務(wù)描述語言(WSDL，用于服務(wù)描述)統(tǒng)一描述、發(fā)現(xiàn)和集成規(guī)范(UDDI，用于服務(wù)的發(fā)布和集成)、簡單對象訪問協(xié)議(SOAP，用于服務(wù)調(diào)用)和Web服務(wù)流語言(WSFL，用來定義工作流，這尚不是一個W3C標(biāo)準(zhǔn))，Web服務(wù)消除了現(xiàn)存解決方案(如CORBA和DCOM)中的互用性問題。

Web服務(wù)不是EAI，或者只是EAI的一部分，它是另外一個技術(shù)。Web服務(wù)能夠使EAI成為真正可能的和便捷實施的、同時又引人注目的解決方案。Web服務(wù)能徹底地改變傳統(tǒng)的EAI中點對點的集成處理方式。

使用Web服務(wù)，通過松散的應(yīng)用集成，一個企業(yè)僅僅實現(xiàn)EAI的一個子集即能取得實效。與之相反，EAI實現(xiàn)一個全盤的方案，要緊密地集成和聯(lián)系支持公司業(yè)務(wù)的所有系統(tǒng)和應(yīng)用。在公司內(nèi)部不同的業(yè)務(wù)系統(tǒng)和技術(shù)單體中，可能需要花費數(shù)年的持續(xù)努力。

Web服務(wù)以一種松散的服務(wù)捆綁集合形式(也可以說是一個特別得解決方案)，快速、低代價地開發(fā)、發(fā)布、發(fā)現(xiàn)和動態(tài)綁定應(yīng)用。就當(dāng)代Web服務(wù)的技術(shù)發(fā)展水平來看，Web服務(wù)可以實現(xiàn)應(yīng)用程序之間的函數(shù)或方法級的集成。它們不是自然的基于事務(wù)的，僅提供了基本的“請求/響應(yīng)”功能。在下一代的Web服務(wù)中，在功能上和技術(shù)上都會更先進，將會提供用戶接口封裝和安全性，它們將能夠包裝一個應(yīng)用程序，并且把它嵌入到其它的應(yīng)用程序中去。

現(xiàn)有主要關(guān)注于應(yīng)用集成的EAI解決方案將不得不因此而改變。將來，包裝好的應(yīng)用程序?qū)⑹褂萌鏧ML、SOAP、WSDL和UDDI技術(shù)來把函數(shù)或方法作為Web服務(wù)的接口來顯示。因此，EAI解決方案將不得不提供一個對服務(wù)集成的廣泛支持，而不僅僅是應(yīng)用集成。

傳統(tǒng)EAI解決方案和Web服務(wù)之間的顯著的不同

下面是傳統(tǒng)的EAI解決方案和Web服務(wù)之間的一些基本不同點。

注意：有一些不同點所描述的Web服務(wù)可能并非是Web服務(wù)目前有的特性，而是考慮了Web服務(wù)被提議的未來的改進。

1. 簡單性，相比于典型的EAI解決方案(也許包括分布式技術(shù)如DCOM和CORBA)，Web服務(wù)更便于設(shè)計、開發(fā)、維護和使用。既然開發(fā)和使用Web服務(wù)的平臺框架已經(jīng)準(zhǔn)備好了，創(chuàng)建跨越多個應(yīng)用程序的商務(wù)流程處理將變得相對簡單。

2. 開放標(biāo)準(zhǔn)，不像有所有權(quán)的EAI解決方案，Web服務(wù)是基于開放標(biāo)準(zhǔn)諸如UDDI、SOAP、HTTP的。這個可能是導(dǎo)致Web服務(wù)被廣泛接受的最重要的因素。事實上，現(xiàn)存的開放標(biāo)準(zhǔn)消除了企業(yè)為了支持新出現(xiàn)的Web技術(shù)投資的需要。

3. 靈活性，既然EAI解決方案需要點對點集成，一端的改變必須告知另外一端，這自然使集成變得非常的生硬，同時也浪費開發(fā)人員的時間?；赪eb服務(wù)的集成是非常靈活的，因為它是建立在發(fā)布服務(wù)的應(yīng)用程序和使用服務(wù)的應(yīng)用程序之間的松散耦合。

4. 便宜，EAI解決方案，諸如消息中介實施是非常昂貴的。而Web服務(wù)的實施則便宜而快速。

5. 范圍，EAI解決方案諸如消息中介，把應(yīng)用程序作為一個單個的實體來集成。然而Web服務(wù)允許企業(yè)把大的應(yīng)用劃分為小的獨立邏輯實體，并且進行包裝。舉例來說，企業(yè)可以為一個ERP應(yīng)用的不同的商業(yè)組件進行包裝，如訂單管理、接受購買訂單、訂單情況、訂單確認、賬戶接受、賬戶支付等等。

6. 高效性，已在前面幾點提到的Web服務(wù)允許應(yīng)用程序劃分為一些小的邏輯組件。因為在小粒度基礎(chǔ)上集成應(yīng)用程序，集成將變得更容易。這也使Web服務(wù)的EAI解決方案比傳統(tǒng)的EAI解決方案更有效率。

7. 動態(tài)，Web服務(wù)通過提供動態(tài)的服務(wù)接口來實施一個動態(tài)的集成。在傳統(tǒng)的EAI解決方案里都是靜態(tài)處理的。

Web服務(wù)的EAI示例

圖3展示了在一個在企業(yè)內(nèi)使用Web服務(wù)的例子。在這個例子中，應(yīng)用服務(wù)器中運行的企業(yè)門戶從多個內(nèi)部應(yīng)用集成信息，并提供一個跨越這些應(yīng)用的業(yè)務(wù)處理的入口點。企業(yè)門戶應(yīng)用通過內(nèi)部應(yīng)用程序，使用私有UDDI注冊中心(Private UDDI Registry)來獲得可提供的Web服務(wù)的技術(shù)信息，并且在Intranet上調(diào)用這些服務(wù)。一些經(jīng)常被調(diào)用的Web服務(wù)的綁定信息將被企業(yè)門戶應(yīng)用緩存，這樣得以避免花費在動態(tài)綁定上的資源和時間。在這個例子里面，Web服務(wù)把企業(yè)門戶和CRM、ERP應(yīng)用程序松散地集成在一起。

　　圖3 企業(yè)應(yīng)用Web服務(wù)的流程圖

流程步驟如下：

1. 登錄企業(yè)門戶之后，用戶發(fā)出請求信息；

2. 支持企業(yè)門戶框架的應(yīng)用程序，通過瀏覽私有UDDI注冊中心獲得關(guān)于CRM和ERP應(yīng)用的Web服務(wù)的技術(shù)；

3. Web服務(wù)的位置和WSDL綁定信息被傳送給應(yīng)用服務(wù)器；

4. 應(yīng)用程序調(diào)用CRM應(yīng)用發(fā)布的Web服務(wù)得到個人的信息，如名字、身份證號碼、地址及用戶的Email，這個通訊過程是基于SOAP交互的；

5. 應(yīng)用程序調(diào)用ERP應(yīng)用發(fā)布的Web服務(wù)獲得銀行賬號信息，諸如銀行帳號號碼、結(jié)余和用戶交易歷史記錄，這個通訊過程也是基于SOAP交互的；

6. 信息被格式化后，發(fā)給起初的調(diào)用用戶。

從哪里開始

如果企業(yè)在內(nèi)部應(yīng)用程序中使用Web服務(wù)來實施應(yīng)用集成中的項目，應(yīng)當(dāng)從函數(shù)、應(yīng)用程序接口(API)，或者遠端過程調(diào)用(RPC)級別開始這一進程。這將使企業(yè)內(nèi)使用和實施Web服務(wù)的IT技術(shù)人員熟悉Web服務(wù)技術(shù)。當(dāng)企業(yè)將來使用Web服務(wù)進行外部集成(B2B集成)項目時，有助于項目的有效進行。在Intranet內(nèi)控制、管理、尋找、執(zhí)行和維護Web服務(wù)，相對來說比通過企業(yè)防火墻在Internet上使用Web服務(wù)更為容易。進一步來說，它將幫助企業(yè)進行比較和鑒別使用標(biāo)準(zhǔn)化和相對便宜的Web服務(wù)解決方案相對于昂貴的傳統(tǒng)的EAI解決方案哪個對提高企業(yè)的產(chǎn)出率更有幫助。

然而，要求企業(yè)拋棄現(xiàn)存的EAI底層架構(gòu)，并且盲目地轉(zhuǎn)向開發(fā)基于Web服務(wù)的解決方案來替代它是不太現(xiàn)實的。企業(yè)不會停止使用提供完整事務(wù)服務(wù)的EAI中間件框架。在使用Web服務(wù)的場所，不是替代(現(xiàn)在還不是)，而是應(yīng)該使用Web服務(wù)來支撐現(xiàn)存的下層結(jié)構(gòu)。

經(jīng)過一段時間，Web服務(wù)將逐漸的由一個EAI解決方案進化為一個B2BI(B2B Intergration)解決方案。