第一章Web地理信息效勞尹章才 網絡效勞是Web2.0的重要技術根底和實現方式，網格、云計算等都是基于網絡效勞的。其中，XML是網絡效勞的根底語言。1.1Web效勞本節來源于：Web效勞，維基百科，://1.1.1核心定義一、Web效勞Web效勞〔WebService〕是一種面向效勞的架構的技術，通過標準的Web協議提供效勞，目的是保證不同平臺的應用效勞可以互操作。根據W3C的定義，Web效勞應當是一個軟件系統，用以支持網絡間不同機器的互動操作。網絡效勞通常是許多應用程序接口〔API〕所組成的，它們通過網絡，例如國際互聯網〔Internet〕的遠程效勞器端，執行客戶所提交效勞的請求。盡管W3C的定義涵蓋諸多相異且無法介分的系統，不過通常我們指有關于主從式架構〔C/S〕之間根據SOAP協議進行傳遞XML格式消息〔圖〕。無論定義還是實現，Web效勞過程中會由效勞器提供一個機器可讀的描述〔通常基于WSDL〕以辨識效勞器所提供的Web效勞。另外，雖然WSDL不是SOAP效勞端點的必要條件，但目前基于Java的主流Web效勞開發框架往往需要WSDL實現客戶端的源代碼生成。一些工業標準化組織，比方WS-I，就在Web效勞定義中強制包含SOAP和WSDL。WebService體系結構基于效勞提供者、效勞注冊中心和效勞請求者之間的交互。效勞提供者在效勞注冊中心發布Web效勞描述語言WSDL；效勞請求者使用注冊中心的UDDI注冊效勞來搜索其所需Web效勞，并通過SOAP將該Web效勞和本部門的當前應用綁定，實現空間數據與操作的共享。二、關鍵技術Web效勞建立在XML、WSDL、SOAP和UDDI等協議和標準之上，具有完好的封裝性、松耦合、使用協約的標準性、使用標準協議標準、高度可集成能力等特點。其中〔維基百科，://〕，1〕SOAP簡單對象訪問協議〔SOAP，全寫為SimpleObjectAccessProtocol〕是一種標準化的通訊標準，主要用于Web效勞中。SOAP的出現是為了簡化網頁效勞器〔WebServer〕在從XML數據庫中提取數據時，無需花時間去格式化頁面，并能夠讓不同應用程序之間透過HTTP通訊協定，以XML格式互相交換彼此的數據，使其與編程語言、平臺和硬件無關。此標準由IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出，并得到IBM，蓮花〔Lotus〕，康柏〔Compaq〕等公司的支持，于2000年提交給萬維網聯盟〔WorldWideWebConsortium；W3C〕，目前SOAP1.1版是業界共同的標準，屬于第二代的XML協定〔第一代具主要代表性的技術為XML-RPC以及WDDX〕。用一個簡單的例子來說明SOAP使用過程，一個SOAP消息可以發送到一個具有WebService功能的Web站點。例如，一個含有房價信息的數據庫，消息的參數中標明這是一個查詢消息，此站點將返回一個XML格式的信息，其中包含了查詢結果〔價格，位置，特點，或者其他信息〕。由于數據是用一種標準化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。2〕WSDL一個XML格式文檔，用以描述效勞端口訪問方式和使用協議的細節。通常用來輔助生成效勞器和客戶端代碼及配置信息。WSDL〔Web效勞描述語言，WebServicesDescriptionLanguage〕是為描述Web效勞發布的XML格式。WSDL2.0版將被作為推薦標準〔recommendation〕〔一種官方標準〕，并將被W3C組織批準為正式標準。WSDL描述Web效勞的公共接口。這是一個基于XML的關于如何與Web效勞通訊和使用的效勞描述；也就是描述與目錄中列出的Web效勞進行交互時需要綁定的協議和信息格式。通常采用抽象語言描述該效勞支持的操作和信息，使用的時候再將實際的網絡協議和信息格式綁定給該效勞。3〕UDDI一個用來發布和搜索WEB效勞的協議，應用程序可借由此協議在設計或運行時找到目標WEB效勞。UDDI是統一描述、發現和集成〔UniversalDescription,Discovery,andIntegration〕的縮寫。它是一個基于XML的跨平臺的描述標準，可以使世界范圍內的企業在互聯網上發布自己所提供的效勞。UDDI是OASIS發起的一個開放工程，它使企業在互聯網上可以互相發現并且定義業務之間的交互。UDDI業務注冊包括三個元件：白頁：有關企業的根本信息，如地址、聯系方式以及的標識；黃頁：基于標準分類的目錄；綠頁：與效勞相關聯的綁定信息，及指向這些效勞所實現的技術標準的引用。這些標準由這些組織制訂：W3C負責XML、SOAP及WSDL；OASIS負責UDDI。三、根本特征〔龍岳紅2008〕就技術角度而言，Web效勞是對象/組件技術在Inetmet上的延伸，它具備以下特征：1〕完好的封裝性Web效勞具備良好的封裝性，對于效勞使用者而言，他能且僅能看到該Web效勞所提供的接口。2〕松散藕合當一個Web效勞的實現發生變更的時候，只要其調用界面不變，對效勞的調用者不會有任何影響。也就是說，只要Web效勞的調用接口不變，Web效勞的實現的任何變更對效勞調用者來說都是透明的，甚至是當Web效勞的實現平臺從J2EE遷移到了.NET或者是相反的遷移流程，效勞的用戶都可以對此一無所知。3〕使用標準協議標準Web效勞使用開放的標準協議進行描述、傳輸和交換。這些協議具有完全免費的標準，以便由任意方進行實現。4〕高度可集成能力Web效勞是可組合的，可以用簡單的效勞構建更復雜的效勞。由于Web效勞采取簡單的、易理解的標準協議作為效勞接口描述和協同描述標準，完全屏蔽了不同軟件平臺的差異，從而可以在不同平臺間進行互操作，實現了在當前環境下最高的可集成性。5〕Web效勞是比組件更高層的架構(抽象)Web效勞并不是面向對象方法和基于組件方法建立企業應用的替代品，而是一種比組件技術更高層的抽象。組件技術通常是多個組件一起共同提供企業所需的某項功能，而Web效勞通常針對企業范圍內一個處理流程提供整體的業務解決方案。Web效勞由組件構成，一個(或幾個)組件會暴露在效勞接口中。1.1.2使用方式一、遠程過程調用1概念遠程過程調用〔RemoteProcedureCall，RPC〕是一個計算機通信協議。該協議允許運行于一臺計算機的程序調用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。如果涉及的軟件采用面向對象編程，那么遠程過程調用亦可稱作遠程調用或遠程方法調用。2信息傳遞遠程過程調用是一個分布式計算的C/S的例子，它簡單而又廣受歡送。遠程過程調用總是由客戶端對效勞器發出一個執行假設干過程請求，并用客戶端提供的參數，執行結果將返回給客戶端。由于存在各式各樣的變體和細節差異，對應地派生了各式遠程過程調用協議，而且它們并不互相兼容。為了允許不同的客戶端均能訪問效勞器，許多標準化的RPC系統應運而生了，其中大局部采用接口描述語言〔InterfaceDescriptionLanguage，IDL〕，方便跨平臺的遠程過程調用。3在Web效勞中的應用Web效勞提供一個分布式函數或方法接口供用戶調用，這是一種比較傳統的方式。通常，在WSDL中對RPC接口進行定義〔類似于早期的XML-RPC〕。盡管最初的Web效勞廣泛采用RPC方式部署，但針對其過于緊密之耦合性的批評聲也隨之不斷。這是因為RPC式Web效勞實質上是利用一個簡單的映射，以把用戶請求直接轉化成為一個特定語言編寫的函數或方法。如今，多數效勞提供商認定此種方式在未來將難有作為，在他們的推動下，WS-I根本協議集〔WS-IBasicProfile，WS是WebService的簡稱〕已不再支持遠程過程調用。二、面向效勞架構1概念〔〕面向效勞的體系結構(Service-OrientedArchitec-ture，SOA)是一個組件模型，它將應用程序的不同功能單元(稱為效勞)通過定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現效勞的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的效勞可以以一種統一和通用的方式進行交互。這種具有中立的接口定義〔沒有強制綁定到特定的實現上〕的特征稱為效勞之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性；另一點是，當組成整個應用程序的每個效勞的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而與此相對，緊耦合意味著應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對局部或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。雖然面向效勞的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基于SOA的系統并不排除使用面向對象的設計來構建單個效勞，但是其整體設計卻是面向效勞的。由于它考慮到了系統內的對象，所以雖然SOA是基于對象的，但是作為一個整體，它卻不是面向對象的。不同之處在于接口本身。SOA系統原型的一個典型例子是通用對象請求代理體系結構(CommonObjectRequestBrokerArchitecture，CORBA)，它已經出現很長時間了，其定義的概念與SOA相似。然而，現在的SOA已經有所不同了，因為它依賴于一些更新的進展，這些進展是以XML為根底的。通過使用WSDL來描述接口，效勞已經轉到更動態且更靈活的接口系統中，非IDL可比了。總之，SOA是一種“如何將軟件組織在一起”的抽象概念，依賴于用XML和Web效勞實現并以軟件的形式存在的更加具體的觀念和技術。2特征〔〕1〕可重用，一個效勞創立后能用于多個應用和業務流程。2〕松耦合，效勞請求者到效勞提供者的綁定與效勞之間應該是松耦合的。因此，效勞請求者不需要知道效勞提供者實現的技術細節，例如程序語言、底層平臺等等。3〕明確定義的接口，效勞交互必須是明確定義的。效勞請求者不知道也不關心效勞究竟是由哪種程序設計語言編寫的。4〕無狀態的效勞設計，效勞不應該依賴于其他效勞的上下文和狀態。5〕基于開放標準，當前SOA的實現形式是Web效勞，基于的是公開的W3C及其他公認標準．采用第一代Web效勞定義的SOAP、WSDL和UDDI以及第二代Web效勞定義的WS-*來實現SOA。3在Web效勞中的應用現在，業界比較關注的是遵從SOA概念來構筑Web效勞。在SOA中，通訊由消息驅動，而不再是某個動作〔方法調用〕，這種Web效勞也被稱作面向消息的效勞。SOA式Web效勞得到了大局部主要軟件供給商以及業界專家的支持和肯定。作為與RPC方式的最大差異，SOA方式更加關注如何連接效勞而不是特定某個實現的細節。WSDL定義了聯絡效勞的必要內容。值得一提的是，SOA不是Web效勞。Web效勞是技術標準，而SOA是設計原那么。特別是Web效勞中的WSDL，是一個SOA配套的接口定義標準：這是Web效勞和SOA的根本聯系。從本質上來說，SOA是一種架構模式，而Web效勞是利用一組標準實現的效勞。Web效勞是實現SOA的方式之一。用Web效勞來實現SOA的好處是你可以實現一個中立平臺，來獲得效勞，而且隨著越來越多的軟件商支持越來越多的Web效勞標準，你會取得更好的通用性〔〕。三、表述性狀態轉移1REST設計概念和準那么〔〕：1〕網絡上的所有事物都被抽象為資源〔resource〕；2〕每個資源對應一個唯一的資源標識〔resourceidentifier〕；3〕通過通用的連接器接口〔genericconnectorinterface〕對資源進行操作；4〕對資源的各種操作不會改變資源標識；5〕所有的操作都是無狀態的〔stateless〕。2在Web效勞中的應用表述性狀態轉移式〔Representationalstatetransfer，REST〕Web效勞類似于HTTP或其他類似協議，它們把接口限定在一組廣為人知的標準動作中〔比方HTTP的GET、PUT、DELETE〕以供調用。此類Web效勞關注與那些穩定的資源的互動，而不是消息或動作。此種效勞可以通過WSDL來描述SOAP消息內容，通過HTTP限定動作接口；或者完全在SOAP中對動作進行抽象。1.2根底Web地理信息效勞開放地理信息系統協會(OpenGISConsortiumOGC)致力于為地理信息系統間的數據和效勞互操作提供統一，它是一個非盈利的志愿的國際標準化組織，引領著空間地理信息標準及效勞的開展。目前在空間數據互操作領域，基于CGI模式的互操作方法是一種根本的操作方法。通過國際標準化組織〔ISO/TC211〕或技術聯盟〔如OGC〕制定空間數據互操作的接口標準，GIS軟件商開發遵循這一接口標準的空間數據的讀寫函數，可以實現異構空間數據庫的互操作。目前，基于HTTP、XML的空間數據互操作主要涉及WebService的相關技術，是未來互操作的開展趨勢。OGC和ISO/TC211共同推出了基于Web效勞〔XML〕的空間數據互操作實現標準WMS，WFS，WCS〔OGC,://〕。以上三個標準既可以做為Web效勞的空間數據效勞標準，又可以做為空間數據的互操作實現接口。只要某一個GIS軟件支持這個接口，部署在本地效勞器上，其他GIS軟件就可以通過這個接口得到所需要的數據。從技術實現的角度，可以將Web效勞理解為一個應用程序〔可以用現有的各種編程語言實現〕，它向外界暴露出一個能通過Web進行調用的接口，允許被任何平臺、任何系統，用任何語言編寫的程序調用。這意味著，Web效勞可以實現跨平臺、跨語言、跨硬件的互操作。1.2.1網絡地圖效勞作為OGC基于Web地圖效勞的互操作標準，WMS憑借其簡單明了的請求方式和豐富的響應信息，為在互聯網上實現多源異構地理空間數據的集成、共享、互操作和應用提供了一條簡捷高效的途徑。WMS能動態整合與可視化在線的數據源，而不受格式、數據模型、坐標系以及軟件商家的限制(Marta2002)。WMS定義了用來在Internet上得到地圖圖像的效勞接口，其所生成的地圖是以諸如PNG、GIF、JPEG、SVG或WebCGM(WebComputerGraphicsMetafile)的格式存在，為不同來源地理信息的融合與效勞的共享提供了根底。WMS定義了三個操作〔圖〕：“GetCapabilities()”返回效勞層的元數據；“GetMap()”返回一定地理范圍和維度的地圖，用戶提供所需地圖的邊界范圍、圖像大小、格式、錯誤處理等信息；“GetFeatureInfo()”是可選的第三種操作，它返回地圖中指定要素的屬性信息，用戶提供所作用的圖層和點位置的坐標對〔x,y〕。標準的網絡瀏覽器通過發送URLs〔UniformResourceLocators〕請求來激活這些操作，不同操作對應的URLs內容不同。一般情況下請求地圖的URL包括：地圖顯示那些信息、地圖反映地球的那局部、所使用的坐標參考系、輸出的圖像高度和寬度等。具有相同地理參數和輸出大小的兩個或多個地圖，通過疊加能產生復合地圖。同樣，單個地圖可以來自于不同的效勞器，從而實現網絡分布式地圖效勞。WMS通過圖層組織地理信息，并提供有限的用于顯示圖層的預定義樣式。WMS所呈現的地圖可以被定義為一系列的樣式化圖層〔StyledLayers〕。每個圖層可以認為是符號化的要素。一幅地圖是由大量的這些圖層按照一定的次序構成的。用戶通過增加或減少圖層，能定義復雜或簡單的地圖。每個樣式化的圖層本身表示了“圖層”和“樣式”的特定融合。理論上講，圖層定義了一系列的要素和定義如何符號化這些要素的樣式。WMS僅僅支持指定的圖層和樣式，并不包括地理要素的自定義符號化機制。1.2.2網絡要素效勞Web要素效勞〔WFS,WebFeatureServer〕標準描述了使用HTTP協議通過網絡訪問要素效勞的標準，是數據訪問效勞接口之一。WMS允許客戶端重疊顯示來自Internet的多個WMS的地圖圖像。類似地，Web要素效勞允許客戶端從多個WFS中使用GML編碼的地理空間數據。實現WFS的必要條件：接口必須用XML定義；GML必須被用來在接口中表達要素；一個最小化的WFS必須可以使用GML表達要素；謂語或過濾語言將使用XML定義；用來存儲要素的數據庫對客戶端應用應該是不透明的，它們對數據的唯一查看方法應通過WFS接口；使用XPath表達式子集引用特性。WFS是地理要素數據庫提供要素效勞的接口〔圖〕。WFS操作支持在使用HTTP協議的分布式計算平臺上對要素進行插入、更新、刪除、查詢和發現操作。為了支持事務和查詢操作，以下操作必須定義： GetCapabilities，一個WFS必須可以描述它的能力，特別地，必須指出它可以為哪些要素類型提供效勞以及每個要素類型支持哪些操作。 DescribeFeatureType，WFS必須可以在請求中描述它可以提供效勞的任何要素的結構。GetFeature，WFS必須可以為一個獲取要素實例的請求提供效勞。另外，客戶端可以規定獲取要素的哪些特性，并且可以使用空間和非空間的查詢限制條件。 Transaction，WFS可以為事務請求提供效勞。一個事務請求是由修改要素的操作組成的，即對地理要素的創立、修改和刪除操作。 LockFeature，WFS可以處理在一個事務期間對一個或多個要素類型實例上鎖的請求，這就保證了可序列化的事務被支持。基于對以上操作的描述，可以定義兩種類型的要素效勞：根本WFS和事務WFS。其中，根本WFS可以實現GetCapabilities，DescribeFeatureType和GetFeautre操作，它被認為是只讀的WFS；事務WFS可以支持所有的WFS操作。圖是一個簡化的協議圖，描述了為了處理一個典型的事務請求，客戶端和WFS間來回傳遞的數據。WFS請求要遵循上述協議，處理請求的過程：客戶端應用請求WFS的能力文檔，這個文檔包含對WFS支持的所有操作的描述和它可以提供效勞的要素類型列表；客戶端應用〔可選的〕向WFS發出請求，請求得到WFS可以效勞的一個或多個要素類型的定義；以要素類型的定義為根底，客戶端應用向WFS發出事務請求，WFS被調用以讀取請求并為之提供效勞。聚合網絡要素效勞〔AggregationWebFeatureServicesAWFS〕能夠聚合符合OGC的WFS標準的WFS效勞。聚合多個WFS效勞，將它們邏輯關聯在一起，可以更加有效的獲取到WFS效勞的數據〔聚合網絡要素效勞，:///〕。1.2.3網絡覆蓋效勞網絡覆蓋效勞〔WCSWebCoverageService〕是空間數據互操作的一個重要組成局部。WCS面向空間影像數據，將包含地理位置值的地理空間數據作為“覆蓋”在網上進行交換。OGC的WCS執行標準中定義了三種必須的操作〔WCS,://=41〕：GetCapabilities操作返回描述效勞和數據集的