地理信息 服務(wù) 征求意見稿_第1頁
地理信息 服務(wù) 征求意見稿_第2頁
地理信息 服務(wù) 征求意見稿_第3頁
地理信息 服務(wù) 征求意見稿_第4頁
地理信息 服務(wù) 征求意見稿_第5頁
已閱讀5頁,還剩165頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

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

溫馨提示

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

最新文檔

評論

0/150

提交評論