欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

基金項目：國家自然科學(xué)基金重點(diǎn)項目(60432010)

      開(kāi)放和融合是當前電信網(wǎng)發(fā)展的兩大特點(diǎn)。開(kāi)放指的是網(wǎng)絡(luò )與業(yè)務(wù)之間采用標準接口，從而實(shí)現業(yè)務(wù)開(kāi)發(fā)與網(wǎng)絡(luò )能力分離，為計算機界開(kāi)發(fā)人員進(jìn)行電信業(yè)務(wù)開(kāi)發(fā)提供了技術(shù)便利，有利于引入第三方開(kāi)發(fā)的業(yè)務(wù)，這是目前網(wǎng)絡(luò )開(kāi)放的一種重要思想和具體實(shí)施措施，Parlay接口正是這樣的網(wǎng)絡(luò )能力開(kāi)放接口的代表；融合指的是包括固定網(wǎng)、移動(dòng)網(wǎng)在內的電信網(wǎng)本身以及電信網(wǎng)與Internet融合。采用Internet領(lǐng)域興起的Web服務(wù)的Parlay接口技術(shù)體現了上述的開(kāi)放和融合，值得關(guān)注。

      另一方面Web服務(wù)作為一種新興的軟件技術(shù)，當前人們對其在認識上還存在一些誤區：或者把它看作一項簡(jiǎn)單的接口技術(shù)，或者把它看成和公共對象請求代理體系結構(CORBA)等面向對象系統等同的技術(shù)，而且由于Web服務(wù)與面向服務(wù)的體系結構(SOA)常常聯(lián)系在一起以至于混淆它們之間的關(guān)系。

1 Web服務(wù)
      萬(wàn)維網(wǎng)聯(lián)盟(W3C)對Web服務(wù)的定義[1]如下：Web服務(wù)是由通用資源標志符(URI)標識的軟件系統，其接口和綁定可以通過(guò)可擴展標記語(yǔ)言(XML)進(jìn)行定義、描述和發(fā)現，Web服務(wù)支持通過(guò)基于Internet的協(xié)議，使用基于XML的消息與Web服務(wù)或者其他軟件系統直接交互。

      從定義可以看出，Web服務(wù)有以下幾個(gè)顯著(zhù)的特點(diǎn)。

• 基于XML，包括其接口描述、外界交互數據格式等。
• 基于消息，而不是面向對象的方法調用。
• 采用URI標識，并且基于Internet協(xié)議，如超文本傳輸協(xié)議(HTTP)，是“Internet風(fēng)格”的技術(shù)。
• 與外界的交互需要與具體協(xié)議綁定，并且一般綁定的是Internet協(xié)議，是在Internet范圍內，所以與外界可以進(jìn)行“廣域”的交互。
• 作為一種軟件系統，內部實(shí)現平臺、編程語(yǔ)言等對外是不可見(jiàn)的，外界通過(guò)接口了解系統。
• 可以被外界發(fā)現。
  

      在Web定義中，除了XML、URI，Web服務(wù)并沒(méi)有特別指定采用什么技術(shù)實(shí)現其定義中聲明的功能，文獻[2]給出了Web服務(wù)的一個(gè)最小“核”：一個(gè)包含應用特定相關(guān)信息的XML文檔，一個(gè)可以發(fā)送或者接收和處理XML文檔的軟件程序，一個(gè)綁定的協(xié)議地址。原則上包括了以上的3個(gè)部分就可以構建一個(gè)Web服務(wù)，但是實(shí)際應用中，還需要很多額外的具體協(xié)議和技術(shù)。圖1給出了一個(gè)Web服務(wù)技術(shù)框架，可以說(shuō)用于建立一個(gè)完整和完善的系統，涉及到的協(xié)議和技術(shù)很多，但是Web服務(wù)最基本的技術(shù)包括以下3項：Web服務(wù)與外界交互的SOAP協(xié)議、Web服務(wù)描述語(yǔ)言(WSDL)、通用描述和發(fā)現集成(UDDI)規范。其中關(guān)于SOAP特別需要注意的是以下兩項：

• 遠程過(guò)程調用(RPC)和文檔風(fēng)格的SOAP消息綁定：SOAP交互本身是基于消息的，但是也包含了過(guò)程或者方法調用的支持。RPC風(fēng)格指出SOAP消息主體中包含了某個(gè)RPC調用或者響應的XML表示，而文檔風(fēng)格指出SOAP消息主體包含的只是一個(gè)XML文檔，發(fā)送方和接收方需要遵循該文檔的格式。
• 使用文字和使用編碼的SOAP消息綁定用法：消息綁定用法指的是用于確定數據序列映射到普通的XML格式的序列化機制。使用文字用法，將由XML模式定義(XSD)確定SOAP主體的XML格式，不具有二義性，而使用編碼用法，SOAP處理器必須在運行時(shí)遍歷各種SOAP編碼規則以確定SOAP主體正確的序列化，這將易于導致錯誤和互操作性方面的問(wèn)題。SOAP編碼的用法是XSD沒(méi)有完善之前提出的一種SOAP消息綁定用法，對它的支持已經(jīng)可選甚至被要求不再支持[3]。

1.1 Web服務(wù)與CORBA
      從前面Web服務(wù)的定義中我們可以看出Web服務(wù)也是一種分布式計算技術(shù)，Web服務(wù)與CORBA等分布式對象系統之間存在一些類(lèi)似之處，但是它們之間也存在一些重要的差異，正是這些差異使得Web服務(wù)能勝任一些CORBA等分布式對象系統難以完成的任務(wù)，成為一種新的備受關(guān)注的技術(shù)。表1給出了Web服務(wù)與CORBA的一些比較。Web服務(wù)與CORBA最重要的差別在于前者面向消息，后者面向對象，前者基于文本，后者基于二進(jìn)制，前者采用Internet協(xié)議，后者采用OMG組織的標準協(xié)議。所以這使得二者比較起來(lái)，前者是松耦合、后者是緊耦合；前者效率低、后者效率高；前者在Internet范圍內均有很好的互操作性，后者更適合在某個(gè)特定環(huán)境如Intranet范圍內的分布式處理。

      CORBA依賴(lài)于一個(gè)嚴格管理的環(huán)境，不同的CORBA系統可以互通，但是很多廠(chǎng)商均有自己對象請求代理(ORB)實(shí)現上的一些特定的優(yōu)化，而不同ORB互操作時(shí)就沒(méi)有了這種優(yōu)化。

      Web服務(wù)發(fā)展目的和方向并不是比CORBA更好的RPC系統，雖然它提供了對RPC的支持，Web服務(wù)本質(zhì)上是一個(gè)面向消息的系統，它與一般面向消息的分布式系統的區別在于它建立在XML、Internet標準協(xié)議之上，不是某個(gè)廠(chǎng)商的私有技術(shù)和產(chǎn)品，具有開(kāi)放性。Web服務(wù)的發(fā)展定位于構建Internet范圍內具有良好互操作性、擴展性、動(dòng)態(tài)性的服務(wù)系統。文獻[2,4-6]分析介紹了Web服務(wù)的技術(shù)特點(diǎn)及一些認識的誤區，分析了RPC系統與面向消息系統的差別、對象封裝成Web服務(wù)存在的問(wèn)題，并指出Web服務(wù)更適合位于比CORBA等面向對象系統更高抽象層次的集成和交互，可以作為“中間件的中間件”(例如實(shí)現CORBA與DCOM系統的互通)。文獻[7]將Web服務(wù)使用分為4種場(chǎng)景：簡(jiǎn)單的遠程服務(wù)通信、部分功能模塊外包、整體流程建模和執行、自動(dòng)組合和執行。

1.2 Web服務(wù)與SOA
      SOA是一種通過(guò)已發(fā)布的、可發(fā)現的接口向分布在網(wǎng)絡(luò )上的用戶(hù)應用或者其他軟件系統提供服務(wù)的軟件系統構建方法，SOA的核心和基本概念是服務(wù)，W3C對服務(wù)的定義如下：“服務(wù)是一種表示執行任務(wù)的能力的抽象資源，一個(gè)服務(wù)必須被具體的軟件實(shí)體實(shí)現才可以被使用”。服務(wù)作為SOA中的系統構建模塊，也可以看成一種特殊的構件。SOA的基本結構如圖2所示：包含3個(gè)角色(服務(wù)請求者、服務(wù)提供者、服務(wù)中介)、3個(gè)操作(服務(wù)發(fā)布、服務(wù)發(fā)現、服務(wù)綁定/交互)。服務(wù)中介一般包含了服務(wù)倉庫。SOA各個(gè)角色之間是松耦合，并且交互一般是通過(guò)一種廣泛接收的標準協(xié)議。

      SOA、服務(wù)與基于構件的軟件開(kāi)發(fā)(CBSD)和構件的核心差別在于以下兩點(diǎn)[8]：

      (1)SOA比CBSD更強調在運行時(shí)的發(fā)現、調用和集成，所以服務(wù)的描述比構件接口地位顯得更重要，服務(wù)外部視圖和內部實(shí)現的分離比構件更徹底。

      (2)服務(wù)和構件的動(dòng)態(tài)變化程度不同，對于前者，動(dòng)態(tài)變化是典型的場(chǎng)景，而對于構件，一般并不這么假定，雖然也可能有一定的動(dòng)態(tài)變化支持機制，所以支持動(dòng)態(tài)變化的機制在SOA和CBSD中的重要性也是不一樣的。

      綜上，SOA是一種非常適合應用于Internet環(huán)境下軟件系統的體系結構模型和系統構建方式，并且SOA沒(méi)有限定某種具體實(shí)現的技術(shù)。

      SOA和Web服務(wù)仍然是在發(fā)展中的技術(shù)，Web服務(wù)對SOA的支持也不夠完善，需要進(jìn)一步研究。

2 Web服務(wù)在Parlay接口中的應用介紹
      Parlay應用編程接口(API)是Parlay組織定義的一組開(kāi)放的、獨立于具體實(shí)現技術(shù)的、面向對象的網(wǎng)絡(luò )能力開(kāi)放接口，其定義是基于面向對象方法采用統一建模語(yǔ)言(UML)進(jìn)行描述的，獨立于具體中間件平臺，目前Parlay API的實(shí)現一般采用CORBA平臺，但是Parlay API同樣可以建立在Web服務(wù)之上，這種基于Web服務(wù)實(shí)現的Parlay API被稱(chēng)之為Parlay Web Services。除了Parlay API，Parlay組織還定義了Parlay X，一種基于Web服務(wù)的粗顆粒網(wǎng)絡(luò )能力開(kāi)放接口(Parlay API是一種細顆粒的網(wǎng)絡(luò )能力開(kāi)放接口)，Parlay組織的網(wǎng)絡(luò )能力開(kāi)放接口體系如圖3所示。

      本文中的Parlay接口泛指Parlay組織定義的網(wǎng)絡(luò )能力開(kāi)放接口，包括細顆粒和粗顆粒兩種類(lèi)型。本文中基于Web服務(wù)的Parlay接口指的是Parlay Web Services、Parlay X以及它們的集成。

      需要注意的是Parlay X只包括向應用提供的網(wǎng)絡(luò )能力接口，并不提供認證、授權、計費(AAA)，業(yè)務(wù)等級協(xié)定(SLA)，網(wǎng)絡(luò )能力注冊等部署環(huán)境相關(guān)的接口。Parlay Web Services除了向應用提供的網(wǎng)絡(luò )能力接口，還包括框架等接口，相對Parlay X，更加全面。Parlay X相對Parlay Web Services更加高層，它將電信網(wǎng)絡(luò )能力粗顆粒地提供給應用。Parlay X一般和Parlay Web Services或者其他Parlay API實(shí)現集成在一起，單獨的Parlay X不構成一個(gè)完整的網(wǎng)絡(luò )能力開(kāi)放方案。當前Parlay X提供的能力包括呼叫控制、短消息處理、多媒體消息處理、終端定位、賬號管理等。

      Parlay接口采用Web服務(wù)技術(shù)，除了Parlay接口定義采用WSDL，各方的交互基于SOAP協(xié)議，Web服務(wù)的UDDI可以引入到Parlay接口的部署環(huán)境，為應用對網(wǎng)關(guān)的發(fā)現、各種網(wǎng)絡(luò )能力的發(fā)布等提供了新的方式。例如各種Parlay網(wǎng)關(guān)可以在UDDI注冊中心登記，應用通過(guò)UDDI查找發(fā)現Parlay網(wǎng)關(guān)，選擇合適的Parlay網(wǎng)關(guān)訪(fǎng)問(wèn)網(wǎng)絡(luò )。

      基于Web服務(wù)的Parlay接口對應用開(kāi)發(fā)的影響主要體現在：計算機軟件開(kāi)發(fā)人員相對更容易理解和使用基于Web服務(wù)的接口，特別是Parlay X這樣的抽象層次較高的網(wǎng)絡(luò )能力粗顆粒接口；Web服務(wù)的開(kāi)放性和標準性使得網(wǎng)絡(luò )可以有更廣泛的應用接入和使用；基于Parlay Web Services或者Parlay X開(kāi)發(fā)的業(yè)務(wù)更容易與其他系統例如企業(yè)應用系統集成，提升各自的價(jià)值。

3 基于Web服務(wù)的Parlay接口的技術(shù)分析
      下面從多個(gè)方面分析總結基于Web服務(wù)的Parlay接口(Parlay Web Services和Parlay X)的技術(shù)特點(diǎn)：

(1)WSDL綁定
      考慮到當前實(shí)現技術(shù)，Parlay Web Services和Parlay X目前規定采用SOAP/HTTP協(xié)議作為Parlay邏輯體系中框架、業(yè)務(wù)能力服務(wù)器和應用之間通信的綁定協(xié)議。

(2)WSDL消息綁定的風(fēng)格和用法
      前面已經(jīng)提到SOAP支持RPC和文檔兩種風(fēng)格的消息綁定，而SOAP消息綁定可以采用編碼的用法，也可以采用文字的用法，這樣基于SOAP的綁定一般可以提供4種風(fēng)格/用法模式：RPC/編碼、RPC/文字、文檔/編碼、文檔/文字，另外還存在一種文檔/文字包裝模式，其中文檔/編碼模式是沒(méi)有意義的[9]，由于Parlay API是方法調用形式，所以基于Parlay API UML規范的Parlay Web Services中的SOAP采用RPC風(fēng)格進(jìn)行消息綁定，規范中給出了RPC/編碼模式的WSDL定義。而Parlay X在1.0版本規范中只給出RPC/編碼模式的WSDL定義，在1.0.1版本規范中增加了RPC/文字模式以及文檔/文字模式的WSDL定義，在最新的2.0版本規范中又只給出了文檔/文字模式的WSDL定義，Parlay X  WSDL定義形式的變遷反映了Parlay X的定義風(fēng)格遵循Web服務(wù)面向消息的技術(shù)本質(zhì)特點(diǎn)。

(3)WSDL文檔分離
      Parlay X從1.0.1版本開(kāi)始在除采用編碼用法的其他模式中WSDL定義不再全是在一個(gè)文檔中，而是區分為服務(wù)抽象接口、服務(wù)具體綁定以及服務(wù)數據類(lèi)型3種類(lèi)型文檔，這種分離有利于重用。雖然目前Parlay Web Services規范并沒(méi)有對WSDL定義文檔實(shí)行分離，但是也可以采用這種定義方法。

(4)對象引用
      Parlay Web Services是一種采用Web服務(wù)技術(shù)實(shí)現基于面向對象原則制訂的Parlay API，對象引用是Parlay API中基本的概念。在分布式系統中，對象引用不同于關(guān)聯(lián)標識這樣的數值，它是一個(gè)數據結構，包含了可以定位遠程對象的必要信息。Parlay API使用了回調機制，需要有回調接口引用，是一種特殊的對象引用。但是面向消息的Web服務(wù)基本規范里面沒(méi)有對象引用的概念。解決這個(gè)問(wèn)題存在多種方法，其中有的僅僅限于在回調中使用，而有的對回調和對象引用都適用。Parlay API規范和Parlay Web Services白皮書(shū)給出了兩種處理方法：

• 基于SOAP的方法：定義了一種新的數據類(lèi)型ObjectRef表示對象引用，該數據類(lèi)型被定義為統一資源定位器(URL)后附字符串，其中字符串后綴標識了URL上下文環(huán)境下特定的遠程對象實(shí)例。每一個(gè)接口均有一個(gè)對應的引用類(lèi)型，接口引用類(lèi)型是受限的ObjectRef，當對象引用作為參數或者結構化類(lèi)型參數的屬性傳遞時(shí)，參數或者參數屬性的類(lèi)型被定義為接口引用類(lèi)型。當對象引用要被用于標識接收消息的處理對象時(shí)，在Parlay API對應WSDL的SOAP綁定中，每個(gè)方法的輸入消息均包含一個(gè)頭部單元，而對象引用作為消息ObjectRefHeader被包含在SOAP頭部單元，而SOAP消息HTTP綁定包含的SOAPAction字段標識了處理接收消息的接口類(lèi)型。這樣對SOAP頭部的處理就可以確定處理接收消息的對象。該方法依賴(lài)于SOAP的頭部擴展機制，適合對象引用和回調的處理。
  
• 基于Web服務(wù)實(shí)現機制的方法：在WSDL的類(lèi)型定義區內定義了一個(gè)引用單元，在消息定義區中當某個(gè)消息參數相當于對象引用時(shí)，那么將消息參數的類(lèi)型定義為這個(gè)引用單元。引用單元包括一個(gè)端點(diǎn)、一個(gè)端口以及一個(gè)數據元素ObjectData。端點(diǎn)是服務(wù)的地址，端口被用于標識需要用到的存根和用于在遠程系統組裝存根，ObjectData用于標識特定的對象。在使用回調接口引用或者其他對象引用時(shí)，存根將被組裝，負責基于SOAP或者其他綁定協(xié)議與端點(diǎn)所在的服務(wù)進(jìn)行通信，ObjectData作為參數通過(guò)存根傳遞，ObjectData可以是包含定位對象實(shí)例的ID，也可以是使對象可以重構的數據。該方法依賴(lài)于Web服務(wù)具體實(shí)現機制(例如：存根和骨架)來(lái)提供運行時(shí)必要的支持，不要求對SOAP等傳送層協(xié)議進(jìn)行修改，適合對象引用和回調的處理。JAX-RPC規范(2.0版本之后改名為JAX-WS)等技術(shù)支持這種方法的具體實(shí)施。
  

(5)異步交互
      Parlay API方法根據交互是否同步分為同步方法和異步方法。生成一個(gè)對象，檢索數據是否存在等均為同步交互，同步交互一般發(fā)生在不要求業(yè)務(wù)能力服務(wù)器(SCS)與網(wǎng)絡(luò )中其他節點(diǎn)通信時(shí)，而當需要不定時(shí)長(cháng)或者較長(cháng)時(shí)間處理的情況下采用異步交互，這樣可以防止交互發(fā)起方的阻塞和對交互響應方是否出錯的猜測。Parlay API主要采用了回調機制實(shí)現異步交互，包括下面兩種模式[10]：通知模式、請求-響應模式。WSDL本身支持單向、請求/響應、懇求/響應、通知這4種類(lèi)型的操作?；赪SDL的這4種類(lèi)型操作，有多種方式用于構建Web服務(wù)異步交互[11]，實(shí)現異步交互的關(guān)鍵在于兩點(diǎn)：一是提供請求和響應關(guān)聯(lián)的機制，二是響應的回復地址。對于Parlay Web Services來(lái)說(shuō)，其異步交互經(jīng)過(guò)分析可以總結為如圖4、圖5、圖6所示的3種情形。這3種情形的異步交互均是通過(guò)創(chuàng )建關(guān)聯(lián)標識實(shí)現請求和響應關(guān)聯(lián)，均是把回調接口引用作為響應的回復地址，并且均是基于WSDL的請求/響應操作。不同點(diǎn)在于請求者在請求時(shí)傳遞回調接口引用還是單獨的設置回調接口引用，是由請求者還是提供者負責關(guān)聯(lián)標識的創(chuàng )建。Parlay Web Services的異步交互需要支持對象引用和回調接口引用概念。

      對于Parlay X來(lái)說(shuō)，其交互是基于XML文檔的消息傳遞而不是模擬面向對象的方法調用，并且遵循接口盡量保持簡(jiǎn)單易用的原則。Parlay X應用與Parlay X SCS之間的消息交互一般遵循同步的請求/響應操作并且是應用觸發(fā)的，Parlay X Services對于應用來(lái)說(shuō)應該是無(wú)狀態(tài)的，應用的每次調用不存在關(guān)聯(lián)關(guān)系?？梢圆捎幂喸?xún)的機制避免進(jìn)行異步交互，但是有時(shí)異步交互也可以被定義，例如應用側實(shí)現一個(gè)接受Parlay X SCS通知的Web服務(wù)，Parlay X SCS異步通知應用，具體的每一次交互，均是同步的請求/響應類(lèi)型操作。

      從上面的分析總結中可以看出Parlay Web Services是讓W(xué)eb服務(wù)支持 “面向對象”的API定義，而Parlay X則除了接口本身較Parlay API簡(jiǎn)單易用和抽象層次更高，其定義也逐漸擺脫“面向對象”的痕跡，回歸“面向消息”的本質(zhì)，所以可以說(shuō)Parlay Web Services是一種“形似而神不似”的Web服務(wù)網(wǎng)絡(luò )能力開(kāi)放接口，而Parlay X是一種“純”的基于Web服務(wù)的網(wǎng)絡(luò )能力開(kāi)放接口，這種“純”不僅體現在一開(kāi)始接口就是直接采用WSDL定義，而且體現在其設計思想、具體定義風(fēng)格均是愈來(lái)愈符合上面提到的Web服務(wù)技術(shù)發(fā)展思路。

4 結束語(yǔ)
      Web服務(wù)是當前計算機界的熱門(mén)技術(shù)，而Parlay接口是電信界業(yè)務(wù)領(lǐng)域研究人員廣泛關(guān)注的技術(shù)，基于Web服務(wù)的Parlay接口技術(shù)體現了上述兩種技術(shù)的結合，為構建電信網(wǎng)和Internet融合環(huán)境下的統一業(yè)務(wù)體系提供了基礎。

5 參考文獻
[1] W3C Working Group. Web services glossary[EB/OL].[2004-02-11]. http://www.w3.org/tr/2004/note-ws-gloss-20040211.
[2] Vogels W. Web services are not distributed objects[J]. IEEE Internet Computing, 2003, 7(6):59-66.
[3] Ewald T. The argument against SOAP encoding[EB/OL]. [2005-06-07]. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsoap/html/argsoape.asp.
[4] Vinoski S. Where is middleware?[J]. IEEE Internet Computing, 2002, 6(2):83-85.
[5] Vinoski S. Web services interaction models—part 1: current practice[J]. IEEE Internet Computing, 2002, 6(3): 89-91.
[6] Vinoski S. Web services interaction models—part2: cutting the "Web" into web services[J]. IEEE Internet Computing, 2002, 6(4):90-92.
[7] Shaparau D. Approaches to web service composition[EB/OL]. [2005-06-25]. http://science.unitn.it/~tomasi/think/pdf/sdmi.pdf.
[8] Cervantes H, Richard S. Autonomous adaptation to dynamic availability using a service-oriented component model [C]// Proceedings of the International Conference on Software Engineering (ICSE 2004). May 23-28,2004, Edinburgh, UK. Piscataway, NJ,USA:IEEE, 2004:614-623.
[9] Russell B. Which style of WSDL should I use?[EB/OL]. [2005-03-25]. http://www-900.ibm.com/developerWorks/cn/webservices/ws-whichwsdl/index_eng.shtml.
[10] Annex A. Asynchronous patterns in the parlay API[S]// Parlay Group. Parlay UML to Java API Rulebook 1.1. 2003: 28-32.
[11] Adams H. Synchronous operations and Web services[EB/OL]. [2005-03-25]. http://www-106.ibm.com/developerworks/library/ws-asynch2/index.html.

收稿日期：2005-12-21