JT / T 1505. 1—2024
目 次
前言 ………………………………………………………………………………………………………… Ⅱ Ⅲ
引言 …………………………………………………………………………………………………………
1 范围 ……………………………………………………………………………………………………… 2 规范性引用文件 ………………………………………………………………………………………… 1 1
3 术语和定义、缩略语 ……………………………………………………………………………………… 4 总体架构 ………………………………………………………………………………………………… 5 服务规格 ………………………………………………………………………………………………… 1 2 5
6 服务技术设计 …………………………………………………………………………………………… 7 服务实例 ………………………………………………………………………………………………… 13 17
附录 A(规范性) 基础数据类型 XSD 结构 ……………………………………………………………… 附录 B(规范性) 服务规格 XSD 结构 …………………………………………………………………… 附录 C(规范性) 服务技术设计 XSD 结构 ……………………………………………………………… 22 24 30
附录 D(规范性) 服务实例 XSD 结构 附录 E(规范性) 服务规格文件模板 …………………………………………………………………… 33 36
……………………………………………………………………
附录 F(规范性) 服务技术设计文件模板 ……………………………………………………………… 附录 G(规范性) 服务实例文件模板 …………………………………………………………………… 37 38
Ⅰ
JT / T 1505. 1—2024
前 言
本文件按照 GB / T 1. 1—2020《标准化工作导则 第 1 部分:标准化文件的结构和起草规则》的规则
起草。
本文件是《E 航海技术服务规范》的第 1 部分。 JT/ T 1505 已经发布了以下部分:
———第 1 部分:总体要求。
请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别专利的责任。
本文件由交通运输航测标准化技术委员会提出并归口。
本文件起草单位:交通运输部南海航海保障中心、交通运输部水运科学研究所。
本文件主要起草人:王平、杨毅、洛佳男、余锦超、唐承源、罗子汶、李春旭、邬金、文捷、于巧婵、
高汉增、马永学、丁格格、李益琴、耿雄飞、熊娥、熊骏超、刘超、徐海生、晏小浩。
Ⅱ
JT / T 1505. 1—2024
引 言
E 航海技术服务是基于多种技术和通信方式,可以为航海用户播发提供交通组织、海上安全信息、
水文气象、港口、电子海图、数字出版物、冰况、远程医疗等标准化海事服务(Maritime service)的软件功
能集。 本文件旨在统一我国 E 航海技术服务规范,促进我国海事服务在全球范围内的推广应用,保证
国际、国内船舶在泊位到泊位间获取连续、标准的信息服务,拟由五个部分组成:
———第 1 部分:总体要求。 目的在于规定 E 航海技术服务规范的编制方法和要求,指导服务设计、
开发与应用。
———第 2 部分:航线信息服务。 目的在于规定 E 航海航线规划、航线检查、航线交换等技术服务的
基本要求、技术设计以及相关实例。
———第 3 部分:海上安全信息服务。 目的在于规定 E 航海海上安全信息技术服务的基本要求、技
术设计以及相关实例。
———第 4 部分:水文气象信息服务。 目的在于规定 E 航海水文气象信息技术服务的基本要求、技
术设计以及相关实例。
———第 5 部分:交通组织信息服务。 目的在于规定 E 航海交通组织信息技术服务的基本要求、技
术设计以及相关实例。
Ⅲ
JT / T 1505. 1—2024
E 航海技术服务规范
1 范围
第 1 部分:总体要求
本文件规定了 E 航海技术服务的总体架构,以及服务规格、服务技术设计和服务实例等的要求。
本文件适用于 E 航海技术服务的设计、开发与应用。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。 其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
IHO S-100 通用海道测量数据模型(Universal hydrographic data model)
3 术语和定义、缩略语
3. 1 术语和定义
下列术语和定义适用于本文件。
3. 1. 1
技术服务 technical service
一种经标准化数据采集、处理、生产和发布的,为航海相关利益者提供导助航和决策支持的数
据流。
3. 1. 2
服务接口 service interface
一个自动化系统与另一个自动化系统或人之间的共享边界。
3. 1. 3
服务操作 service operation
通过服务接口与服务进行编程通信的功能或过程。
3. 1. 4
操作节点 operational node
执行服务操作的逻辑实体。
3. 1. 5
消息交换模式 message exchange pattern
不同系统间进行交互和通信的方式。
3. 2 缩略语
下列缩略语适用于本文件。 JSON:JavaScript 对象简谱(JavaScript Object Notation) MCP:海上互联平台(Maritime Connectivity Platform) MEP:消息交换模式(Message Exchange Pattern) 1
JT / T 1505. 1—2024
MRN:海事资源名(Maritime Resource Name)
REST:表述性状态转移(Representational State Transfer)
UML:统一建模语言(Unified Modeling Language)
WSDL:网络服务规范语言(Web Service Definition Language)
XML:可扩展性标记语言(Extensible Mark-Up Language)
XSD:XML 模式定义(XML Schema Definition)
4 总体架构
4. 1 E 航海技术服务管理
E 航海技术服务(以下简称“技术服务”)通过技术服务注册系统进行统一维护和管理。 技术服务
注册系统应符合国际航标协会 MCP 管理模式和要求,见图 1。
图 1 技术服务运行与管理机制
技术服务管理的主要工作机制如下:
a) 服务规格编制者制定某种服务规格文件,并在技术服务注册系统中进行注册;
b) 服务技术设计者根据已发布的某种服务规格文件,通过特定技术开发实现和测试服务,编制
服务技术设计文件,并在技术服务注册系统中进行注册;
c) 服务提供者按照服务技术设计,发布实施技术服务,编制服务实例文件,并在技术服务注册系
统中进行注册;
d) 服务用户在技术服务注册系统中获取服务实例,并进行使用。
4. 2 技术服务规范文件编制框架与基本内容
4. 2. 1 技术服务规范文件由服务规格文件、服务技术设计文件和服务实例文件三个文件组成,文件编
制框架见图 2。
2
JT / T 1505. 1—2024
图 2 E 航海技术服务规范文件编制框架
4. 2. 2 服务规格文件应采用与技术无关的方式描述服务,规定下列基本内容:
———服务规格概述;
———服务标识;
———运行环境;
———服务概要;
———服务逻辑数据模型;
———服务接口规范;
———服务动态行为;
———服务提供(可选);
———参考文件。
4. 2. 3 服务技术设计文件应在技术层面描述服务的技术实现方式,规定下列基本内容:
———服务技术设计概述;
———服务技术设计标识;
———技术介绍;
———服务技术设计概要;
———服务物理数据模型;
———服务接口设计;
———服务动态行为;
———参考文件。
4. 2. 4 服务实例文件依据特定技术设计实现,能被不同的服务提供者部署在不同的位置。 对于每一
个服务实例都应在服务实例文件中进行描述,规定下列基本内容:
———服务实例概述;
———服务实例标识;
———服务实现和实例详情;
———发布公告;
———参考文件。
3
JT / T 1505. 1—2024
4. 3 技术服务规范文件编制模板
4. 3. 1 服务规格、服务技术设计和服务实例均应包含文档和 XML 两种规范文件描述方式。 XML 规范
文件应对文档中的内容进行结构化编码封装,便于技术服务的自动化数据处理,且应满足下列要求:
———基础数据类型 XSD 结构符合附录 A 的规定;
———服务规格 XSD 结构符合附录 B 的规定;
———服务技术设计 XSD 结构符合附录 C 的规定;
———服务实例 XSD 结构符合附录 D 的规定;
———服务规格文件模板符合附录 E 的规定;
———服务技术设计文件模板符合附录 F 的规定;
———服务实例文件模板符合附录 G 的规定。
4. 3. 2 服务规格文件应规定一个服务的基本用途、接口和服务逻辑数据模型等信息。 服务规格文件
的构成要素如下:
———服务规格文档;
———服务规格 XML 文件;
———服务逻辑数据模型:描述服务中数据模型的 XML 模式定义文件。 服务逻辑数据模型应包含在
服务规格中,并使用 < ! [CDATA[]] > 标签封装。
4. 3. 3 服务技术设计文件应说明一个服务的技术实现方法。 服务技术设计文件的构成要素如下:
———服务技术设计文档;
———服务技术设计 XML 文件;
———服务物理数据模型:服务物理数据模型应与服务规格中的服务逻辑数据模型相映射。 如有必
要,应提供数据模型映射表。
4. 3. 4 服务实例文件用于说明一个具体服务的实现和部署信息。 当多个服务实例实现同一个服务技
术设计时,多个服务实例可同时存在。 服务实例文件的构成要素如下:
———服务实例文档;
———服务实例 XML 文件;
———已部署实现的软件系统。
注:一个服务实现(同一个软件)可能在不同位置多次部署,应使用不同服务实例文件。
4. 4 相互关系
4. 4. 1 服务规格不应规定服务的具体实现,而应由服务技术设计说明。
4. 4. 2 对于同一个服务规格,可由不同的服务技术设计实现,编制多个服务技术设计文件。
4. 4. 3 对于同一个服务技术设计,可有多个服务实例,编制多个服务实例文件。
4. 5 技术服务注册系统
宜在国家或行业层面开发部署技术服务注册系统,对服务规格、服务技术设计、服务实例进行统一
组织管理,负责对系统中已注册的技术服务进行审核和发布。
4. 6 编制序列
4. 6. 1 服务规范的编制可采用“自上而下”和“自下而上”两种编制方式。
4. 6. 2 对于尚无实例的技术服务,应采用“自上而下”的编制方式,流程宜为:
a) 编制新服务的需求分析文档;
b) 编制新服务的服务规格文件,确定服务逻辑数据模型;
4
JT / T 1505. 1—2024
c) 服务规格注册; d) 编制服务技术设计文件; e) 服务软件系统开发,服务提供者和服务应用终端可同时开发; f) 服务技术设计注册; g) 编制服务实例文件; h) 发布服务实例; i) 服务实例注册。 4. 6. 3 对于完成实例开发和部署的技术服务,宜采用“自下而上”的编制方式,流程如下: a) 编制服务技术设计文件,确定服务物理数据模型; b) 编制服务实例文件; c) 对服务物理数据模型进行抽象化,转化为逻辑数据模型; d) 编制服务规格文件; e) 服务注册。
5 服务规格
5. 1 文档文件
5. 1. 1 服务规格概述
服务规格概述应包含服务和规范的基本信息,如文档的目的、适用范围、预期读者等。
5. 1. 2 服务标识
服务标识应采用表格形式描述服务的管理性信息,用于查找和识别服务,如服务规格的名称、标识
符、版本、编制人、关键字等。 服务标识符应是唯一的,应使用 MRN 进行标识。
5. 1. 3 运行环境
5. 1. 3. 1 运行环境应从运行角度描述特定服务在不同操作节点之间交互的方式。 运行环境应基于业
务域实际情况进行描述,包括操作活动和组织结构等。
5. 1. 3. 2 运行环境的编制宜选用以下方式之一:
a) 说明服务在不同操作节点间的交互的方式。 通常包括两个部分,即提供服务的操作节点和消
费服务的操作节点。
b) 说明服务在流程模型中支持哪些操作活动。
5. 1. 3. 3 运行环境应描述需求分析结果,包括业务/ 管理需求、信息交换需求、系统需求、功能和非功
能性需求。
5. 1. 3. 4 运行环境描述的原始资料应源于操作用户,并在特定的需求文档中进行说明。 如果没有需
求文档,那么应在服务规格文档中使用列表的方式描述基本的服务需求。
5. 1. 4 服务概要
5. 1. 4. 1 服务概要应定义服务主要元素的概述性信息,元素宜采用 UML 建模工具创建。
5. 1. 4. 2 服务概要主要构成元素包括:
———服务:即服务本体;
———服务接口:服务的通信机制,即服务提供者和消费者之间的交互机制。 通过将服务操作分配给
服务提供者或消费者进行接口定义;
5
JT / T 1505. 1—2024
———服务操作:描述访问服务的逻辑操作;
———参数定义:用于识别通过服务操作进行交换的数据结构。
5. 1. 4. 3 服务概要宜使用 UML 图进行描述,说明服务接口、服务操作以及分配到服务提供者和消费
者的具体情况,也可使用表格方式描述。
5. 1. 4. 4 当服务接口使用某个特定 MEP 时,应描述其原因。
5. 1. 4. 5 一个服务至少应提供一个服务接口,每一个服务接口均应进行结构化定义。
5. 1. 4. 6 服务接口支持一个或多个服务操作。 根据 MEP 的不同,服务操作可由服务提供者或消费者
实现,两者的区别应清晰直观。
5. 1. 5 服务逻辑数据模型
5. 1. 5. 1 服务逻辑数据模型应描述服务提供者和消费者之间数据交换的抽象数据结构,并应提供实
现该服务的充分信息。
5. 1. 5. 2 服务逻辑数据模型在描述数据结构时应采用抽象描述方法,不应列出所有的细节或定义与
技术相关的数据类型。
5. 1. 5. 3 宜使用 UML 等可视化建模工具绘制和表述数据结构。
5. 1. 5. 4 服务逻辑数据模型应由图和解释性的表格组成。 在每一个图后,应对每一个实体项(类)及
其属性以及每一个实体项之间的关系进行描述。
5. 1. 5. 5 如果服务逻辑数据模型与外部数据模型相关,那么服务逻辑数据模型应引用外部数据模型
的每个数据项。
5. 1. 5. 6 每一个服务逻辑数据模型的数据项都应与定义在外部数据模型中的数据项相对应。 这种映
射应添加在描述数据项、属性和关系的表中。
5. 1. 5. 7 如果服务重复使用了外部数据模型的结构,那么这些结构应在服务规格中进行引用,而不应
重复编制在服务规格中。
5. 1. 5. 8 服务逻辑数据模型的结构化定义应附于服务规格附录中。 结构化定义应使用 XSD 进行定
义。 XSD 在逻辑层提供正式的规范化描述,从而保证不同服务规格具有一致性的体例结构。
5. 1. 5. 9 如果 XSD 不适用,结构化定义也可使用其他文本格式进行描述。
注:基于 IHO S-100 的产品数据模型可直接作为结构化定义描述服务逻辑数据模型。
5. 1. 6 服务接口规范
5. 1. 6. 1 服务接口规范应定义每一个服务接口的具体信息。
5. 1. 6. 2 服务接口规范的主要构成元素包括:
———服务接口;
———服务操作:服务接口提供的具体功能或过程,如数据的查询、更新、删除等;
———参数:服务接口中具体服务操作的输入输出变量和常量。
5. 1. 6. 3 一个服务可以有一个或多个服务接口。 每一个接口都应划分为子条款进行描述,条款名称
应包含接口名称。
5. 1. 6. 4 应描述每一个服务接口的目的、MEP 和接口结构。
5. 1. 6. 5 服务接口可以支持一个或多个服务操作。 每一个服务操作都应划分子条款进行描述,条款
名称应包含操作名称。 每一个服务操作条款均应包含如下信息:
———功能:包含操作功能的文本描述,确保 UML 建模工具中的操作描述一致;
———参数:使用 UML 图(通常是服务逻辑数据模型的子集)和解释性的表格描述操作(载荷)的输
入和输出参数的逻辑数据模型。
5. 1. 6. 6 服务接口应使用解释性表格对每一个服务操作的参数进行说明,在服务逻辑数据模型中出
6
JT / T 1505. 1—2024
现的参数应清晰标出。
5. 1. 7 服务动态行为
5. 1. 7. 1 服务动态行为应描述服务接口之间的交换行为。 如有需要,也可描述不同服务(服务编排)
之间的交换行为。
5. 1. 7. 2 服务动态行为的主要构成元素包括:
———服务交换规范;
———服务状态机;
———服务编排。
5. 1. 7. 3 宜使用下列类型的 UML 图描述服务动态行为:
———序列图;
———交互图;
———状态机图。
5. 1. 7. 4 每一个服务接口都划分子条款进行描述,每一条款至少应包含服务接口动态特征,每一个服
务操作均应至少使用一个框图来表示。
5. 1. 8 服务提供(可选)
服务提供应描述服务提供和消费的方法和渠道。
注:服务提供是可选的,因为面向服务架构的关键点之一就是通过将服务规格和实现进行分离,从而确保整个系统
的灵活性。 也就是说,在进行服务设计的时候,设计人员无须了解服务最终的应用环境。
5. 1. 9 参考文件
应列出服务规格参考引用的文档列表(如需求文档、外部参考数据模型标准等)。
5. 2 XML 文件
5. 2. 1 基本结构
服务规格的 XML 编码结构应符合图 3 的规定。
5. 2. 2 服务规格的信息要素释义
5. 2. 2. 1 服务规格类 服务规格类释义见表 1。 表 1 服务规格类释义
类名称 描述
ServiceSpecification 服务规格 服务规格在逻辑层面以一种与技术无关的方式描述一个特定服务。 服务 规格通过 ID 和版本进行标识
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 服务规格名称
7
JT / T 1505. 1—2024
表 1(续)
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
2 id 标识符 ServiceIdentifier 服务标识符 服务规格标识符,在服务规格、服务 技术设计和服务实例中对服务进行全 球唯一标识
3 version 版本 ServiceVersion 服务版本 服务规格版本,在服务规格、服务技 术设计和服务实例中标明服务版本号
4 status 状态 ServiceStatus 服务状态 服务规格状态。 状态枚举值包括临 时、发布、弃用和删除四种状态
5 description 描述 CharacterString 字符串 服务简要介绍,提供实现服务的摘 要性信息
6 keywords 关键字 CharacterString 字符串 关键词,与服务相关的关键词
7 isSpatial Exclusive 是否空间 限制 Boolean 布尔 是否空间限制,用于指示服务规格、 服务技术设计和服务实例是否仅适用 于特定地理范围
8 requirements 需求 Requirement 需求 服务需求,参考引用的业务需求、功 能和非功能需求
9 authorInfos 作者信息 AuthorInfo 作者信息 编制人。 服务规格编制人信息,强 制元素
10 serviceInterfaces 服务接口 ServiceInterface 服务接口 服务接口定义
11 service DataModel 服务数据 模型 ServiceDataModel 服务数据模型 服务逻辑数据模型定义
8
JT / T 1505. 1—2024
图 3 服务规格描述的 XML 编码结构
5. 2. 2. 2 需求类
需求类释义见表 2。
表 2 需求类释义
类名称 描述
Requirement 需求 服务需要满足的需求
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 id 标识符 CharacterString 字符串 需求标识符
2 name 名称 CharacterString 字符串 需求名称/ 摘要
3 text 描述文本 CharacterString 字符串 需求描述信息
4 rationale 需求缘由 CharacterString 字符串 需求缘由。 使用文本描述需求存在 的原因,提供有关背景信息
5 reference 引用 CharacterString 字符串 需求引用文件。 当存在服务需求文 档时,在此处进行引用
6 author 作者信息 AuthorInfo 作者信息 需求文档编制人
9
JT / T 1505. 1—2024
5. 2. 2. 3 作者信息类
作者信息类释义见表 3。
表 3 作者信息类释义
类名称 描述
AuthorInfo 作者信息 服务规格或需求文件的编制人信息
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 id 标识符 CharacterString 字符串 编制人唯一标识符
2 name 名称 CharacterString 字符串 编制人名称(个人或单位)
3 description 描述 CharacterString 字符串 编制人基本介绍
4 contactInfo 联系方式 CharacterString 字符串 编制人联系方式
5 organizationId 组织标识符 CharacterString 字符串 编制人所在单位标识符
5. 2. 2. 4 服务接口类 服务接口类释义见表 4。 表 4 服务接口类释义
类名称 描述
ServiceInterface 服务接口 服务接口规范。 一个服务可以包含多个接口,例如,请求/ 响应和发布/ 订 阅接口可以在同一规范中。 不同接口通常提供不同的服务操作
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 服务接口名称
2 description 描述 CharacterString 字符串 服务接口介绍
3 dataExchange Pattern 数据交换 模式 ExchangePattern 交换模式 数据交换模式。 枚举值包括单向、 请求响应、请求回调、发布订阅和广播
4 operations 操作 Operation 操作 服务操作。 服务接口支持的服务操 作,一个 接 口 中 至 少 包 含 一 个 服 务 操作
5 consumerInterface 用户接口 ConsumerInterface 用户接口 消费者接口。 参考引用需要提供的 消费者接口
5. 2. 2. 5 用户接口类
用户接口类释义见表 5。
1
0
JT / T 1505. 1—2024
表 5 用户接口类释义
类名称 描述
ConsumerInterface 用户接口 接口规范由服务消费者提供
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 接口名称
2 description 描述 CharacterString 字符串 接口简要说明
3 operations 操作 Operation 操作 接口支持的服务操作。 一个接口中 至少包含一个服务操作
5. 2. 2. 6 操作类 操作类释义见表 6。 表 6 操作类释义
类名称 描述
Operation 操作 服务操作定义。 服务操作允许服务消费者与服务进行交互。 服务操作描 述服务的特定功能
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 服务操作名
2 description 描述 CharacterString 字符串 服务操作简要介绍
3 returnValueType 返回值类型 ValueTypeData ModelMapping 值类型与数据 类型映射 服务操作的返回值。 可选项,返回 值可以是业务对象或简单状态码。 返 回值数据类型必须在服务逻辑数据模 型中定义
4 parameterTypes 参数类型 ValueTypeData ModelMapping 值类型与数据 类型映射 服务操作的参数定义。 参数可以是 业务对象或简单类型。 参数必须在服 务逻辑数据模型中定义
5. 2. 2. 7 值类型与数据模型映射类
值类型与数据模型映射类释义见表 7。
1
1
JT / T 1505. 1—2024
表 7 值类型与数据模型映射类释义
类名称 描述
ValueTypeDataModelMapping 值类型与数据模型映射 在服务逻辑数据模型中定义的数据类型。 值类型与数据模型映射用于服 务操作参数或返回值
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 typeReference 类型引用 CharacterString 字符串 服务逻辑数据模型引用。 通过服务 逻辑数据模型中数据类名称进行引用, 仅当非 S-100 兼容数据类型时使用
2 parameter 参数 S100_Parameter S100 参数 对 S-100 属性的引用
3 multiplicity 多重性 S100_Multiplicity S100 多重性 多重性。 提供实例的最小和最大数 量,其中最大数量可以是无限大。 默 认值为 1
4 direction 方向 DirectionKind 方向类型 参数方向。 枚举值包括输入、输出、 输入输出
5 encoding 编码 CharacterString 字符串 参数编码
5. 2. 2. 8 服务数据模型类
服务数据模型类释义见表 8。
表 8 服务数据模型类释义
类名称 描述
ServiceDataModel 服务数据模型 如果服务遵循 S-100 标准,在 featureCatalogue 元素中对现有 S-100 要素目 录进行引用,并省略其他要素。 如果服务不遵循 S-100,服务逻辑数据模型 在子元素 modelDefinition 中描述。 编码使用子元素 encoding 说明。 一个服 务规格仅包含一个服务逻辑数据模型
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 featureCatalogue 要素目录 S100_FC_Feature Catalogue S100 要素目录 S-100 逻辑数据模型的引用。 仅当 遵循 S-100 时使用,否则在 modelDefi- nition 中定义模型
2 modelDefinition 模型定义 CharacterString 字符串 模 型 定 义。 仅 当 不 遵 循 S-100 时 使用
3 encoding 编码 CharacterString 字符串 模 型 编 码。 仅 当 不 遵 循 S-100 时 使用。 为了兼容 S-100,引用 S-100 规范附 录 4a-D 中描述的数据格式
1
2
JT / T 1505. 1—2024
6 服务技术设计
6. 1 文档文件
6. 1. 1 服务技术设计概述
服务技术设计概述包含服务技术设计的基本信息,例如文档的目的和预期读者等。
6. 1. 2 服务技术设计标识
服务技术设计标识提供用于查找服务技术设计的相关管理性信息,例如对服务规格的引用、技术设
计的名称、标识符和版本、编制人、关键字等。
6. 1. 3 技术介绍
技术介绍主要描述所选技术的基本背景和相关技术摘要信息,宜使用少量文字描述技术的基本特
点,以及相应的标准参考文档和最佳实践描述等信息。
6. 1. 4 服务技术设计概要
6. 1. 4. 1 服务技术设计概要的目标是提供服务技术设计中主要元素的概览图,以及与服务规格元素
映射的设计元素。 设计元素宜使用 UML 建模工具完成。
6. 1. 4. 2 服务技术设计概要的主要构成元素包括:
———服务:即代表服务本体;
———服务接口:服务的通信机制,即服务提供者和消费者之间的交互机制。 通过将服务操作分配给
服务提供者或消费者进行接口定义;
———服务操作:描述访问服务的操作;
———参数定义:用于识别通过服务操作进行交换的数据结构。
6. 1. 4. 3 如果服务技术设计与服务规格基本一致,则不需要在服务技术设计中重复绘制相同的图表,
应直接引用。
6. 1. 4. 4 服务技术设计概要宜使用 UML 图进行描述,说明服务操作接口以及分配到服务提供者和消
费者的具体情况。 该信息也可以使用表格方式描述。
6. 1. 4. 5 应说明 MEP 在所选技术下的实现方法。
6. 1. 5 服务物理数据模型
6. 1. 5. 1 服务物理数据模型提供服务提供者和消费者之间交换的数据结构和具体信息,同时应包含 物理数据结构与服务规格中服务逻辑数据模型的映射关系。 6. 1. 5. 2 服务物理数据模型允许的表述方式包括: ———UML 类图; ———XML / XSD、JSON; ———表格。 6. 1. 5. 3 为了确保描述清晰易读,可综合选取上述多种表述方式。 遵循 S-100 的规范应引用数据集发 现元数据,从而与 S-100 产品规范和兼容数据格式建立链接。 6. 1. 5. 4 如果服务物理数据模型与外部数据模型相关,那么该部分应对其进行引用。 每一个服务物 理数据模型的数据项都应与定义在外部数据模型的数据项相对应。 这种对应关系应一同在描述数据 项、属性和关系的表格中进行说明。 1 3
JT / T 1505. 1—2024
6. 1. 6 服务接口设计
服务接口设计的结构应符合 5. 1. 6 的规定。 若满足以下条件,应直接引用服务规格文档:
———服务接口设计与服务接口规范是 1 ∶ 1 的关系;
———服务接口在服务规格(服务接口规范)中已充分描述;
———服务物理数据模型包含了所有服务规格中所有载荷数据项与具体物理数据项之间的无歧义映
射关系。
6. 1. 7 服务动态行为
6. 1. 7. 1 服务动态行为描述服务接口之间的交换行为。 若有需要,也可描述不同服务之间的交换 行为。 6. 1. 7. 2 宜使用下列类型的框图描述服务动态行为: ———序列图; ———交互图; ———状态机图。 6. 1. 7. 3 每一个服务接口都划分子条款进行描述。 每一条款至少应包含服务接口动态特征,每一个 服务操作均应至少使用一个框图来表示。 6. 1. 7. 4 如果服务接口和操作与服务规格中的相同,并且动态行为在服务规格中已经充分描述,则该 部分可直接引用服务规格文档。
6. 1. 8 参考文件
应列出参考引用的文档列表,其中应引用对应的服务规格。
6. 2 XML 文件
6. 2. 1 基本结构
服务技术设计 XML 文件编码结构应符合图 4 的规定。
1 4 图 4 服务技术设计描述的 XML 编码结构
JT / T 1505. 1—2024
6. 2. 2 服务技术设计的信息要素释义
6. 2. 2. 1 服务技术设计类
服务技术设计类释义见表 9。
表 9 服务技术设计类释义
类名称 描述
ServiceDesign 服务技术设计 特定服务规格的技术设计
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 服务技术设计名称。 服务技术设计 新版本不应改变名称
2 id 标识符 ServiceIdentifier 服务标识符 服务技术设计标识符。 服务标识符 在服务规格、服务技术设计和服务实 例中对服务进行全球唯一标识
3 version 版本 ServiceVersion 服务版本 服务技术设计版本。 服务版本在服 务规格、服务技术设计和服务实例中 标明服务版本号。 当服务物理数据模型或服务接口定 义修改时,发布服务技术设计新版本
4 status 状态 ServiceStatus 服务状态 服务技术设计状态。 状态枚举值 包括: ———provisional(临时) ———released(发布) ———deprecated(弃用) ———deleted(删除)
5 description 描述 CharacterString 字符串 服务技术设计简要介绍。 包含关于 实现服务的摘要性信息
6 designsServiceSp- ecifications 服务规格 引用 ServiceSpecification Reference 服务规格引用 服务规格引用。 至少引用一个服务 规格,一个服务技术设计可以实现多 个服务规格(或同一规范的不同版本)
7 offersTransport 提供传输 Transport 传输 传输技术引用。 至少引用一个传输 技术
8 designedBy 由……设计 VendorInfo 编制人信息 服务技术设计编制人。 强制元素
9 servicePhysical DataModel 服务物理 数据模型 ServicePhysical DataModel 服务物理 数据模型 服务物理数据模型引用。 强制元素
1
5
JT / T 1505. 1—2024
6. 2. 2. 2 服务规格引用类
服务规格引用类释义见表 10。
表 10 服务规格引用类释义
类名称 描述
ServiceSpecificationReference 服务规格引用 服务技术设计实现的服务规格。 通过 id 和版本标识服务规格
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 id 标识符 ServiceIdentifier 服务标识符 引用的服务规格标识符
2 version 版本 ServiceVersion 服务版本 引用的服务规格版本
6. 2. 2. 3 传输类 传输类释义见表 11。 表 11 传输类释义
类名称 描述
Transport 传输 服务技术设计使用的传输协议的定义
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 人工可读的名称
2 description 描述 CharacterString 字符串 服务技术设计使用的传输协议的人 工可读描述
3 protocol 协议 CharacterString 字符串 传输的非正式字符串表示形式(例 如 http/ rest、http/ soap…),它为服务使 用者提供足够的信息,以便能够连接
6. 2. 2. 4 责任人信息类
责任人信息类释义见表 12。
表 12 责任人信息类释义
类名称 描述
VendorInfo 责任人信息 提供服务技术设计的编制个人或单位
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 id 标识符 CharacterString 字符串 编制人唯一标识符
2 name 名称 CharacterString 字符串 编制人名称(个人或单位)
3 description 描述 CharacterString 字符串 编制人基本介绍
4 contactInfo 联系方式 CharacterString 字符串 编制人联系方式
5 organizationId 组织标识符 CharacterString 字符串 编制人所在单位标识符
6 isCommercial 是否商用 Boolean 布尔 是否为用于商业目的
1
6
JT / T 1505. 1—2024
6. 2. 2. 5 服务物理数据模型类
服务物理数据模型类释义见表 13。
表 13 服务物理数据模型类释义
类名称 描述
ServicePhysicalDataModel 服务物理数据模型 服务物理数据模型描述服务技术设计所使用的数据结构。 服务物理数据 模型详细定义了服务消费者与服务进行消息交换过程中的数据的结构
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 模型名称
2 description 描述 CharacterString 字符串 模型简要介绍
3 model 模型 CharacterString 字符串 模型。 模型应选用成熟的数据结构 描述格式,如 WSDL、JSON 等。 可以 将模型封装列 入 XSD 的 CDATA 部 分,并提供足够的关于处理数据模型 的信息
4 modelType 模型类型 CharacterString 字符串 模型类型。 包含关于模型涉及的技 术缩略语,如 WSDL、JSON 等
7 服务实例
7. 1 文档文件
7. 1. 1 服务实例概述
服务实例概述应定义服务实例的基本信息,例如文档目的、预期读者等。
7. 1. 2 服务实例标识
服务实例标识应规定用于查找服务实例的相关管理性信息,如对服务技术设计的引用、实例名称、
标识符、版本、编制人(服务提供者)、关键字等。
7. 1. 3 服务实现和实例详情
服务实现和实例详情提供有关对理解服务实现有帮助的所有信息,如内部设计决策、需要配置的数
据、部署先决条件、服务组合、内部服务结构等。
注:服务实例描述文档模板不规定服务实现和实例详情的具体格式,由编制人选取适当的格式。
7. 1. 4 发布公告
发布公告描述服务实例的发布信息,应至少包含如下信息: 1 7
JT / T 1505. 1—2024
———发布标识和日期;
———功能列表,增加的功能,改变的功能,删除的功能;
———错误列表,已知的公开错误,已解决的错误。
注:服务实例描述文档模板不规定发布公告的具体格式,由编制人选取适当的格式。
7. 1. 5 参考文件
引用文件应列出服务实例描述文档参考引用的文档,至少应引用对应的服务规格和服务技术设计
描述文档。
7. 2 XML 文件
7. 2. 1 基本结构
服务实例 XML 文件编码结构应符合图 5 的规定。
图 5 服务实例描述的 XML 编码结构
7. 2. 2 服务实例的信息要素释义
7. 2. 2. 1 服务实例类
服务实例类释义见表 14。
1
8
JT / T 1505. 1—2024
表 14 服务实例类释义
类名称 描述
ServiceInstance 服务实例 服务实例描述。 一个服务可以在多个地点由相同或不同的服务提供者部 署。 每一个部署均代表一个不同的服务实例
序号 元素名称 (英) 元素名称 (中) 数据类型 (英) 数据类型 (中) 释义
1 name 名称 CharacterString 字符串 服务实例名称