【文章內(nèi)容簡介】 rvice的 WSDL文檔， 具體含義分析如下： definitions 該元素用來定義 WSDL文檔的名稱，引入需要的XML命名空間 70 ?types元素規(guī)定了與消息相關的數(shù)據(jù)類型的定義 71 ? message message(消息 )元素定義了傳遞的消息的數(shù)據(jù)結構 ? portType portType(端口類型 )元素是抽象操作和抽象消息的組合 message name=getWeatherRequest part element=tns:WeatherRequest name=parameters / /message message name=getWeatherResponse part element=tns:WeatherResponse name=parameters / /message portType name=Weather operation name=getWeather input message=tns:getWeatherRequest / output message=tns:getWeatherResponse / /operation /portType 72 ?binding binding(綁定 )元素用來具體化 portType元素，其中定義了 portType元素中的操作和消息的格式與協(xié)議等 73 ?service service(服務 )元素指定了 Web Service的位臵。一個service元素可以包含多個 port(端口 )元素，端口的集合構成了 service。 service元素如下： 74 WSDL綁定 ? WSDL 綁定可為 web service 定義消息格式和協(xié)議細節(jié)。 ? WSDL規(guī)范中定義了 3種綁定擴展： ?SOAP綁定 ?HTTP GET POST綁定 ?MIME綁定 其中 SOAP綁定是最常用的一種方式 。 75 SOAP綁定 綁定名，命名空間不重復 指出綁定是針對 SOAP協(xié)議格式的 指出操作是面向 RPC（ 消息包含參數(shù)和返回值）的還是面向文檔的（消息包含文檔） 使用的 SOAP 協(xié)議 指出綁定是針對 SOAP協(xié)議格式的 此 URI應當被直接用作 SOAPAction頭的值 給出輸入、輸出消息的編碼為 literal 76 UDDI ? UDDI是通過因特網(wǎng)描述服務、發(fā)現(xiàn)服務并且集成商業(yè)服務的一個獨立于平臺的框架。 ? UDDI代表著普遍化的描述、發(fā)現(xiàn)和集成。 ? UDDI是一個存儲 Web服務的目錄，使用WSDL描述 Web服務接口。 77 UDDI互聯(lián)網(wǎng)今后發(fā)展的初級階段 互聯(lián)網(wǎng) ? 一個以價值為導向的交互世界 未經(jīng)整合、 低價值的資源 78 服務集市 UDDI互聯(lián)網(wǎng)今后發(fā)展的初級階段 互聯(lián)網(wǎng) ? 一個以價值為導向的交互世界 經(jīng)過整合、 高價值的服務 79 服務集市 存在明顯 的差距 四種核心數(shù)據(jù)類型 ? businessEntity(描述發(fā)布服務組織的信息 ) ? businessService(描述服務的業(yè)務功能 ) ? binding Template(描述服務的技術細節(jié) ) ? tModel(其他各種屬性 ) 新的數(shù)據(jù)類型 () ? publisherAssertion – 描述所注冊的服務之間的關系 ? Subscription – 跟蹤一組實體的變更 80 UDDI 數(shù)據(jù)結構 BusinessEntity 企業(yè)碼 , 企業(yè)名 , 聯(lián)系方式 ,描述信息 , 分類 BusinessService 服務碼 , 企業(yè)碼 ,服務名 描述信息及分類 BindingTemplate 綁定碼 , 服務碼 , 描述信息 , 描述信息 , 接入點 tModel 模型名 , 描述信息 , 概述文檔 , 指向 WSDL文檔的指針 WSDL 文檔 外部 Web服務的接口 描述 81 UDDI如何工作 2)將服務的描述注冊到UDDI注冊中心 UDDI Business Registry 3) UDDI 注冊中心給每個實體指定一個在程序中唯一的標識符 4)電子交易場所和搜索引擎等客戶機與商業(yè)應用程序使用 UDDI 注冊中心來發(fā)現(xiàn)它們感興趣的服務 1)軟件公司、程序員等將tModel發(fā)布到UDDI注冊中心 5)企業(yè)調(diào)用這些服務,簡便地進行動態(tài)集成 82 注冊信息 企業(yè)與服務的注冊信息： 白頁：表示企業(yè)的基本信息，如企業(yè)的名稱、經(jīng)營范圍描述、聯(lián)系信息等。 黃頁：通過支持使用多種具有分類功能的分類法系統(tǒng)產(chǎn)生的類別劃分，使得使用者能夠在更大的范圍內(nèi)查找在注冊中心注冊的企業(yè)或者服務。 綠頁：與服務相關聯(lián)的綁定信息，并提供了指向這些服務所實現(xiàn)的技術規(guī)范的引用和指向基于文件的 URL的不同發(fā)型機制指針。 83 Web服務工作流程 84 WSBPEL ? WSBPEL(Web Services Business Process Execution Language)是一種基于 XML用來描述高層業(yè)務流程的編程語言，被描述的業(yè)務流程的每個單一步驟由 Web服務實現(xiàn)。 ? 原名是 BPEL4WS， 2023年由 IBM、 Microsoft、BEA合作開發(fā)。 2023改名為 WSBPEL。目前版本是 ? 本質(zhì)上是將一組 Web服務整合在一起以形成一個新的 Web服務的語言。 85 WSBPEL 基本結構 process //流程定義的根元素 partnerLinks //描述業(yè)務流程與伙伴的關系 partnerLink .......... /partnerLink /partnerLinks variables//通過變量表示合作伙伴間生成與傳遞的信息 ............ /variables sequence //一組順序執(zhí)行的活動 ............. /sequence /process 86 WSBPEL建模工具和引擎 ? Active Endpoints – ActiveBPEL engine – ActiveBPEL Designer ? Oracle BPEL Process Manager ? IBM WebSphere Business Integration Server Foundation ? BEA WebLogic Integration\AquaLogic ? Apache ODE開源 WSBPEL引擎 87 Apache ODE開源 WSBPEL引擎 ? Apache ODE是一個 WSBPEL兼容的 Web服務編配引擎，它可以使開發(fā)人員根據(jù)以 BPEL XML語法寫成的過程描述來編配 Web服務。 88 基于 Apache ODE的 Web服務組合 一、加法服務 (Add_Service) 輸入 double類變量 a、 b，輸出結果a+b； 二、減法服務 (Sub_Service) 輸入 double類變量 a、 b ，輸出結果 ab； 三、將這兩個服務組合為一個新服務 輸入 double類變量 a、 b和字符串變量 c，如果 c=add，輸出結果為 a+b； 如果 c=sub，輸出結果為 ab； 89 基于 Apache ODE的 Web服務組合 90 基于 Apache ODE的 Web服務組合 組合后的 Web服務運行結果： 91 概念和背景 面向服務的架構 SOA 語義互操作 服務案例 服務開發(fā)方法 云計算中的服務 高級專題 提 綱 92 開發(fā)案例 基于 IP地址的氣象查詢服務 ? 案例通過 BPEL組裝 IP2Location（根據(jù) IP地址查出所在地的城市名和國名）和GlobalWeather（根據(jù)城市名和國名給出天氣信息）兩個獨立的 Web服務，使得兩個服務能夠自動地串行調(diào)用，并將整合了的流程發(fā)布為 WeatherByIP服務。 93 業(yè)務用例 ① 客戶端向 WeatherByIP服務請求某一個 IP所在地的天氣信息 ② 當 WeatherByIP服務取得目標 IP后，將參數(shù)傳給IP2Location服務 ③ IP2Location服務根據(jù) IP地址查出所在地的城市名和國名，將此消息傳遞給 GlobalWeather服務 ④ GlobalWeather服務通過城市名和國家名查詢當?shù)氐奶鞖庑畔ⅲ⒎答佇畔骰?WeatherByIP服務 ⑤ WeatherByIP服務最終向用戶輸出目標 IP所在地的天氣情況。 94 Client WeatherByIP Service GlobalWeather Service IP2Location Service Targeted IP WeatherInfo LocationInfo Targeted IP WeatherInfo 訪問流程 （ 1） （ 2） （ 3） （ 4） （ 5） 95 96 IP2Location 接口類型 SOAP HttpGet HttpPost 97 IP2Location 輸入消息結構 輸入信息 98 IP2Location 輸出消息結構 可輸出信息 99 GlobalWeather 接口類型 100 GetWeather輸入消息結構 輸入信息 101 GetWeather輸出消息結構 輸出信息 102 WeatherByIP Service的 XML Schema ? 為了使整個流程的輸入格式與輸出消息格式保持一致，需在 XML Schema文檔中規(guī)定服務的輸入和輸出消息結構。主要來源自IP2Location Service的輸入消息格式和GlobalWeather Service的輸出消息格式。 103 XML Schema圖形化表示 104 WeatherByIP的服務描述 ? 接口類型和操作： ? 輸入消息結構： ? 輸出消息結構： 105 BPEL流程是業(yè)務流程的物理實現(xiàn)，通過服務間的消息傳遞，實現(xiàn)相互調(diào)用和流程組合 BPEL流程描述 106 BPEL 變量映射 ? 在 BPEL把消息從一個 service傳遞給另一個 service時，需要定義不同服務間的消息變量的映射關系 ? 消息傳遞通過 Assign活動來實現(xiàn)。 ? Assign1 – 從 WeatherByIP服務的輸入到 IP2Location服務的輸入 ? Assign2 – 從 IP2Location服務的輸出到 GlobalWeather服務的輸入 ? Assign3 – 從 GlobalWeather服務的輸出到 WeatherByIP的輸出 107 測試 輸入的 SOAP消息： 輸出的 SOAP消息： 108 概念和背景 面向服務的架構 SOA 語義互操作 服務案例 服務開發(fā)方法 云計算中的服務 高級專題 提 綱 109 ? 開發(fā)范式的變遷 – 結構化程序設計 – 面向?qū)ο蟮能浖_發(fā) – 基于組件的軟件開發(fā) – 面向服務的軟件開發(fā)（對象化 +開放式） ? 從單機系統(tǒng)、分布式系統(tǒng)、異構分布式系統(tǒng)，軟件的規(guī)模與復雜度逐漸提高，模塊耦合度逐步降低（ 對象化 +開放式 ）。 110 面向服務的軟件開發(fā)特點 ? 兩個視圖： – 服務提供者視圖：關心服務如何實現(xiàn)、封裝、發(fā)布、管理 – 服務消費者視圖：關心服務如何組合滿足業(yè)務需求 ? 面向重用的開發(fā) – Development for reuse – Reusebased Development ? 業(yè)務敏捷的開發(fā) – 快速構建 – 適應發(fā)展 111 Web 服務開發(fā)生命周期 ? IBM將服務的生命周期分為 建模、組裝、部署和管理 四個階段，而 SOA理念和最佳實踐貫穿每個階段。 ? 治理和過程為 SOA工程提供指導和監(jiān)管，支撐整個生命周期的各個階段。 112 建模 Model ? 建模階段主要是收集和分析業(yè)務需求，建立和優(yōu)化業(yè)務流程，并設計軟件服