1地理信息服務本標準定義了創建與平臺無關以及與特定平臺相關服務規范的需求，以便保證所創建的服務能夠獨立于一個或多個分布式計算平臺。本標準定義了進一步從平臺無關到特定平臺的服務的映射條件，以便促進一致性和互操作性服務的實現。本標準第6章和第8章涉及ISO地理信息參考模型19101-1:2014中元：服務基礎。本標準定義如何基于架構領域中的服務分類法對地理信息服務進行分類，或者是基于用例生命周期的視角對地理信息服務進行分類，亦或是根據域規范和用戶定義的服務分類法對地理信息服務進行分類，為發布和發現服務提供支持。2一致性2.1一致性聲明任何聲稱與本標準中一致性類相一致的產品均要求滿足附錄A抽象測試套件的所有相關要求。2.2概述本標準定義了6個一致性類，見表1-表6，相應標準類的描述見第6章至12章。任何聲稱與本標準中任意類相一致的服務均要求滿足附錄A抽象測試套件中相應的一致性類的測試列表。每項測試關聯一個或多個特定條件，這些條件在測試描述中已明確的指出。2.3企業視角企業視角的一致性類內容見表1。表1企業視角一致性類一致性類/conf/enterpriseviewpoint條件/req/enterpriseviewpoint(表11)測試A.2中的所有測試2.4計算視角計算視角的一致性類內容見表2。表2計算視角一致性類一致性類/conf/computationalviewpoint條件/req/computationalviewpoint(表12)測試A.3中的所有測試2.5信息視角信息視角的一致性類內容見表3。表3信息視角一致性類一致性類/conf/informationviewpoint依賴/conf/uml(2.4)2條件/req/informationviewpoint(表18)測試A.4中的所有測試2.6服務分類服務分類的一致性類內容見表4。表4服務分類一致性類一致性類/conf/servicetaxonomies依賴/conf/uml(2.4)條件/req/servicetaxonomies(表19)測試A.5中的所有測試2.7工程視角工程視角的一致性類內容見表5。表5工程視角一致性類一致性類/conf/engineeringviewpoint依賴/conf/uml(2.4)條件/req/engineeringviewpoint(表26)測試A.6中的所有測試2.8技術視角技術視角的一致性類內容見表6。表6技術視角一致性類一致性類/conf/technologyviewpoint依賴/conf/uml(2.4)條件/req/technologyviewpoint(表27)測試A.7中的所有測試注：抽象測試套件的定義見ISO19105。3規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。ISO/IEC10746-1:1998信息技術開放分布式處理-參考模型:概述ISO/IEC10746-2:1996信息技術開放分布式處理參考模型:基本概念GB/T35647-2017地理信息概念模式語言ISO19115-1:2014地理信息元數據基礎ISO19118:2011地理信息編碼SOA-RAF面向服務架構的參考框架基礎1.0OSAIS標準，2012年12月4日，SOA-RM面向服務架構的參考模型1.0，OASIS標準，2006年10月12日SoaML面向服務架構建模語言1.0.1版，2012年5月，OMG標準QoS服務質量建模與容差特性和機制UMLtM專用標準(QFTP)1.1版,200年4月,OMG標準，/spec/QFTP/1.14術語、定義和縮略語4.1術語和定義本標準采用下列術語和定義。4.1.1性能capability服務（4.1.12）提供者能夠為服務消費者提供的現實世界的影響[來源：SOA-RAF]4.1.2計算視角computationalviewpoint基于ODP系統及其環境能實現分布處理的視角，這個環境通過系統的功能分解到對象上，對象能在接口(4.1.7)上交互。4.1.3分布透明distributiontransparency對特定用戶屏蔽分布式系統的某些部分的潛在行為的特性。[來源：ISO/IEC10746-2:2009,11.1.1]4.1.4工程視角engineeringviewpoint基于ODP系統及其環境的視角(4.1.15),在系統中以機制和功能需求為重點，支持系統中對象間的分布式交互。[來源：ISO/IEC10746-3:2009,]4.1.5實體entity獨立存在的客觀現實或概念。[來源：/dictionary/entity（2）]4.1.6企業視角enterpriseviewpoint基于ODP系統及其環境的視角(4.7)，在系統中以目的、適用范圍和政策為重點。[來源：ISO/IEC10746-3:2009,]4.1.7接口interface描述實體(4.1.5)行為特征的命名操作(4.1.10)集合。4.1.8信息視角informationviewpoint基于ODP系統及其環境的視角(4.7)，在系統中以信息的語義和信息處理為重點。[來源：ISO/IEC10746-3:2009,]4.1.94互操作性interoperability要求用戶幾乎不了解，或者完全不了解各功能單元的獨特特征的情況下，能在這些功能單元之間進行通訊、執行程序或傳送數據的能力。[來源：ISO/IEC2382-1：1993,01.01.47]4.1.10操作operation對象可以被調用執行的轉換和查詢的規范。4.1.11現實世界影響realworldeffect使用服務（4.1.12）的真實結果,而不僅僅是由服務提供者提供的能力（4.1.1）。[來源：OASISRAF,3.2.3]4.1.12服務service由實體(4.1.5)通過接口(4.2)提供的功能的可區分部分。4.1.13服務鏈servicechain服務(4.1.12)序列，在每個鄰接的服務對中，第一個行為是產生第二個行為的必要條件。4.1.14技術視角technologyviewpoint基于ODP系統及其環境的視角(4.7)，在系統中以技術的選擇為重點。[來源：ISO/IEC10746-3:2009,]4.1.15視角viewpoint為了聚焦系統內所關注的細節，通過選擇框架概念的集合及結構規則形成抽象的形式。[來源：ISO/IEC10746-2,3.2.7]4.1.16工作流workflow根據程序規則的集合，使文檔、信息或任務在參與者之間傳遞和操作，全部或部分自動化實現的業務過程。4.2縮略語本標準采用下列縮略語。API應用程序接口（ApplicationProgrammingInterface）BPEL業務流程執行語言（BusinessProcessExecutionLanguage）BPMN業務流程建模與標注（BusinessProcessModelingNotation）CORBA公共對象請求代理體系結構（CommonObjectRequestBrokerArchitecture）CSL概念模式語言（Conceptualschemalanguage）DAG有向非循環圖（DirectedAcyclicGraph）DCP分布式計算平臺（DistributedComputingPlatform）DEM數字高程模型（DigitalElevationModel）DTD文檔類型定義(DocumentTypeDefinitions)EJB企業JAVABEANS（EnterpriseJavaBeans）ERP企業資源規劃(EnterpriseResourcePlanning)GIOP通用內部ORB協議（GeneralInter-ORBProtocol）GFM通用要素模型（Generalfeaturemodel）HTI人類技術接口（HumanTechnologyInterface）HTML超文本標記語言(HypertextMarkuplanguage)HTTP超文本傳輸協議(HypertextTransferProtocol)IaaS基礎設施即服務（InfrastructureasaService）IDL接口定義語言（InterfaceDefinitionLanguage）IIOP因特網內部ORB協議（InternetInter-ORBProtocol）IT信息技術（InformationTechnology）J2EEJava2企業版（Java2EnterpriseEdition）JDBCJava數據庫互連（JavaDataBaseConnectivity）OASIS結構化信息標準促進組織(OrganizationfortheAdvancementofStructuredInformationStandards)OCL對象約束語言（ObjectConstraintLanguage）ODBC開放式數據庫互連（OpenDataBaseConnectivity）ODMG對象數據管理組（ObjectDataManagementGroup）ODP開放式分布處理（OpenDistributedProcessing見RM-ODP）OGC開放地理空間信息聯盟（OpenGeospatialConsortium）OMG對象管理組（ObjectManagementGroup）ORB對象請求代理（ObjectRequestBroker）OWL網絡本體語言（WebOntologyLanguage）Paas平臺即服務（PlatformasaService）QoS服務質量（QualityofService）QVT查詢/顯示/轉換（Query/View/Transformation）REST,表述性狀態轉移（Representationalstatetransfer）RDF資源描述框架（ResourceDescriptionFramework）RMI遠程方法調用（RemoteMethodInvocation）RM-ODP開放分布式處理參考模型（ReferenceModelofOpenDistributedProcessing）RPC遠程過程調用（RemoteProcedureCall）SaaS軟件即服務（SoftwareasaService）SDI空間數據基礎設施（SpatialDataInfrastructure）SDAI標準數據訪問接口（StandardDataAccessInterface(ISO10303-22)）SOA面向服務架構（ServiceOrientedArchitecture）SoaML面向服務體系架構建模語言（ServiceorientedarchitectureModelingLanguage（OMG））SOAP簡單對象訪問協議（SimpleObjectAccessProtocol）SOF服務組織者目錄（ServiceOrganizerFolder）SPS空間規劃服務（SpatialPlanningService）SQL結構化查詢語言（StructuredQueryLanguage）UML統一建模語言（UnifiedModelingLanguage）URI統一資源標識符（UniformResourceIdentifier）W3C萬維網聯盟（WorldWideWebConsortium）WFS網絡要素服務（WebFeatureService）WMS網絡地圖服務（WebMapService）XML可擴展標記語言（ExtensibleMarkupLanguage）XMLRDFXML資源描述框架（XMLResourceDescriptionFramework）XSLT擴展樣式表轉換語言（eXtensibleStylesheetLanguageTransformations）TM時間模式、時間對象（ISO1910:2002TempralSchema,TemporaObjects）5標記5.1概述本標準描述如何在ISO地理信息系列標準中描述服務。此外還包括對創建服務描述的規則聲明，本標準還通過相關示例為服務描述提供指南。5.2一致性類通過定義一致性類，在多個層面上實現與本標準的一致的可能的。每項一致性類用表7所示的模板進行歸納。表7一致性類模板7一致性類/conf/{classM}依賴[其他一致性類標識符]條件/req/{classA}測試[條目包含的測試參考]某個類中的所有測試均應當通過，所以依賴性存在于其他的一致性類中。每個一致性類測試與第7、第8章中的某個封裝在條件類中的一系列條件相一致。。5.3條件類標準中每項規范性聲明都是條件類的成員。本標準中每個條件類都由獨立的章節來表示，用表8中所示的模板進行歸納。表8條件類模板條件類/req/{classM}[產品或技術類型]依賴[另外一個條件類的標識符]條件/req/{classM}/{reqN}推薦/req/{classM}/{recO}條件/req/{clasM}/{reqP}條件/推薦[必要性重復]類中所有的條件都需要滿足，所以條件類是再利用和獨立性的單元。因此，依賴條件的值是另外一個條件類。5.4規則所有的規則都是標準化的、規范的，每一條規則通過如下模板來表示。/req/[classM]/[reqN][標準的聲明]其中，/req/[classM]/[reqN]標識條件或推薦。5.5標識符每一個條件類，條件和建議都有一個路徑或部分URI作為標識符。此標識符支持類成員之間的交叉引用，支持依賴性以及鏈接一致性測試與已測試的條件。標識符可以附加在標識標準的URI上，為了構建一個完整的URI允許條件類，條件和推薦等可以被外部的上下文關系識別。例如，遵循ISOIETRFC5141標準的URI模式指代URI是：/iso/19109/2每一個條件類的URI的形式是：/iso/19109/2/req/[classM]每一個條件或建議的URI的形式是：/iso/19109/2/req/[classM]/[reqN]5.6概念模式本標準規范部分的概念模式有統一建模語言（UML）表達，與GB/T35647-2017地理信息概念模式語言一致。UML圖與ISO/IEC19505-2一致。5.7概念描述UML中概念由大寫字母表示-如，CLASS，PACKAGE，ROLE，ATTRIBUTE，ASSOCIATION。6地理信息服務體系結構概述6.1目的意義8服務的定義包括訪問和使用地理信息不同層級功能性的多種應用。雖然特定服務仍服務于生產者的自身領域，但服務接口的標準化有助于不同專門產品之間互操作。地理信息系統和軟件開發者可采用這些標準來提供適合于各種地理信息的通用服務或特定服務。本標準綜合采用了通用的信息技術領域中的多種方法，尤其是面向服務的架構。本標準定義的地理信息服務體系結構滿足下列目的：―為特定服務的協調開發提供抽象框架的指導；―通過接口標準化實現可互操作的數據服務；―通過定義服務元數據支持服務目錄開發；―允許將數據實例與服務實例分離；―使某一提供者的服務可應用另一提供者的數據；―定義一種可按多種方式實現的抽象框架。6.2與ISO19101-1的關系表9參考模型概念框架參考模型概念框架層級\基礎互操作性程序標準語義基礎語法基礎服務基礎Meta-metaMeta-meta：語義Meta-meta：語法Meta-meta：服務Meta-meta：程序MetaMeta：語義Meta：語法Meta：服務Meta：程序應用應用：語義應用：語法應用：服務應用：程序實例實例：語義實例：語法實例：服務實例：程序表9列出了ISO19101-1參考模型概念框架中的服務，以及互操作的服務基礎，在本標準中描述如下：Meta-meta:ServiceMeta-meta:Service構成標準作為地理信息處理開發中規則和方法定義的基礎，并且也服務于發現、訪問和處理地理信息。本標準與其他標準在這個層級上相關（Meta-meta:Service尤其是ISORM/ODP,OASISSOARM,ISO19101-1:2014,GB/T35647-2017,ISO19109:和OMGSoaML。Meta：ServiceMeta：Service構成標準作為地理信息處理和服務開發與建模中的規則及方法定義。本標準尤其描述此級別。Application：ServiceApplication：Service構成地理信息服務標準化的定義。服務的能力有Application：Semantic一致。Application：Service包括：地理信息人機交互服務標準；地理模型、信息管理服務標準；9地理工作流、任務管理服務標準；地理處理服務標準空間（如，矢量、Coverage，影像和格網數據專題（如網絡地圖服務，分發數據要素，清洗數據元數據；地理交互服務標準。Instance：ServiceInstance：Service包含在參考模型概念框架中，為了保持完整性，但并不是本標準的范圍。由服務實例組成（包括網絡服務作為Application：service的一部分，遵從服務定義。6.3基于RM-ODP的互操作參考模型本標準的開發是基于開放分布式處理參考模型（RM-ODP）的系統架構，參見ISO/IEC10746。體系結構是通過一系列視角定義的組件、連接點和拓撲等的集合。根據本標準實現的地理信息基礎設施可以有多組用戶、開發者、操作者和審查者，每組人員可按各自的觀點來審視系統。體系架構的目的是從多個視角對系統進行描述。此外，本架構有助于確保每個視角與需求、每個視角與其他視角之間保持一致。RM-ODP視角在本標準中的應用見表10。表10RM-ODP視角在本標準中的應用視角名稱RM-ODP視角定義（ISO/IEC10746-1：1998）本標準中對視角的闡述企業視角見4.1.5見第7章，企業視角計算視角見4.1.2見第8章，計算視角。信息視角見4.1.7見第9章，信息視角。工程視角見4.1.4見第11章，工程視角。技術視角見4.1.3見第12章，技術視角，同時見平臺相關服務規范。企業視角關注企業或業務的目的、范圍和政策，以及它們如何與特定系統或服務關聯。服務的企業規范是服務以及與該服務交互環境的模型。它包括該服務在業務中的角色、與該服務相關的用戶角色和業務政策。計算視角關注系統組件（服務）之間的交互模式，這種交互模式是由接口來描述的。服務的計算規范是客戶端可見的服務接口和該服務所需的一組潛在其他服務的模型。該規范具有描述為信息源和信息匯的交互服務。信息視角關注信息和信息處理的語義。系統信息規范是它擁有的信息和執行信息處理的模型。工程視角關注面向分布式特征的設計，即支持分布式所需要的基礎設施。系統的工程規范定義了網絡化的計算基礎設施，該設施支持在計算規范中定義的系統結構，并提供其所定義的分布透明度。該視角定義了下列分布透明：訪問、失敗、定位、遷移、重新定位、復制、持久性和事務。安全性也可視為一種機制。技術視角描述了按照技術對象配置的系統的實現，該技術對象表示該實現的軟件與硬件組件。它受成本與滿足本規范的技術對象（軟件與硬件產品）的可用性的制約。它們遵從為技術對象提供有效性模板的平臺相關標準。本標準的計算視角與信息視角條款中，給出了定義地理信息服務應遵從的具體方法。對于工程與技術視角，本標準定義了如何把一個特定服務映射到一種實現技術上，如Webservice，RESTservice，SQL，CORBA互聯網或類似的技術。6.4服務抽象服務存在多種定義，本標準中服務的定義如下：由實體通過接口提供的功能的可區分部分。本領域中其他標準闡述了更多關于服務的定義。在OASISSOA參考架構框架[SOA-RAF]中的定義如下：服務是能夠訪問一種或多種能力的機制，通過規范的接口（界面）提供訪問，并檢驗與標準描述中約束和政策的一致性。服務由實體提供，亦服務提供者，為其他人所應用，但是服務的最終消費者可能不知道服務的提供者，并且可能服務的應用證明已經超出服務提供者最初的設計。OMGSoaML中服務的定義如下：服務是通過友好界面分發給其他人的價值，可由某些行業（或團體）提供（可以是普通的公眾）。服務就是一方向另一方提供工作的結果。服務表示參與者的特征，由一個參與者以規范的術語、條件和接口提供給另外的參與者。服務指定一個端口，該端口通過參與者提供能力和為客戶提供服務來定義。在此參種情形中，參與者、端口、服務描述和能力定義如下：參與者-參與者不是提供服務就是使用服務的特定實體或一類實體。參與者可以是人，組織或信息系統組件。參與者可提供許多數量的服務，也可以消費任意數量的服務。端口-參與者通過端口提供或消費服務。端口是參照者的一部分或特征，是服務提供和消費的交互作用點。服務提供的接口可被指定為服務接口，服務消費的接口可被指定為響應接口。服務描述-服務描述指參與者如何根據封裝的服務規范提供和使用服務，通常有兩種規定的服務交換的方法，即簡單的UML接口或兩步服務接口。能力-提供服務的參與者必須是其具備提供服務的能力，但是不同的服務提供者提供相同的服務可能有不同。有些甚至是通過它其他服務提供者發送服務請求來實現服務的代理或“外包”。隱藏在服務背后的能力應當根據某個服務描述提供相應的服務，這種能力也可能是依賴其他服務提供相應的功能，服務能力是供應商不可缺少的業務流程。功能可以從兩個方面來看，一方面某個參與者具備的功能可能被充分用來提供服務，另一方面，某個企業具備的功能應當具備可用來確定候選服務的能力。無論服務如何確定，均通過服務描述形式化。服務描述定義了服務的目的，以及如何正確使用和提供服務的任何交互或通信協議。服務描述可以從它自己的角度定義一個服務的完整接口，而不考慮它可以連接到的任何用戶請求。或者，在一個地方定義的公共服務合同中可能會捕獲用戶請求和提供服務之間的協議，并且約束用戶的請求服務接口和提供程序的服務接口。這種服務建模方法依賴于模型驅動的技術，以分離的邏輯實現在各種平臺上可能的物理實現服務。這種分離的關注都保持該服務模型更簡單，更靈活的底層平臺和執行環境的變化。使用這種方法服務模型可以支持多種技術實現和工具支持幫助自動化這些技術的映射，如下圖1定義了各種類型服務規范之間的關系。SV_ServiceSpecification定義了沒有參考的規范的類型的服務以及其實現。SV_PlatformNeutralServiceSpecification提供了服務規范類型的SV_PlatformSpecificServiceSpecification定義了特定類型服務的實現。CodeLis服務元數據：DCP包括不同的不同目標技術平臺的選擇。SV_Service是服務的一個實現。這些條件在本標準中進行了描述，尤其是第10章。圖1服務抽象與實現6.5互操作性互操作性是指當用戶不了解各種功能單元的獨立特性或知之甚少時，各種功能單元之間的通信、程序執行或數據傳輸的能力。如圖2，組件1和組件2，如果1向2發送服務請求3，在1和2對服務3相互理解的基礎上，2能將可相互理解的響應4返回到1，則1和2可互操作。圖2互操作性這表示兩個可互操作的系統能進行交互，共同執行任務。下列對“地理信息互操作性”術語的描述適用于地理信息領域。“地理信息互操作性”是指信息系統在這些方面的能力：1）自由交換關于地球及位于地表、上空或地下的各類對象和現象的空間信息；2）通過網絡運行軟件協同處理上述信息。ISO1911-1:2014對地理信息領域的互操作性有進一步描述。ODP視角抽象提供了在多個抽象層次中描述系統的框架。本標準根據RM-ODP提供的不同抽象層次來審視互操作性。本標準從不同的視角重點描述如何支持地理元數據和地理數據的語義和語法的互操作。如果兩個不同機構分別開發分布式系統，每個系統均可采用RM-ODP視角描述，系統之間的互操作性可通過對應于RM-ODP的五種視角分別討論。對互操作性的每個方面，應區分語法互操作和語義互操作。語法互操作保證系統技術上的聯接，即數據可在系統之間傳輸；語義互操作保證兩個系統均以相同的方式理解數據內容，包括在給定的環境中人與系統之間的交互。6.6服務規范中其它地理信息標準的使用服務規范應當包含ISO地理信息系列標準中適當標準的相關信息模型。在服務接口定義中應正確使用相應的UML模型。6.7體系結構模式體系結構模式表達軟件服務的基本結構化組織或方案。它標識一系列服務，指定服務的職責，也包括服務之間組織關系的規則和指南。通過類和對象實現的服務，可以使用設計模式，但這種詳細程度超出了本標準的范圍。表11提供了體系結構模式元素的一個列表，在本標準中定義具體結構模式時，建議使用以下元素。表11模式的元素模式的元素元素描述名稱（name）名稱是描述模式的單詞或短語。因為它是用來減少通訊開銷的，所以極為重要。名稱也可以有別名或同義詞。問題（problem）問題是在給定環境或約束中要達到的意圖、目標和任務的問題陳述。約束往往促使這些目標以及約束之間的相互作用。環境（context）環境定義了所要發生的問題和解決辦法以及所期望的解決方案的前提條件，它定義了模式的適用性。在使用模式前，環境可視為系統的最初配置。約束（forces）約束是實現最佳解決方案必須權衡的事項。當產生沖突或不協調時，約束要確定必須考慮的幾種折衷。它要回答的問題是：為什么這是一個難題？結構（structure）描述實現所期望結果的靜態關系和動態規則。結構描述通過協作圖實7企業視角：服務環境7.1企業視角企業視角描述系統和系列服務的環境。它集中在需要被系統和服務支持的目標、業務規則和策略上。服務的企業規范是服務的模型及與服務相互作用的環境。他涵蓋了業務中服務的角色，用戶角色及與服務相關的業務策略。在服務規范環境中，有特別關注的用例和外部功能相關的特定服務。服務發展的經驗表明，擁有模型的企業視角非常實用。關注使用的通用描述，和使用的典型處理。這有助于形成對系統和服務在功能與限制層面的理解。也有助于在已制定的標準和服務中滿足對凝集項目和開發活動的需要，同時也支持新服務的識別。企業視角包括所描述服務的范圍和結構。這個視角可以解釋為何需要此服務，服務的目的，服務與目標之間的關系。它明確、簡潔，針對非專業的對象觀眾。企業視角是以人為本的服務描述。該視角的目的是提供對服務的良好理解，他的活動對象是對服務感興趣的人群。其他的視角也會有面向計算機的服務規范，為了支持服務的實現及與服務的一致性檢測。地理信息服務的目標是支持多個服務和組織機構以便于支持由他們參與的多樣性工作過程。為了提高空間數據共享和處理的目的，他們應該盡可能多的涵蓋組織和程序的業務要工作程序定義為組織創建產品、服務和政策的方法。它在時間、空間上是結構化與相互關聯的活動的連續，由一個可識別的輸入開始，由一個服務或產品的輸出結束。為了獲得需要的輸出，輸入是可以進行轉換的。理想化的情況是，程序中的轉換應該增加輸入值，并且為接收者創建更為有用的輸出，無論是上游還是下游接收者。傳統的工作過程發生在單個機構之間，但是跨組織甚至跨國界的情況逐級增加。通常，由于復雜性，過程被細分為多個子過程，也可以再次被劃分為一系列的活動或任務。因此，簡單的輸入-生產-輸出模型可以由多個相互鏈接的輸入-生產-輸出鏈構成，然而其中的某個子過程的輸出可以服務于另一個子過程的輸入。帶有服務鏈的服務可以支撐這些工作過程。許多過程基于其他產品來創建產品，舉例來講，如汽車制造商。對于處理政策準備、監測、評估、決策或服務提供的過程流程，數據的注釋和信息流是關鍵環節。對于服務和服務鏈，為了處理數據并生產新的數據和信息服務用于決策，服務于其他機構、決策制定者或市民，作為輸入的數據和信息是關鍵。7.2企業視角服務規范用企業視角創建服務規范的條件總結如下表12所示：表12企業視角服務規范的條件類條件類/req/enterpriseviewpoint服務描述條件/req/enterpriseviewpoint/servicename條件/req/enterpriseviewpoint/servicetypes條件/req/enterpriseviewpoint/purpose條件/req/enterpriseviewpoint/scope條件/req/enterpriseviewpoint/capabilities條件/req/enterpriseviewpoint/community建議/rec/enterpriseviewpoint/scenarios/req/enterpriseviewpoint/servicename服務名稱用文本字符串描述，表示服務的名稱注1：這是人類可讀的服務標識（如，WebMapService，WebFeatureService，Sensor/req/enterpriseviewpoint/servicetypes根據本標準的架構服務類別或其他服務目錄，對服務進行分類注2：服務的目的需要清晰的描述服務的傾向性目標。定義服務的目標，解決，執行和完成。/req/enterpriseviewpoint/purpose用文本段描述服務目標，表明服務的范圍和目的。注3：服務的目的需要清晰的描述服務的傾向性目標。定義服務的目標，解決，執行和完成。1/req/enterpriseviewpoint/scope用文本段描述服務范圍，表明服務可以提供的能力，以及在范圍之外的相關能力注4：能力可以描述為一系列不同的能力，以及服務對真實世界的影響。能力對真實世界的影響可以是同共享信息一樣簡單，或涉及復雜過程的執行，或改變其他相關過程的狀態。/rec/enterpriseviewpoint/capabilities服務能力是可以規定為由服務提供的一系列功能，以及他們對真實世界的影響注5：能力可以描述為一系列不同的能力，以及服務對真實世界的影響。能力對真實世界的影響可以是同共享信息一樣簡單，或涉及復雜過程的執行，或改變其他相關過程的狀態。2/req/enterpriseviewpoint/community服務社區由文本段描述，表明使用服務中潛在的角色注6：角色由高級別的提供者描述，以及用戶和消費者之間較好數據的使用能力。/rec/enterpriseviewpoint/scenarios服務使用有過程視圖規定表明可能的使用過程的服務用例（如，BPMN和/或UML用例）這是關于用例場景的描述，這些場景表示由服務提供的接口、操作的使用的概念模型。場景用于企業視角服務的典型應用的描述。場景應該描述基本的流。如果場景有可選擇的流，需要文檔化。簡單的可選擇的表需要在基本流中進行標記。復雜的可選擇的流應該獨立描述。場景能夠描述為一系列的步驟，但是我們推薦使用圖表來描述每一個商務場景。推薦使用BPMN和UML用例圖及模板。場景可以比描述性的文字更好的描述服務，它能夠表示服務所能扮演的角色。這可以在代表性場景中使用，而不需要詳盡的描述。場景與通過描述特定功能和對象的方式來驗證服務可用性的測試用例有關。具體的行動是確定的，可能是衡量預期的測試結果與產出。質量服務QoS規范可以在相關的服務描述中應用。為滿足這一目的，推進使用服務質量建模與容差特性和機制UMLtM專用標準(QFTP)（QoS）。服務策略，服務合同包括服務級別的協議（SLAs目前不是本標準的一部分，這些被認為是與服務分發和服務所有者極度相關的，目前也不是本標準的關注點。7.3相關標準舉例BPMN-業務流程建模與標注-這是OMG的標準，目的是面向業務和企業的建模，也可以是對技術處理過程的技術映射，比如BPEL[39].Usecases-UML，使用模板的用例通常應用于系統和服務功能的典型用戶需要，在地理信息團體內。UML標準只提供一個用例的圖形格式，然而，地理信息團體通常都會采用多種形式的用例模板來表達。敏捷需求工程與用戶存儲-軟件工程社區目前引入了一系列敏捷方法，加強潛在系統用戶和開發者之間的聯系，更多關注用戶的輕量級存儲作為系統開發積壓的輸入。用戶的過程可以擴展為用例。BMM-業務動機元模型-這是OMG提供的一項關于企業級可視化、目標和對象的建模基礎標準，包括了對應用處理和服務的映射策略。UML4ODP企業規范介紹（ISO/IEC19793）這項標準為RM-ODP企業視角定義的主要概念提供了UML介紹。他是執行完整的RM-ODP企業級視角建模的參考和基礎，但是在地理信息社區，因為應用輕量級的方法處理BPMN和/或用例。見例[43].7.4例子和工具附錄D提供了用例的例子，該用例基于地理信息服務上下文中所需要資源的標識方法，在附錄E中包括了用例模板的例子，涉及數據和服務資源。為了展示不同視角的服務規范，例子的元素與ISO19123和傳感器規劃服務以及WMS和WFS中獲取服務操作（GetCapabilities）相關。8計算視角：服務接口和鏈的基礎8.1組件和服務互操作性及其計算視角計算視角描述獨立于實現和語義內容的分布式系統實體。它描述了實體及其接口之間的交互模式。在計算視角中為實現互操作，兩個系統必須是“接口-服務可互操作”。如果兩個系統在它們的實體所提供的一系列服務和這些實體的接口均一致，則這兩個系統是“接口-服務可互操作”。通過定義標準化的接口，一個系統中的實體就能從另一系統的實體中請求服務。本章內容包括：―定義服務、接口和操作的概念以及這些概念之間的關系；―通過n層體系結構提供服務物理分布的途徑；―定義一個模型來組合系列相關的服務，以實現更為復雜的任務，例如服務鏈接；―定義服務元數據模型并通過服務目錄來支持服務發現。8.2服務、接口和操作本條款給出多個術語的定義及其它們之間的關系。本標準將使用這些術語。―服務：由實體通過接口提供的明確功能。―接口：描述實體行為特征的具有名稱的操作集合。―操作：調用對象執行轉換或查詢的規定，操作有名稱和參數列表。術語之間的關系如圖3，服務由一系列接口（接口即操作）來規定。接口實現為端口，端口使得服務對用戶可用。圖3服務定義的關系服務中接口集合應當視為定義對用戶有價值的功能，這里的用戶可以是軟件，也可以是人。服務提供增值功能，這種增值對調用服務的用戶是可見的。接口中操作集合與接口定義應當滿足軟件可重用性的要求，應當為便于在多種服務類型中重用而定義接口。一個接口的語法可以以不同的語義重用于多個服務中。多種類型的服務可以聚集。服務類型的定義應當與10中服務分類一致。當某個服務提供的功能超出服務分類中單個服務種類時，應當被看成是一個聚合服務，如8.4中的定義的服務鏈接所產生的服務集合體。接口是抽象的規范，它與具體的部署或數據格式的綁定是分離的。接口規范應當包含一個靜態部分，該靜態部分包括操作的定義。接口規范包含一個動態部分，該動態部分包括調用操作順序的約束。接口實現為端口。實現包括平臺相關規范的實現以及識別服務的方法，如地址。服務的實現可能與某個具體的數據集有關或者是可以被用于操作多個非指定數據集的服務。第一種情況被稱為緊耦合式服務，第二種狀況被稱為是松耦合式服務，見8.4.1。接口通過操作來定義。操作定義目標對象的狀態轉換或者是對操作的請求者有返回值的查詢。操作應當是由接口支持的某個動作的抽象描述。操作包含參數。計算視角關注系統組件（服務）之間的交互模式，使用接口來描述。從客戶角度看服務的計算規范是服務接口的模型，也是這項服務為其他系列服務提供，與交互服務相關，描述為信息的源和匯。在多樣式的SOA環境中，服務規范也包括產生和接收的信號（事件支持同同步或一部交互，也是面向RPC和面向文檔/RESTful的交互。計算視角是接口和服務標識的核心。8.3計算視角服務規范8.3.1計算視角服務規范條件類創建計算視角服務規范的條件歸納見表13：表13計算服務視角的條件類條件類/req/computationalviewpointUML服務模型依賴GB/T35647-2017地理信息概念模式語言ISO19115-1:2004（元數據）條件/req/computationalviewpoint/interfaces條件/req/computationalviewpoint/operations建議/rec/computationalviewpoint/behavior建議/rec/computationalviewpoint/pre_and_post_conditions條件/req/computationalviewpoint/servicechaining條件/req/computationalviewpoint/servicemetadata建議/rec/computationalviewpoint/servicechaining8.3.2服務接口與操作/req/computationalviewpoint/interfaces服務應該通過平臺無關的方式進行描述，使用抽象接口描述單路接口，《ServiceInterface》描述更為復雜的多路接口。服務的接口可以分為必選的和可選的。這兩種規定服務的方法描述如下：——簡單接口-簡單的接口主要關注由參與者提供的接口的單路交互，用UML接口表達。參與者接收這個端口的操作并向呼叫者提供結果。這類單路的接口可以為匿名呼叫者使用，且參與者對服務呼叫者不做假設和編排。——服務接口基礎-服務接口基礎方法允許雙向服務，這些“回調”從供應商到消費者作為雙方對話的一部分。服務接口由服務提供者定義，指定與消費者之間的接口。服務接口還可以指定服務之間的編排信息，包括什么信息通過什么規則在提供者和消費者之間傳遞。服務消費者指定服務接口需要使用一個請求端口。提供者和消費者之間的接口必須是相同或兼容的。如果他們是兼容的，提供者可以為消費者提供服務。消費者需要遵照消費者的服務接口，但是他們之間不會有任何前置的協議。服務接口的能力決定這些協議是否一致以及能否被連接完成顯示時間的服務功能或實現價值交換。服務接口是提供者的服務端口到消費者的端口。總之，消費者通信使用服務接口定義的服務，服務提供者共享提供服務接口的服務。服務接口的能力決定他們之間是否可以了連接并能保持一致性。服務接口方法是最可應用為現有能力的服務，通過多種實現途徑，達成一方或多方之間的服務協議。/req/computationalviewpoint/operations接口操作應該描述為平臺無關的方式，來表明參數的輸入和輸出（及例外）。輸入、輸出參數（包括例外）的細節描述可通過《MessageType》從信息視角進一步描述。供應商和消費者，并在什么秩序。操作規定如下：對每一個操作（主要動作描述操作名，操作目的，操作輸入、輸出參數，作為《MessageTypes》類型，進一步通過信息視角進行精煉和描述。SoaML標準也為服務協議和服務架構規范提供支持，用UML協助圖表達，這些應用本標準中不做要求。在抽象接口的操作由他們的輸入、輸出參數的邏輯表格表示，與UML模型一致的相關定義通過信息視角描述。經驗表明多數服務由簡單接口指定，在服務提供者和用戶之間沒有復雜的雙路協議。有時，更復雜的雙路交互是需要的。本標準遵從SoaML的推薦，使用簡單協議的UML接口標準規范，并且在復雜的雙路協議需要時使用SoaML的服務接口概念。圖4給出了簡單接口描述的例子（來源：OGCSOS2.0）圖4簡單接口描述的例子例子：基礎傳感器規劃者具備操作的GetCapabilities，這一操作運行請求和接收描述特定服務執行的服務元數據文件。這個操作也支持客戶端-服務器交互的版本規范的轉讓。8.3.3服務行為與約束/req/computationalviewpoint/behaviour服務行為由UML序列圖表示，表示可能的序列操作。服務的可能狀態和狀態轉換通過UML狀態圖表示。圖5用序列圖表示了操作的可能序列（來源：OGCSPS）圖5用序列圖表示操作應用的潛在序列圖6轉換中的鎖定處理圖6給出了轉換中的鎖定處理的例子（來源:ISO19142）/rec/computationalviewpoint/pre_and_post_conditionspre-和post-條件及操作比對變量通過OCL表達式表示。8.4服務鏈接8.4.1服務鏈接概述為完成復雜任務，8.4定義一個模型來組合系列相關的服務。8.4描述了服務鏈接的語法問題，如一個鏈的數據結構。服務鏈接的例子見附錄B。/rec/computationalviewpoint/servicechaining服務的可能組件和構件通過服務鏈表示。回顧服務鏈的數據結構，確定他是否是一個有向圖。確定服務鏈的節點是否是服務。架構應該提供鏈擴展的方法和用戶之間轉換的方法，以及滿足用戶評價和驗證鏈的方法。一個可擴展的服務鏈是半透明鏈模式中必須的。如果一個架構聲稱執行透明鏈模式，確認人類用戶可以控制鏈的執行。如果一個架構聲稱執行半透明鏈模式，確認服務鏈能夠對人類用戶進行獨立擴展并且獨立的完成鏈執行。對于透明鏈模式，架構應該為用戶提供確定服務價值的機制，比如：服務目錄或服務組織文件結構。本標準幫助用戶在數據或服務提供者事先未定義組合方式的情況下組合數據或服務。這種數據／服務互操作性級別將達到一個新的階段。首先，服務目錄將條目與數據／服務緊密綁定。最終，信息基礎設施幫助用戶決定哪種數據可按松散耦合式的服務來執行。這種互操作能力將通過更廣.IT領域的基礎設施來實現。8.4.2服務鏈解析鏈的UML建模圖7給出了鏈的UML模型。圖7基礎服務鏈參考GB/T35647-2017服務鏈的有向圖建模可以使用UML活動圖來實現。活動圖表示鏈執行的狀態。表14標出了活動圖的元素。相關的方法包括使用BPMN作為服務組件和編排的建模語言。BPMN【39】用于支持BPEL中的網絡服務組件，也用于支持用戶視角的業務處理建模。表14UML活動圖實體UML活動圖中的元素服務鏈接的描述活動狀態標識服務執行的狀態，通常通過一個操作的調用來觸發。轉換兩種狀態之間的關系。轉換表明當指定事件發生并且滿足警戒條件時，指定行為在第一狀態執行結束后，進入第二種狀態。分支/合并活動圖中可選擇線程的開始/結束。分叉/連接活動圖中并發線程的開始/結束。信號活動圖中用于觸發轉換的服務之間的異步通訊。8.4.3服務鏈建模作為有向圖的鏈有向圖是一系列有邊界鏈接的節點，每條邊界管理一個方向。使一個服務的輸入依賴于另一個服務的行為，使得服務鏈成為有向圖，其中每個服務是圖中的一個節點，服務的相互指向形成了有向圖的邊。在某些情況下，有向圖結構是隱含的。在其他情況下，有必要使處理圖的概念明確化，并允許這些圖在它們的權限下視為實體。服務鏈的明確表達允許鏈可視化，并傳遞給鏈執行服務，如工作流服務。一旦明確形成數據結構，服務節點就包含有兩類信息：參數和源。服務節點中的參數提供了特定鏈的服務配置，在特定鏈中使用服務類。服務節點中的源標明指向節點的數據輸入源。有向圖中的弧段可以有幾種類型，這些類型的弧段作為服務交互詳述如下。—循環或非循環有向圖。沒有回路的有向圖，也就是非循環的有向圖，是簡單的。在某些應用中，需要采用迭代方法，因而在涉及收斂性的控制功能中，鏈應該是循環的。—鏈可以被看作是模板或不變圖。模板是一個在抽象類基礎上定義了鏈的有向圖，包括每種服務類型的標識。當模板可以實例化為不變圖時，服務實例是固定的。/rec/computationalviewpoint/servicegraphs有向圖可用作服務鏈的模型，且鏈的特征可被描述。/req/computationalviewpoint/servicenodesandarcs如果有向圖被使用，則：有向圖的節點應該是服務的一個表達有向圖的弧應該表示服務鏈/rec/computationalviewpoint/servicenodesandarcs如果有向圖被使用，如下的附加元素用來表示服務鏈的特征，建模時（列表未用完——平行或序列鏈——迭代——數據傳輸類型——節點中的參數——控制設計模式的變量下面是服務鏈的另一些特征，建模時：―并行鏈與串行鏈：有向圖是否有基于分支的并行路徑，或者僅有所允許的串行鏈？潛在的分支類型包括：如果／否則、合并、轉換、觸發。―迭代：有向圖中節點是否是作為反復操作？如條件循環和計數循環。―數據傳輸類型：有向圖是否允許節點之間鏈的變化？這些節點反映數據傳輸、服務調用的不同方法。―節點中的參數：有向圖中節點描述是否包含可改變的參數？―控制設計模式中的變量：拉處理與推處理。有向圖可以用許多不同的方法建模，其中的一個就是UML序列圖。序列圖被用來為土工的架構模式建模的例子見8.4.6。8.4.4服務組織者目錄服務有10.1中所示的多種類型。只有可用服務的一個子集可被應用到具體環境中，如影像分析。SOF幫助用戶發現符合其應用要求的服務。用戶可以構造一個SOF，并使這個SOF對其他執行相似任務的用戶可用。SOF是一種數據結構，它包含在給定條件下可應用的一系列服務的參照。SOF無需包含服務鏈，可以僅僅包含多個獨立的服務。8.4.5支持服務鏈接的服務用于支持服務鏈接的必要服務見表15。服務的詳細介紹見第10章，一些服務對所有IT領域是通用的，另一些服務則專門針對地理數據和大型的地理數據集。表15支持服務鏈接的服務支持服務鏈接所需的服務OSE類別通用IT服務地理信息服務互服務制服務鏈，并說明其狀態。覽服務的元數據。瀏覽和管理空間數據的元數據。顯示、查詢和分析地圖數據。子表單格式顯示和操作地理數據。工作流/任務服務態化和控制服務鏈接（和其它工作流服務的交互，可選）的資源保存和協同配置機制，用于支持可預測轉換所需要的端到端的性能保證。—務—服務據目錄。.可發現和管理子服務的服務類型注冊。理元數據目錄。理服務和評估技術，包括存儲系統，網絡和計算機。具化的工具服務。 通訊服務.遠程文件和可執行管理：提供對遠程文件的本地訪問和存儲。地理信息格式轉換。8.4.6服務鏈接的體系結構模式概述服務鏈接的體系結構模式使用了6.7中定義的結構。將服務鏈接服務分配到組件的途徑有多種。不同的分配方法反映不同應用的不同優先級：環節中的用戶與用戶監督相對。為了表明這種變量定義的交換空間（tradespace）的擴大，下面給出可以改變控制功能分配的三種設計模板：-用戶自定義（透明）鏈接：用戶直接管理工作流；-工作流管理（半透明）鏈接：用戶調用一個控制鏈的工作流管理服務，且用戶知道服務鏈中的單個服務。-聚合服務（不透明在用戶不知道單個服務的情況下，調用一個執行鏈的服務。除了服務對用戶可見性存在差異外，這些模式之間最主要的差異在于控制上的差別。在透明鏈中，用戶獨占控制；在半透明模式中，工作流服務控制鏈的執行，也許用戶未覺察到該鏈的執行；在聚合服務模式中，聚合服務獨自執行控制功能，這對用戶是不可見的。用戶自定義（透明）鏈接.1名稱正如名稱的含義，用戶定義和控制單個服務的執行順序，對于用戶，服務細節可見，因此，這種模式的別名為透明鏈接。.2問題在這種模式中，用戶知道應如何組合服務，用戶發現和評估可用的服務，確定服務對需求的適用程度，確定服務的有效序列并控制服務鏈接。這種模式假設用戶具備相關知識，并為用戶決定控制提供足夠信息。.3環境用戶參照服務目錄來發現感興趣的服務。在用戶開始介入服務鏈接之前不存在一個具體的鏈。用戶有能力定義一個有效鏈，如果在執行中失敗，用戶有能力修改該鏈。.4約束用戶必須能夠設計可執行的有效鏈。單個服務的輸入和輸出必須兼容，或能增加干預服務，如格式轉化。這些模式假設每個服務有足夠的資源來高效運行，但用戶可能需要考慮網絡環境來選擇服務，如網絡寬帶、安全性、授權等。鏈的語義正確性由用戶來判定，諸如何時在鏈中重新柵格化數據等問題將影響結果的正確性。用戶可以重復使用鏈直到獲得可接受的鏈為止，這種鏈可被存儲或被其他用戶使用，這種情況用戶也可使用工作流鏈接模式。.5結構圖8給出用戶自定義的鏈接體系結構模式。具體步驟見表16注：透明模式的唯一特征表現為：鏈是由用戶定義并控制的。圖中，用戶通過一個目錄服務發現可用圖8明鏈接－用戶自定義鏈接的體系結構模式表16對圖8中步驟的描述步驟1：查詢請求用戶在客戶端向目錄服務發出一個查詢請求（或多個查詢請求）。目錄服務提供服務元數據查詢。步驟2：查詢結果目錄服務返回用戶感興趣的服務元數據，例如，用戶發現三個可被鏈接的服務。步驟3a：調用服務步驟3b：返回結果用戶通過客戶端調用服務，產生對后續服務有用的結果。結果返回到客戶端。步驟4a：調用服務步驟4b：請求輸入步驟4c：返回結果用戶通過客戶端調用第二個服務，請求包括對前一步返回結果的參照，該服務創建一個可被下一個服務應用的結果。結果返回到客戶端。步驟5a：調用服務步驟5b：請求輸入用戶通過客戶端調用第三個服務，請求包括對前兩個服務返回結果的參照，第三個服務為客戶端返回結果。結果返步驟5c：請求輸入步驟5d：返回結果回到客戶端。工作流管理（半透明）鏈接（編排）.1名稱正如名稱的含義，這種模式中鏈的執行是通過一個工作流服務（或多個工作流服務）來管理，在鏈接過程中用戶介入鏈的階段主要是觀察服務鏈執行各個服務，這些服務對用戶是可見的，因而其別名是半透明鏈。這種模式的一個主要的特征是鏈的定義在前，用戶執行在這種模式是信息技術團體特別有名的編排。編排定義了一個服務調用其他服務的序列和條件，來實現一些可用功能。編排是網絡服務代理為達到目的必須遵循的交互模式。.2問題在這種模式中，用戶依賴工作流服務來執行預定義的服務鏈。用戶確定一個已存在的鏈并設想能產生用戶感興趣的結果。用戶可能需要為特定實例提供參數，但依賴工作流服務來執行鏈。.3環境用戶已了解一個工作流服務，并選擇了一個感興趣的鏈。用戶通過與工作流交互的方式來執行鏈，包括為用戶感興趣的數據實例提供具體參數。.4約束為了減少用戶工作量，工作流服務處理執行鏈時在分布式計算的細節。盡管通過評價中間結果，預先定義的鏈被認為具有一定程度的語義有效性，但用戶仍可以評估這個處理過程的具體實例的語義有效性。例如，對包含迭代算法的一個服務，用戶需要判斷收斂是否達到足夠的精確度。.5結構圖9是工作流－管理（半透明）鏈接的體系結構模式。具體步驟見表17.注：可能存在多種工作流服務。如果存在多個工作流服務，工作流服務必須協調預定義鏈的執行。在極端情況下，鏈中的每個服務均包含一個工作流服務，服務產生的結果沿著鏈傳遞。半透明模式的獨特處在于存在預定義鏈，且用戶了解該鏈。圖9半透明鏈接－工作流管理鏈接的體系結構模式表17對圖9中步驟的描述步驟1：調用鏈用戶在客戶端請求工作流服務來執行鏈。在執行前允許用戶修改鏈的某些方面。步驟2a：調用服務步驟2b：返回結果步驟2c：服務狀態工作流服務確定鏈中的服務并調用第一個服務，任務的完成由該服務通知工作流服務。向工作流服務返回結果。服務狀態可以直接提供給客戶端。可以從客戶端停止工作流。步驟3a:調用服務步驟3b：請求輸入步驟3c：返回結果步驟3d：服務狀態在得到第一個服務完成通知的基礎之上,工作流服務確定鏈中的下一個服務并調用它。第二個服務請求始于第一個服務的結果，任務的完成由該服務通知工作流服務。向工作流服務返回結果。服務狀態可直接提供給客戶端，也可以從客戶端停止工作流。步驟4a：調用服務步驟4b：請求輸入步驟4c：請求輸入在得到第二個服務完成通知的基礎之上,工作流服務確定鏈中的下一個服務并調用它。第三個服務請求始于第一個和第二個服務的結果，任務的完成由該服務通知工作流服務。向工作流服務返回結果。步驟4d：返回結果步驟4e：服務狀態服務狀態可直接提供給客戶端，也可以從客戶端停止工作流。步驟5：鏈的結果在得到最后一個服務完成通知的基礎上，工作流服務通知客戶端鏈已完成。集成服務（不透明鏈-編排）.1名稱正如名稱的含義，在這種模式中服務表現為單個服務，它協調隱藏在集成服務中的單個服務。用戶不了解在集成服務之后隱藏的一系列服務，因而其別名為不透明鏈。這種模式是信息技術團體特別有名的編排。編排是多個合作獨立機構交換信息執行任務來達到目標狀態的條件下的序列和條件的定義。.2問題在這種模式中，用戶依賴集成服務來執行一個預先定義好的服務鏈。用戶發現集成服務，但并不清楚集成服務是如何完成的。用戶可能需要為具體實例提供特定參數，但依賴集成服務來執行鏈。.3環境用戶了解集成服務，但可能不知道服務鏈是如何實現集成的。用戶通過與集成服務交互的方式來執行鏈，包括為用戶感興趣的數據實例提供具體參數。.4約束為了減少用戶工作量，集成服務處理所有與鏈執行相關的多個服務的細節。雖然通過評價中間結果，集成服務鏈被認為具有某種程度的語義有效性，但用戶仍可以評估這個處理過程的具體實例的語義有效性。例如對包含迭代算法的一個服務，用戶需要判斷收斂是否達到足夠的精確度。這種中間結果無需指明其所代表的服務。.5結構集成服務（不透明-鏈接）體系結構模式，如所示。具體步驟描述見表18.圖10不透明鏈接表18對圖10中步驟的描述步驟1：調用服務用戶使用客戶端請求集成服務來執行鏈。用戶也許不知道如何使用服務鏈執行服務。步驟2a：調用服務步驟2b：返回結果集成服務確定鏈中的服務并調用第一個服務。該服務通知集成服務任務的完成，向集成服務返回結果。步驟3a：調用服務步驟3b：請求輸入步驟3c：返回結果在得到第一個服務完成通知的基礎之上,集成服務決定鏈中的下一個服務并調用它。第二個服務請求始于第一個服務的結果，任務的完成由該服務通知集成服務，向集成服務返回結果。步驟4a：調用服務步驟4b：請求輸入步驟4c：請求輸入步驟4d：返回結果在得到第二個服務完成通知的基礎之上,集成服務確定鏈中的下一個服務并調用它。第三個服務請求始于第一個和第二個服務的結果，任務的完成由該服務通知集成服務，向集成服務返回結果。步驟5：鏈結果在得到最后一個服務完成通知的基礎上，集成服務通知客戶端鏈已完成。8.4.7鏈接模式的變化上述討論的三種鏈接模式可按各種各樣的方式組合。模式圖中，最底層中的每一個服務可依次實現一個鏈。這就是由不透明模式支持的服務的遞歸合成（recursivecomposition）。一個服務鏈可以成為一個新的服務。定義服務遞歸合成的能力提供了可擴展性并支持從上到下的逐層細化，如同從下到上的集成一樣。這些模式可以用于定義如何構建一個鏈庫。有經驗的用戶可以利用透明模式創建鏈。通過透明模式迭代應用來構建一個能產生有效結果的鏈。根據半透明模式，鏈可以更廣泛地應用。某個鏈可能被例行使用，集成服務作為接口被創建。例如，在決策支持中需要出現一種半透明或不透明的鏈接模式。決策者個人使用決策支持工具做出決策。決策支持工具的例子是一個服務鏈，決策支持工具開發者將服務鏈集成到決策支持工具。另一種服務交互可被看作是一個鏈接，其中：用戶向引導服務發出請求，引導服務調用第二個服務，第二個服務又調用第三個服務。當從所代表的服務中得到足夠的信息時，每個服務均向請求做出回應。在這種情況下，只有隱含的鏈而沒有明確的鏈。8.5服務元數據/req/computationalviewpoint/servicemetadata服務元數據應該根據ISO19115-1:2014,6.5.14內容進行描述。服務元數據與服務質量（QoS）相關。8.6簡單服務體系結構當實現一個基于消息的體系結構以支持服務鏈接時，應當考慮下列簡化假設。系統聲稱為簡單服務體系機構的實例時應當遵從如下內容。—消息－操作。為簡單起見，理想的方式是把操作模擬為消息。消息操作應當包含請求與響應，請求與響應包含參數作為有效荷載，參數獨立于內容并以統一的方式進行傳遞。簡單的應用是以消息的交換模式為特征，如單向（或事件）和雙向（或同步）請求響應交互。服務規范應當使得這種簡單的交換應用盡量容易創建與使用。—控制與數據分離。控制服務的客戶端可能不需要該服務的所有結果。例如，用戶也許不需要那些在服務鏈中可能存在的大量中間結果，而只需要服務鏈的最終結果。因此，接口操作應當將服務產生的數據與服務的控制相分離。客戶端應當具有只接受操作的狀態的選項，而數據可以通過獨立操作進行訪問。—有狀態與無狀態服務。為簡單起見，理想情況下服務是無狀態的，即服務調用由一個不依賴于過去或將來交互的單一的“請求－響應”對組成，但這種情形并不總是成立。對于某些服務，需要設置前提條件并且需要迭代，此時，需要一個具有多種狀態的狀態圖對服務進行建模。狀態之間的轉換通過操作來觸發。—已知服務類型。所有的服務實例都屬于具體的服務類型，客戶端在運行前已知道這些類型。在一個已實現的服務體系結構中，客戶端應當安裝在接觸服務實例之前訪問服務類型的軟件工具。這里假設客戶端了解服務類型。—充足的硬件。本標準中描述的服務都是由運行在硬件主機上的軟件實現的。本標準假設安裝軟件的硬件對用戶是透明的。這里假設服務具備充足的硬件，也就是硬件配置對用戶是透明的。8.7相關標準舉例SoaML——面向服務的體系架構建模語言（SoaML）9-是OMG的一項標準，為服務建模提供了UML介紹和元模型，所有的主流UML工具提供商都支持此標準，但是SoaML協助建模部分的支持工具很少，因此本標準中不做要求。UML4ODP計算規范（ISO/IEC19793）這個ISO標準為RM-ODP計算視角的所有主要概念提供了UML范例。它對完整的RM-ODP計算視角建模非常有參考價值，但是對地理空間信息團體已表明它有輕量級的方法。8.8例子和工具-利用SoaML服務建模面向服務的體系架構建模語言（SoaML）規范為面向服務體系架構的服務設計定義了UML范例和元模型。SoaML的目標是支持服務建模、設計和模型驅動的方法的活動，從業務和IT視角支持SOA。本標準是SoaML的一部分，被用作簡單接口和復雜服務接口所用的信息類型的規范。9信息視角：語義互操作的基礎9.1信息模型互操作與信息視角實現“信息模型互操作”是ISO地理信息系列標準套件的主要目標之一。在這個系列中的許多標準，ISO-19107，ISO19115-1和其他標準，主要關注定義服務所處理的信息內容，以及服務之間交換的信息內容。ODP中定義的信息視角包括靜態信息模型和動態信息模型。8.4中闡述了服務的交互語義，如，哪些服務對服務鏈有意義。信息模型描述組成服務和服務操作的輸入與輸出的數據。輸