面向服務的軟件工程 1104_第1頁
面向服務的軟件工程 1104_第2頁
面向服務的軟件工程 1104_第3頁
面向服務的軟件工程 1104_第4頁
面向服務的軟件工程 1104_第5頁
已閱讀5頁,還剩186頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

面向服務的軟件工程何揚帆2015-11-042概念和背景面向服務的架構SOA服務案例服務開發方法云計算語義Web服務高級專題提綱3什么是服務?Web服務的定義[W3C]:

Web服務(Webservice)應當是一個軟件系統,用以支持網絡間不同機器的互動操作。

Web服務是一個用URI(UniformResourceIdentifier)標識的軟件實體,其接口和綁定可以用XML協議定義、描述和發現。

Web服務通過Internet協議以基于XML消息,以松散耦合的方式與其它軟件實體或Web服務直接通訊。Web服務的興起Web服務作為一種新興起的技術,被稱為繼

PC

Internet

之后的第三次計算機革命Web服務

利用標準的

Internet

協議(如

HTTP,SMTP

等),解決了面向

Web

的分布式計算的通信問題,而傳統的分布式模型解決的是特定平臺下的通信問題。Web服務具有完全的平臺獨立性和語言獨立性,只要遵守

Web

Service

的接口即可進行服務的請求和調用。4Web服務的主要思想以后的應用將由一組在線服務組合而成。兩個相似的服務使用統一的標準和方法在網絡上發布,一個信息應用就可以按照代價或性能的標準,從這兩個相互競爭的候選服務中選擇一個服務來使用。服務允許在機器間復制,可以通過將特定的服務復制到本地存儲庫,從而提高位于特定的計算機(群)上的應用程序的性能.5Web服務的本質從表像上看,Web服務就是應用程序,它向外界暴露出一個能夠通過Web訪問方式進行調用的服務接口。從應用程序的角度上看,Web服務是一種新的Web應用程序,是自包含、自描述、模塊化的應用程序,可以通過互聯網特別是Web方式來描述、發布、查找和調用。6發展脈絡—前期互聯網一個以協議為主的交互世界

底層網絡協議和簡單的內容傳輸協議:“桶”到“桶”之間的交換,不觸及“桶”中的內容很少觸及7發展脈絡—當前互聯網一個以“文檔的對象化”形式主導的交互世界O-本體(論域中的標準化概念)Service(instance)-(對象)Serviceschema-知識模式(類)Controlled-vocabulary受控詞集(人或機器理解的含義)8發展脈絡—今后互聯網一個以價值為導向的交互世界9未經整合、低價值的資源經過整合、高價值的服務Web服務特征完好的封裝性。服務是一種部署在Web上的對象,自然具備對象的良好封裝性,對于使用者而言,能且僅能看到該對象提供的功能列表。松散耦合:當一個Web服務的實現發生變更的時候,調用者是不會感到這一點的,對于調用者來說,只要服務的調用接口不變,服務實現任何變更對他們來說都是透明的。使用標準協議規范:作為Web服務,其所有公共的協約完全需要使用開放的標準協議進行描述、傳輸和交換。這些標準協議具有完全免費的規范,以便由任意方進行實現。高度可集成能力:由于服務采取簡單的、易理解的標準協議作為組件接口描述規范和協同描述規范,完全屏蔽了不同軟件平臺的差異。10Web服務優勢高度的通用性和易用性:Web服務利用標準的Internet協議(如HTTP,SMTP等),解決了面向Web的分布式計算模式,提高了系統的開放性、通用性和可擴展性。完全的平臺、語言獨立性:Web服務進行了更高程度的抽象,只要遵守Web服務的接口即可進行服務的請求與調用。高度的集成性:Web服務實質就是通過服務的組合來完成業務邏輯的,因此,表現出了高度的組裝性和集成性.容易發布和部署:Web服務體系結構方案通過UDDI,WSDL,SOAP等技術協議,能夠很容易實現系統的部署.11Web服務架構棧12(1)(2)(3)(4)13提綱面向服務的架構SOASOA(Service-OrientedArchitecture)起源SOA不是一個新概念,通用對象代理架構CORBA和分布式組件對象模型DCOM被看成是SOA架構的前身。1996年,GartnerGroup提出了SOA“預言”(到2008年,超過60%的企業將使用SOA作為一個“指導原則”),因為當時的軟件發展水平和信息化程度還不足支撐此概念進入實質性的應用階段。SOA可以認為是面向對象分析與設計(OOAD)的合理發展;也是電子商務解決方案中,在體系結構、系統設計、實現與部署時所采用的組件化方法的合理發展。14SOA興起原因(計算部件的對象化趨勢)分布式系統的自然發展系統與運算環境的異質性操作環境的動態性交流設備細節的透明化面向過程需要多重服務15GartnerGroup關于SOA的最初概念客戶端/服務器的軟件設計方法,一項應用由軟件服務和軟件服務使用者組成。SOA與大多數通用的客戶端/服務器模型的不同之處,在于它強調軟件組件的松散耦合,并使用獨立的標準接口(對象化趨勢)16SOA的當前定義[W3C]SOA的定義:SOA是組件的集合,這些組件能被調用,并且接口的描述可以發布和發現。[維基百科]SOA的定義:SOA是構造分布式計算的應用程序的方法。它將應用程序功能作為服務發送給最終用戶或者其它服務。它采用開放標準、與軟件資源進行交互并采用標準的表示方式。17SOA的當前定義(續)當代SOA代表一個開放的、敏捷的、可擴展的、可聯邦的、可組合的架構,包含了自治的、高服務質量的、廠商多樣性的、可互操作的、可發現的和潛在可復用的服務,使用Web服務來實現。 ——ThomasErl 《SOA概念、技術與設計》18普遍接受的SOA架構19W3C發布的Web服務架構基本兩種基本角色(服務提供者和服務請求者)和一個可選的服務注冊中心.三種角色交互,涉及發布、發現、綁定操作.SOA架構中的角色服務提供者(serviceprovider):發布自己的服務,并且使用自身服務的請求進行響應.服務代理(servicebroker):可選.注冊與發布服務及其提供者,對其進行分類,并提供搜索服務.服務使用者(servicerequester):利用服務代理來查找所需服務,進而根據需求使用該服務.20SOA架構中的操作發布(publish):使服務提供者可以通過向服務代理注冊自己的功能及訪問接口.查找(find):服務使用者可以通過服務代理查找特定的服務.綁定(bind):使服務使用者能夠調用或激活服務.21SOA架構特點服務的封裝(encapsulation).將服務封裝成用于業務流程的可重用組件的應用程序函數.服務的互操作(interoperability).通過服務之間既定的通信協議進行互操作,SOA提供服務的互操作特性更利于其在多種場合被重用(“服務”(組織和交互方式)這種抽象協議).服務是位置透明的(locationtransparency).服務請求者不需要知道服務的具體位置及是哪一個服務響應了自己的請求.22SOA架構特點(續)服務的重用(reuse).一個服務是一個獨立的實體,與底層實現和用戶的需求完全無關,極大的方便了服務的重復使用,從而降低了開發成本.服務是自治(autonomous)的功能實體.服務是由組件組成的組合模塊,是自包含和模塊化的.服務之間的松散耦合(looselycoupled).服務請求者和服務提供者之間只有接口上的往來,至于服務內部如何更改,如何實現都與服務請求者無關23SOA與Web服務的聯系與區別SOA是一套面向服務架構的標準規范;Web服務是一套技術體系,可以用來建立應用解決方案,解決特定的消息通信和應用集成問題。SOA是一種軟件架構,不局限于某個技術的組合(例如Web服務)。SOA和Web服務是一對關聯技術。24傳統WebService互操作的核心技術WebService的核心技術主要包括SOAP、WSDL和UDDI。這三大部分代表了Webservice體系中的三個層次,分別是:傳輸層、描述層和發現層。25SOAP(簡單對象訪問協議)26SOAP是一種在分布式環境中進行信息轉換的輕量級協議。作為一種不依賴傳輸協議、用于在應用程序之間以對象的形式交換數據的表示層通信協議,SOAP是WebServices的核心。主要特征擴展性(Extensible)。SOAP定義了一個框架,允許例如安全、路由和可靠性等特性作為分層擴展添加進來互操作(Interoperable)。SOAP允許使用任何傳輸協議傳輸數據。獨立(Independent)于編程模型。SOAP采用XML文本格式,因此可以獨立于各種編程語言和平臺。SOAP信息交換模式SOAP消息交換模式(MEP)是指如何根據通信的需要將多條消息組合成一條整體的消息交換的抽象描述。四種模式:請求-響應消息交換模式

一個SOAP節點向另一個SOAP節點發送的包含SOAP信息的請求,另一個節點返回包含SOAP消息的響應27SOAP信息交換模式(續)單一響應消息交換模式

一個SOAP節點向另一個SOAP節點發送的請求不包含任何SOAP信息,而期望對方返回SOAP消息。SOAPWeb方法特性

請求-響應模式和單一響應模式可一起使用,SOAP節點間互相交流一些額外信息以表示Web方法的名字。SOAPAction特性

請求響應模式和單一響應模式可一起使用,SOAP節點間互相交流一些額外信息以表示其激活標志。28SOAP信息交換29ServiceBrokerServiceConsumerServiceProviderhttp

SOAPmessageWSDLdescribingserviceSOAPmessagehttpclientserviceregistryfindpublishDESCRIBEINVOKESOAPSenderSOAPReceiverSOAPSenderSOAPReceiverrequestresponseSOAP協議組成SOAP由4部分組成:SOAP信封(SOAPEnvelope)構造定義了一個整體的表示框架,可用于表示在消息中的是什么誰應當處理它是“可選的”還是“強制的”SOAP編碼規則(SOAPEncodingRules)定義了一套編碼機制用于表示應用程序交換的數據實例SOAPRPC表示(SOAPRPCPresentation)用于表示遠程過程調用和響應的約定SOAP綁定(SOAPBinding)底層傳輸協議,用以表示節點間交換的SOAP信封的約定。30SOAP信息格式31SOAPBodySOAPheaderSOAPenvelopeHeaderblockHeaderdataHeaderdataHeaderdataBodychildelementBodychildelement<env:Envelopexmlns:env="/2003/05/soap-envelope"><env:Header>

<n:alertcontrolxmlns:n="/alertcontrol">

<n:priority>1</n:priority>

<n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol>

</env:Header><env:Body>

<m:alertxmlns:m="/alert">

<m:msg>PickupMaryatschoolat2pm</m:msg>

</m:alert>

</env:Body></env:Envelope>

32SOAP編碼SOAP編碼:將數據的值編碼為XML格式對于應用中所定義的數據結構和值,SOAP可以將其轉換為由節點和帶有標簽的邊組成的圖,稱為數據模型,并進而通過SOAP編碼規則將SOAP數據模型轉換為XML格式。33SOAPRPCSOAP遠程過程調用信息描述了方法的請求或者方法的回復。SOAPXML文檔在服務器端轉換成方法調用,調用后的結果將編碼成為XML文檔返回給服務請求者。34SOAP請求35目標對象的URI方法的參數方法名SOAP響應36方法名目標對象的URI返回的結果SOAP協議綁定SOAP可在任何傳輸協議上使用,并提供了一種用于定義任意協議綁定的靈活框架。HTTP使用極為廣泛,也是SOAP協議綁定對象的首選。37HTTP請求與回應38POST

/Accounts/Henrik

HTTP/1.1

Content-Type:text/xml;charset="utf-8“

Content-Length:nnnn

SOAPAction:"/MyMessage"

<SOAP:Envelope...

HTTP請求HTTP回應HTTP/1.1200Ok

Content-Type:text/xml;charset="utf-8“

Content-Length:nnnn

<SOAP:Envelope...

HTTP請求方法HTTP協議版本HTTP請求資源資源的文本類型以及編碼格式、長度SOAPActionHTTP請求頭字段(指示SOAPHTTP請求的目的,它的值是一個標識該目的的URI)SOAP信息2XX狀態碼表示成功返回SOA架構

39WSDLWSDL(Webservicesdescriptionlanguage)是以XML格式來描述Web服務接口,指定Web服務的位置、操作方法等信息的描述語言。使用者使用WSDL就可以使用Web服務,而不必關心服務的實現細節。40WSDL構成元素WSDL文檔包含7個關鍵的構成元素:<definitions><types><message><operation><portType><binding><port><service><types>、<message>、<operation>和<portType>元素是抽象定義,與具體的WebService部署細節無關,可以被重用;而<binding>、<port>和<service>元素是WebService的具體描述,其中定義了WebService的技術細節41WSDL文檔結構示例代碼:WeatherWebService.wsdl是天氣預報WebService的WSDL文檔,具體含義分析如下:

<definitions>

該元素用來定義WSDL文檔的名稱,引入需要的XML命名空間42<definitionsname="Weather" xmlns="/wsdl/" xmlns:soap="/wsdl/soap/"

xmlns:tns="/Weather/" xmlns:xsd="/2001/XMLSchema"

targetNamespace="/Weather/"><types>元素規定了與消息相關的數據類型的定義

43<types><xsd:schematargetNamespace="/Weather/">

<xsd:elementname="WeatherRequest"><xsd:complexType><xsd:sequence><xsd:elementname="city"type="xsd:string"/><xsd:elementname="date"type="xsd:date"/></xsd:sequence></xsd:complexType></xsd:element><xsd:elementname="WeatherResponse"><xsd:complexType><xsd:sequence><xsd:elementname="temperature"type="xsd:int"/><xsd:elementname="humidity"type="xsd:int"/></xsd:sequence></xsd:complexType></xsd:element></xsd:schema></types><message>

<message>(消息)元素定義了傳遞的消息的數據結構<portType>

<portType>(端口類型)元素是抽象操作和抽象消息的組合44<messagename="getWeatherRequest"> <partelement="tns:WeatherRequest"name="parameters"/></message><messagename="getWeatherResponse"> <partelement="tns:WeatherResponse"name="parameters"/></message><portTypename="Weather"> <operationname="getWeather"> <inputmessage="tns:getWeatherRequest"/> <outputmessage="tns:getWeatherResponse"/> </operation></portType><binding>

<binding>(綁定)元素用來具體化<portType>元素,其中定義了<portType>元素中的操作和消息的格式與協議等45<bindingname="WeatherSOAP"type="tns:Weather"> <soap:bindingstyle="document" transport="/soap/http"/> <operationname="getWeather"> <soap:operation

soapAction="/Weather/getWeather"/> <input> <soap:bodyuse="literal"/> </input> <output> <soap:bodyuse="literal"/> </output> </operation></binding><service>

<service>(服務)元素指定了WebService的位置。一個<service>元素可以包含多個<port>(端口)元素,端口的集合構成了service。weather.wsdl中的<service>元素如下:46<servicename="Weather"> <portbinding="tns:WeatherSOAP"name="WeatherSOAP">

<soap:addresslocation="/"/> </port></service>WSDL綁定WSDL綁定可為webservice定義消息格式和協議細節。WSDL規范中定義了3種綁定擴展:SOAP綁定HTTPGETPOST綁定MIME綁定其中SOAP綁定是最常用的一種方式。47SOAP綁定48<binding

name="WeatherSOAP"

type="tns:Weather"> <soap:binding

style="document" transport="/soap/http"/> <operationname="getWeather"> <soap:operation soapAction="/Weather/getWeather"/> <input> <soap:bodyuse="literal"/> </input> <output> <soap:bodyuse="literal"/> </output> </operation></binding>綁定名,命名空間不重復指出綁定是針對SOAP協議格式的指出操作是面向RPC(消息包含參數和返回值)的還是面向文檔的(消息包含文檔)使用的SOAP協議指出綁定是針對SOAP協議格式的此URI應當被直接用作SOAPAction頭的值給出輸入、輸出消息的編碼為literalUDDIUDDI是通過因特網描述服務、發現服務并且集成商業服務的一個獨立于平臺的框架。UDDI代表著普遍化的描述、發現和集成。UDDI是一個存儲Web服務的目錄,使用WSDL描述Web服務接口。49四種核心數據類型businessEntity(描述發布服務組織的信息)businessService(描述服務的業務功能)bindingTemplate(描述服務的技術細節)tModel(其他各種屬性)新的數據類型(2.0/3.0)publisherAssertion–描述所注冊的服務之間的關系Subscription–跟蹤一組實體的變更50UDDI數據結構51BusinessEntity企業碼,企業名,聯系方式,描述信息,

分類BusinessService服務碼,企業碼,服務名描述信息及分類BindingTemplate綁定碼,服務碼,

描述信息,描述信息,接入點tModel模型名,描述信息,

概述文檔,

指向WSDL文檔的指針WSDL文檔外部Web服務的接口描述UDDI如何工作522)將服務的描述注冊到UDDI注冊中心UDDIBusinessRegistry3)

UDDI注冊中心給每個實體指定一個唯一的標識符4)電子交易場所和搜索引擎等客戶機與商業應用程序使用UDDI注冊中心來發現它們感興趣的服務1)軟件公司、程序員等將tModel發布到UDDI注冊中心5)企業調用這些服務,簡便地進行動態集成注冊信息53企業與服務的注冊信息:白頁:表示企業的基本信息,如企業的名稱、經營范圍描述、聯系信息等。黃頁:通過多種具有分類功能的分類法系統產生的類別劃分,使得使用者能夠在更大的范圍內查找在注冊中心注冊的企業或者服務。綠頁:與服務相關聯的綁定信息,并提供了指向這些服務所實現的技術規范的引用.Web服務工作流程54JAXR(JavaAPIforXMLRegistries)WS-BPEL55WS-BPEL(WebServicesBusinessProcessExecutionLanguage)是一種基于XML來描述高層業務流程的編程語言,被描述的業務流程的每個單一步驟由Web服務實現。原名是BPEL4WS,2002年由IBM、Microsoft、BEA合作開發。2007改名為WS-BPEL。目前版本是2.0本質上是將一組Web服務整合在一起以形成一個新的Web服務。WS-BPEL基本結構<process>//流程定義的根元素 <partnerLinks>//描述業務流程與伙伴的關系 <partnerLink> .......... </partnerLink> </partnerLinks>

<variables>//通過變量表示合作伙伴間生成與傳遞的信息 ............ </variables> <sequence> //一組順序執行的活動 ............. </sequence></process>56WS-BPEL建模工具和引擎ActiveEndpointsActiveBPELengineActiveBPELDesignerOracleBPELProcessManagerIBMWebSphereBusinessIntegrationServerFoundationBEAWebLogicIntegration\AquaLogicApacheODE開源WS-BPEL引擎57ApacheODE開源WS-BPEL引擎ApacheODE是一個WS-BPEL兼容的Web服務編配引擎,它可以使開發人員根據以BPELXML語法寫成的過程描述來編配Web服務。58基于ApacheODE的Web服務組合59一、加法服務(Add_Service)輸入double類變量a、b,輸出結果a+b;二、減法服務(Sub_Service)輸入double類變量a、b

,輸出結果a-b;三、將這兩個服務組合為一個新服務輸入double類變量a、b和字符串變量c,如果c=add,輸出結果為a+b;如果c=sub,輸出結果為a-b;基于ApacheODE的Web服務組合60基于ApacheODE的Web服務組合組合后的Web服務運行結果:6162提綱服務案例開發案例-基于IP地址的氣象查詢服務案例通過BPEL組裝IP2Location(根據IP地址查出所在地的城市名和國名)和GlobalWeather(根據城市名和國名給出天氣信息)兩個獨立的Web服務,使得兩個服務能夠自動地串行調用,并將整合了的流程發布為WeatherByIP服務。63業務用例客戶端向WeatherByIP服務請求某一個IP所在地的天氣信息當WeatherByIP服務取得目標IP后,將參數傳給IP2Location服務IP2Location服務根據IP地址查出所在地的城市名和國名,將此消息傳遞給GlobalWeather服務GlobalWeather服務通過城市名和國家名查詢當地的天氣信息,并將反饋信息傳回WeatherByIP服務WeatherByIP服務最終向用戶輸出目標IP所在地的天氣情況。64ClientWeatherByIPServiceGlobalWeatherServiceIP2LocationServiceTargetedIPWeatherInfoLocationInfoTargetedIPWeatherInfo訪問流程(1)(2)(3)(4)(5)65開發環境NetBeansIDE5.5withNetBeansEnterprisePack5.5SunjavaSystemApplicationServerPlatformEdition9Update1PartnerServicesIP2LocationService服務地址:http:///ip2locationwebservice.asmxWSDL地址:http:///ip2locationwebservice.asmx?wsdlGlobalWeatherService服務地址:/globalweather.asmxWSDL地址: http://www.webservicex.net/globalweather.asmx?wsdl66IP2Location接口類型67SOAPHttpGetHttpPostIP2Location輸入消息結構68輸入信息IP2Location輸出消息結構69可輸出信息GlobalWeather接口類型70GetWeather輸入消息結構71輸入信息GetWeather輸出消息結構72輸出信息WeatherByIPService的XMLSchema為了使整個流程的輸入格式與輸出消息格式保持一致,需在XMLSchema文檔中規定服務的輸入和輸出消息結構。主要來自IP2LocationService的輸入消息格式和GlobalWeatherService的輸出消息格式。73XMLSchema圖形化表示74WeatherByIP的服務描述接口類型和操作:輸入消息結構:75輸出消息結構:BPEL流程是業務流程的物理實現,通過服務間的消息傳遞,實現相互調用和流程組合BPEL流程描述76BPEL變量映射在BPEL把消息從一個service傳遞給另一個service時,需要定義不同服務間的消息變量的映射關系消息傳遞通過Assign活動來實現。Assign1從WeatherByIP服務的輸入到IP2Location服務的輸入Assign2從IP2Location服務的輸出到GlobalWeather服務的輸入Assign3從GlobalWeather服務的輸出到WeatherByIP的輸出77測試輸入的SOAP消息:輸出的SOAP消息:7879提綱服務開發方法開發范式的變遷結構化程序設計面向對象的軟件開發基于組件的軟件開發面向服務的軟件開發(對象化+開放式)從單機系統、分布式系統、異構分布式系統,軟件的規模與復雜度逐漸提高,模塊耦合度逐步降低(對象化+開放式)。80面向服務的軟件開發特點兩個視圖:服務提供者視圖:關心服務如何實現、封裝、發布、管理服務消費者視圖:關心服務如何組合滿足業務需求面向重用的開發DevelopmentforreuseReuse-basedDevelopment業務敏捷的開發快速構建適應發展81Web服務開發生命周期IBM將服務的生命周期分為建模、組裝、部署和管理四個階段,而SOA理念和最佳實踐貫穿每個階段。治理和最佳實踐為SOA工程提供指導和監管,支撐整個生命周期的各個階段。82建模Model建模階段主要是收集和分析業務需求,建立和優化業務流程,并設計軟件服務的流程。業務模型的建立是此階段的主要工作。83組裝Assemble在服務組合階段,主要是根據業務模型,利用已有的服務資源庫和業務解決方案,發現服務、創建服務和集成服務的過程。84部署Deploy在部署階段,主要是將服務以及集成的業務流程部署到運行環境中,通過控制中心配置和優化運行環境,使其能夠滿足業務所需的不同服務水平要求。85提供一定的靈活性,以支持服務和業務流程的動態更新以適應不斷變化的業務需求。管理Manage管理階段提供對底層服務資源的管理,并實時監測主要的性能指標以獲得預防、隔離、分析和修復問題的信息。86及時了解系統的狀態,并為業務建模和業務流程的持續改進提供重要的反饋信息。服務提供者的開發方法零起點方法。為新Web服務創建新的服務接口,服務接口和服務實現都歸服務提供者所有。自頂向下方法。開發一個與現有服務接口一致的新Web服務。這類服務接口通常是業界標準的一部分,可以被許多服務提供者實現。服務接口不能歸服務提供者所有。87服務提供者的開發方法(續)自底向上方法。用于為現有的應用程序創建新的服務接口。服務接口是從應用程序的應用程序編程接口(applicationprogramminginterface,API)派生出來的。中間相遇方法。當服務接口已經存在,并且用作Web服務的應用程序也已經存在時,將使用中間相遇這種Web服務開發方法。主要任務是將現有的應用程序接口映射到服務接口定義中定義的那些應用程序接口。88服務請求者的開發方法靜態綁定。靜態綁定是在構建時通過為服務請求者將使用的單個Web服務定位服務實現定義構建的。構建時動態綁定。當服務請求者想使用特定類型的Web服務,但在運行時之前實現是未知的,或者實現可以在運行時發生改變,這時將使用這類綁定。這類服務定義在服務接口定義中。運行時動態綁定。這類綁定的不同之處在于服務接口是在運行時被發現的。找到服務接口后,就生成、編譯,然后執行代理代碼。89服務設計方法中的原則服務的名稱要方便使用者服務的操作不能太多或者太少服務的操作應該是內聚的和完全的服務應該對實現的細節進行封裝服務應該適應多種調用模式服務的操作應該是無狀態的服務應該使用有狀態的事務進行建模服務的操作應該代表業務動作服務操作的參數應該是粗粒度的。9091提綱云計算云計算云計算(CloudComputing),是一種基于互聯網的計算方式,通過這種方式,共享的軟硬件資源和信息可以按需求提供給計算機和其他設備。云計算描述了一種基于互聯網的新的IT服務增加、使用和交付模式,通常涉及通過互聯網來提供動態擴展而且經常是虛擬化的資源。92云計算中的服務特征隨需自助服務。隨時隨地用任何網絡設備訪問。多人共享資源池。快速重新部署靈活度。可被監控與量測的服務。基于虛擬化技術快速部署資源或獲得服務。減少用戶終端的處理負擔。降低了用戶對于IT專業知識的依賴。93云計算服務的概觀94云計算服務模式軟件即服務(SaaS)平臺即服務(PaaS)基礎架構即服務(IaaS)95軟件即服務(SaaS)消費者使用應用程序,但并不掌控操作系統、硬件或運作的網絡基礎架構。是一種服務觀念的基礎,軟件服務供應商,以租賃的概念提供客戶服務,而非購買,比較常見的模式是提供一組帳號密碼。例如:MicrosoftCRM與S。96平臺即服務(PaaS)消費者使用主機操作應用程序。消費者掌控運作應用程序的環境(也擁有主機部分掌控權),但并不掌控操作系統、硬件或運作的網絡基礎架構。平臺通常是應用程序基礎架構。例如:GoogleAppEngine。97基礎架構即服務(IaaS)消費者使用“基礎計算資源”,如處理能力、存儲空間、網絡組件或中間件。消費者能掌控操作系統、存儲空間、已部署的應用程序及網絡組件(如防火墻、負載平衡器等),但并不掌控云基礎架構。例如:AmazonAWS、Rackspace。98云計算服務的部署模型公用云(PublicCloud) 簡而言之,公用云服務可通過網絡及第三方服務供應者,開放給客戶使用,“公用”一詞并不一定代表“免費”,但也可能代表免費或相當廉價,公用云并不表示用戶數據可供任何人查看,公用云供應者通常會對用戶實施使用訪問控制機制,公用云作為解決方案,既有彈性,又具備成本效益。私有云(PrivateCloud) 私有云具備許多公用云環境的優點,例如彈性、適合提供服務,兩者差別在于私有云服務中,數據與程序皆在組織內管理,且與公用云服務不同,不會受到網絡帶寬、安全疑慮、法規限制影響;此外,私有云服務讓供應者及用戶更能掌控云基礎架構、改善安全與彈性,因為用戶與網絡都受到特殊限制。99云計算服務的部署模型(續)社區云(CommunityCloud)社區云由眾多利益相仿的組織掌控及使用,例如特定安全要求、共同宗旨等。社區成員共同使用云數據及應用程序。混合云(HybridCloud) 混合云結合公用云及私有云,這個模式中,用戶通常將非企業關鍵信息外包,并在公用云上處理,但同時掌控企業關鍵服務及數據。100101提綱語義Web服務WWWURI,HTML,HTTPBringingthewebtoitsfullpotentialSemanticWebRDF,RDF(S),OWLDynamicWebServicesUDDI,WSDL,SOAPStaticSemanticWebServicesMotivationofSemanticWebService

SemanticWebTechnology+WebServiceTechnologySemanticWebServices=SemanticWebServices

allowmachinesupporteddatainterpretationontologiesasdatamodelautomateddiscovery,selection,composition,andweb-basedexecutionofservicesasintegratedsolutionforrealizingthevisionofthenextgenerationoftheWeb.SemanticWebServicesDefineexhaustivedescriptionframeworksfordescribingWebServicesandrelatedaspects(WebServiceDescriptionOntologies)Supportontologiesasunderlyingdatamodeltoallowmachinesupporteddatainterpretation(SemanticWebaspect)DefinesemanticallydriventechnologiesforautomationoftheWebServiceusageprocess(WebServiceaspect)

SemanticWebServicesUsageProcess:Publication:MaketheavailabledescriptionofthecapabilityofaserviceDiscovery:LocatedifferentservicessuitableforagiventaskSelection:ChoosethemostappropriateservicesamongtheavailableonesComposition:CombineservicestoachieveagoalMediation:Solvemismatches(data,protocol,process)amongthecombinedExecution:Invokeservicesfollowingprogrammaticconventions

SemanticWebServicesExecutionsupport:Monitoring:ControltheexecutionprocessCompensation:ProvidetransactionalsupportandundoormitigateunwantedeffectsReplacement:FacilitatethesubstitutionofservicesbyequivalentonesAuditing:VerifythatserviceexecutionoccurredintheexpectedwaySemanticWebServicesWithSemantic:Notonlyaninterfacedescription,butalsothecapabilityoftheservice.Logicreasoningenhancedservicediscoveryandcomposition.Canbedoneautomatically.OWL-S:OntologyWebLanguageforServicesWSMLWSDL-S…語義Web服務標記語言OntologyOWL-SisanOWLontologytodescribeWebservicesOWL-SleveragesonOWLtoSupportcapabilitybaseddiscoveryofWebservicesSupportautomaticcompositionofWebServicesSupportautomaticinvocationofWebservices"Completedonotcompete"OWL-SdoesnotaimtoreplacetheWebservicesstandards ratherOWL-SattemptstoprovideasemanticlayerOWL-SreliesonWSDLforWebserviceinvocation(seeGrounding)OWL-sExpandsUDDIforWebservicediscovery(OWL-S/UDDImapping)OWL-S概述OWL-S整體結構ResourceServiceService

ProfileService

ModelService

Groundingcommunicationprotocol(RPC,HTTP,…)portnumbermarshalling/serializationinputtypesoutputtypespreconditionseffectsprocessflowcompositionhierarchyprocessdefinitionsprovidespresents(whatitdoes)describedby

(howitworks)

supports

(howtoaccess)服務概要ResourceServiceService

ProfileService

ModelService

Groundingprovidespresents(whatitdoes)describedby

(howitworks)

supports

(howtoaccess)服務概要

ServiceProfilePresentedbyaservice.RepresentswhattheserviceprovidesTwomainuses:AdvertisementsofWebServicescapabilities(non-functionalproperties,QoS,Description,classification,etc.)RequestofWebserviceswithagivensetofcapabilitiesProfiledoesnotspecifyuse/invocation!NonFunctionalPropertiesFunctionalityDescription服務概要SummarizestheabstractcapabilityofaserviceFunctionalspecificationof

whattheserviceprovides

intermsofparameters,

subclassedas:preconditionsinputsoutputseffects服務概要—功能性描述PreconditionsSetofconditionsthatshouldholdpriortoserviceinvocationInputsSetofnecessaryinputsthattherequestershouldprovidetoinvoketheserviceOutputsResultsthattherequestershouldexpectafterinteractionwiththeserviceprovideriscompletedEffectsSetofstatementsthatshouldholdtrueiftheserviceisinvokedsuccessfullyOftenrefertoreal-worldeffectsPackagebeingdelivered,orCreditcardbeingdebited服務概要—功能性描述:參數ProvidessupportinginformationabouttheserviceTheseincludeserviceNametextDescriptionhas_processqualityRatingserviceParameterserviceCategorycontactInformation服務概要—非功能性描述Sub-classingtheProfilemodelfacilitatesthecreationandspecialisationofservicecategoriesEachsubclasscan:IntroducenewpropertiesPlacerestrictionsonexistingpropertiesSub-classingcanalsobeusedtospecialiserequestsforserviceAnexampleProfileHierarchyisprovided,butotherscouldjustaseasilybedefined服務概要層次服務概要層次:例子ResourceServiceService

ProfileService

ModelService

Groundingprovidespresents(whatitdoes)describedby

(howitworks)

supports

(howtoaccess)服務模型ServiceProcessDescribeshowaserviceworks:internalprocessesoftheserviceSpecifiesserviceinteractionprotocolSpecifiesabstractmessages:ontologicaltypeofinformationtransmittedFacilitates(automated)Webserviceinvocationcompositioninteroperationmonitoring服務模型:描述方法ThebasicclassoftheProcessOntologyistheProcess.Itssubclassesdescribeeachprocessby:anynumberof(possibly,conditional)inputs;anynumberof(possibly,conditional)outputs;anynumberofpreconditions,whichmustholdinorderfortheprocesstobeinvoked;anynumberof(possibly,conditional)sideeffects;anynumberofparticipants(subprocess)服務模型:過程本體Atomicprocesses:directlyinvokable(byanagent),havenosubprocesses,executedinasinglestepCompositeprocesses:consistofother(non-compositeorcomposite)processes

TheyhaveacomposedOfproperty,bywhichthecontrolstructureoftheprocessisindicated,usingaControlConstruct

subclasses(seetable…)Simpleprocesses:abstractconcepts,usedtoprovideaviewofsomeatomicprocess,orasimplifiedrepresentationofsomecompositeprocess(i.e.,the“blackbox”viewofacollapsedcompositeprocess)服務模型:OWL-S中的過程類型服務模型:總體結構ConstructDescriptionSequenceExecutealistofprocessesinasequentialorderConcurrentExecuteelementsofabagofprocessesconcurrentlySplitInvokeelementsofabagofprocessesSplit+JoinInvokeelementsofabagofprocessesandsynchronizeUnorderedExecuteallprocessesinabaginanyorderChoiceChoosebetweenalternativesandexecuteoneIf-then-elseIfspecifiedconditionhold,execute“Then”,elseexecute“Else”.Repeat-UntilIterateexecutionofabagofprocessesuntilaconditionholdsRepeat-WhileIterateexecutionofabagofprocesseswhileaconditionholds服務模型:過程中的控制結構<!–AtomicProcessDefinition-GetDesiredFlightDetails

--><rdfs:Classrdf:ID=“GetDesiredFlightDetails”> <rdfs:subClassOf

rdf:resource= “/Process#AtomicProcess”/></rdfs:Class>GetDesiredFlightDetailsAirportFlightDateAtomicProcessdepartureAirport_InoutboundDate_InAtomicProcessExample<!–(sample)Inputsusedbyatomicprocess

GetDesiredFlightDetails--><rdf:Propertyrdf:ID="departureAirport_In">

<rdfs:subPropertyOf

rdf:resource= "http:///Process#input"/> <rdfs:domain

rdf:resource="#GetDesiredFlightDetails"/> <rdfs:range

rdf:resource="/ont/ DAML-S/concepts.daml#Airport"/></rdf:Property><rdf:Propertyrdf:ID="outbounDate_In">

<rdfs:subPropertyOf

rdf:resource="http:///Process#input"/><rdfs:domain

rdf:resource="#GetDesiredFlightDetails"/>

<rdfs:range

rdf:resource="/ont/DAML-S/concepts.daml#FlightDate"/></rdf:Property>AtomicProcessExample<rdfs:Classrdf:ID="BookFlight"><rdfs:subClassOf

rdf:resource="#CompositeProcess"/><rdfs:subClassOf

rdf:resource="/Process#Sequence"/><daml:subClassOf><daml:Restriction><daml:onProperty

rdf:resource="/Process#components"/><daml:toClass><daml:subClassOf><daml:unionOfrdf:parseType="daml:collection"><rdfs:Class

rdfs:about="#GetFlightDetails"/><rdfs:Class

rdfs:about="#GetContactDetails"/><rdfs:Class

rdfs:about="#ReserveFlight"/><rdfs:Class

rdfs:about="#ConfirmReservation"/></daml:unionOf></daml:subClassOf></daml:toClass></daml:Restriction></daml:subClassOf></rdfs:Class>CompositeProcessConfirmReservationBookFlightGetContactDetailsSequenceGetFlightDetailsReserveFlightSequenceSequenceCompositeProcessExampleResourceServiceService

ProfileService

ModelService

Groundingprovidespresents(whatitdoes)describedby

(howitworks)

supports

(howtoaccess)服務基點ServiceGroundingProvidesaspecificationofserviceaccessinformationServiceModel+GroundinggiveeverythingneededforusingtheserviceBuildsuponWSDL

todefinemessagestructureandphysicalbindinglayerSpecifies:communicationprotocols,transportmechanisms,agentcommunicationlanguages,etc.服務基點Resources/ConceptsWSDLOWL-SProcessModelAtomicProcessOperationMessageInputs/OutputsBindingtoSOAP,HTTP,etc.OWL-S/WSDLBindingOWL-S/WSDLBinding132提綱高級專題高級專題(探索性的幾個議題)1331、服務推薦

2、服務組合

3、服務演化

4、服務統計服務推薦的背景134Web服務由于其良好的互操作性、平臺獨立性受到了學術及業界的青睞。面向服務的計算改變了傳統的軟件開發、交互、使用的方式,形成了軟件工程和分布式計算的新型范式。

同時也帶來了若干新的挑戰,例如:

大量服務涌現,面對多個功能相似的服務,用戶如何進行服務選擇?服務推薦技術特征的發展1351、基于QoS建模的服務推薦2、QoS動態性建模3、基于協同過濾的服務推薦4、基于情景感知QoS預測的個性化服務推薦基于QoS建模的服務推薦常見的(Qos)服務評價因子:執行代價、響應時間、可靠性、可用性、信譽度、吞吐率模型的局限性:

多數情況下的前提假設是:所有的QoS數據可以從服務提供者獲取并且數據是穩定的(不需要考慮動態性)。由于網絡開放性、動態性,Web服務的Qos信息是動態變化的(需要考慮動態性)136服務推薦技術特征的發展1、基于QoS建模的服務推薦2、QoS動態性建模3、基于協同過濾的服務推薦4、基于情景感知QoS預測的個性化服務推薦137QoS動態性建模的服務推薦QoS數據的收集與更新(非歷史和上下文的)

研究示范(1)ResearchontoolforservicequalitymeasurementofWebServices.主要工作:提出了一種基于APIHook收集QoS數據的方法(2)Random-QoS-AwareReliableWebServiceComposition.主要工作:將QoS的評價因子映射為一組隨機變量,用數學期望、方差來衡量評價因子的值,不僅僅計算歷史記錄值的平均值。(3)AnApproachforMeasuringQualityofWebServicesBasedontheSuperpositionofUncertainFactors.主要工作:基于非確定因素疊加的web服務評價方法。局限性:雖然反映了Web服務的動態特征,但沒考慮不同用戶之間使用經驗的不同(即用戶使用服務中關注的上下文)。138服務推薦技術特征的發展1、基于QoS建模的服務推薦2、QoS動態性建模3、基于協同過濾的服務推薦4、基于情景感知QoS預測的個性化服務推薦139基于協同過濾的服務推薦研究示范(非上下文的)(1)Reputation-basedrecommenderdiscoveryapproachforserviceselection.主要工作:將信任網絡劃分為若干個性化的信任網絡,通過信任度的迭代傳播,篩選出信任度高的推薦者。(2)WebserviceQoSpredictionapproach主要工作:通過用戶間Qos數據的使用經驗的相似性計算,篩選出歷史Qos數據與服務請求者歷史Qos數據最相近的用戶及其歷史Qos記錄。局限性:

考慮到了用戶的歷史使用經驗,但是沒有考慮用戶進行服務調用時的情景,例如操作系統、內存、CPU、網絡的帶寬、安全性等情況。140服務推薦技術特征的發展1、基于QoS建模的服務推薦2、QoS動態性建模3、基于協同過濾的服務推薦4、基于情景感知QoS預測的個性化服務推薦141基于情景感知QoS預測的個性化服務推薦142創新之處

在進行Web服務推薦時,考慮到用戶調用服務時的情景,如操作系統、內存、CPU、網絡的帶寬、安全性等等。技術路線

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論