基于REST架构的海事信息系统模型研究
杜殿虎
摘 要：为了解决当前海事信息系统架构内部逻辑耦合度较高、技术平台间通用性较低、不利于系统升级改造和第三方集成等问题，提出了一种基于REST架构的新型海事信息系统设计研发模型。打破了传统的基于JavaEE技术的信息系统MVC开发模式，在系统集成、数据整合、信息共享、网络服务发布、平台兼容性等方面表现出诸多优势，从业务管理信息系统的角度进一步消除海事信息化领域的信息“孤岛”现象。
关键词：海事信息系统；REST架构；系统集成
中图分类号：U665.2 文献标识码：A 文章编号：1006—7973（2018）1-0044-04
MVC信息系统研发模型从上世纪七十年代问世到如今的四十多年间被很多信息系统所采用，而基于J2EE的Spring mvc、Struts等MVC研发框架在当前海事信息系统研发中具有很强的影响力。MVC 模型即Model-View-Controller模型，它包括称为模型、视图和控制器的三个组成部分，基于其设计模式产生的逻辑框架在信息系统项目设计研发中较其他模式表现出一定的技术优势。
MVC模式也慢慢地表现出其明显的不足和设计逻辑缺陷，主要表现在：①任何一个网络服务请求的发起到最终得到相关业务数据并在页面上进行逻辑展示，都要严格遵从模型、控制器、视图这个MVC设计模式规定的业务处理流程，操作过程较为复杂、模块间交互繁琐、每个模块之间功能可能存在重复。②设计模式对数据模型的耦合度较高导致其必须首先通过生成相关数据源的对象实体，才可以根据相关依赖性操作来实现业务信息的逻辑处理和数据计算。③每一次客户端的请求所需展现的代码都需要服务器端进行处理并渲染后返回给前端，客户端和服务器端分工设计不够合理导致服务器端的工作强度压力较高，也降低了网络传输效率和对前端展示技术的兼容性。
1 REST架构
综上所述，当前海事业务管理信息系统所面临的诸多问题核心主要包括：传统MVC工程研发设计模式的处理逻辑分工不明确，引发整体业务处理流程过于冗余，前端显示和后端处理结合在一起导致彼此模块间耦合度较高。
那么应该尝试一种更好的研发方式或设计模式，能够将紧耦合的整体工程进行切分使之彼此分离，前端只关注展现，后端只关注业务逻辑。而基于REST风格的研发框架为基于前后端分离的设计思想付诸实践提供了很好的借鉴和技术支撑，因此决定采用REST框架实现前后端即静态展现和动态逻辑的隔离。
REST一般称表述性状态传递是一种松耦合的逻辑设计风格，其关键核心是对资源的表示和获取，该架构注重将资源使用统一资源标识符URI来唯一进行表示。REST是在现有的网络服务技术体系基础上，加强约束和相关应用规范以增强逻辑架构可扩展能力。基于REST风格的设计架构整体分为前端和后端两个部分，前后端的交互过程可以概括地用图1进行描述：
如图可以看出，前端和后端进行了分离，由紧耦合的单工程应用分为逻辑清晰的前端应用和后端应用。前端关注用户展现，后端关注业务逻辑，前后端的信息交互通过Web服务请求和序列化的格式数据来实现。
REST架构遵从的设计原则核心主要包括：工程中所有应用服务资源都需进行统一定位标识，展现端即前端与业务端即后端的交互采用无序的数据传递，前端发起任何一个网络服务请求应携带发起者客户端的全部数据，对数据量较大的信息交互前端应该提供缓存机制以优化整体操作性能，对前端的任何请求后端只负责响应而不负责回溯，后端的体系架构变动不会对前端的业务展现造成任何影响，前端在分布式情况下发起的网络服务请求可以被任何一台处于工作中的后端服务器响应。REST关键核心内容可以用图2进行表示：
2 逻辑模型
基于前端应用和后端处理逻辑彼此分离的行为模式，设计出基于REST架构的海事信息系统的逻辑模型，如图3所示：
基于REST架构的逻辑模型打破了传统基于JavaEE的MVC固有研发框架，设计模式更加清晰。整个逻辑模型采用B/S架构，对海事应用系统用户层面来说是透明的，用户只要根据自身需求在客户端进行界面操作即可，不用去关注任何业务逻辑和技术实现细节。
模型进一步降低了前后端的耦合程度，前端应用负责对页面进行组织并进行用户工作台综合展示，后端应用只关注海事业务实现并返回指定格式的序列化结果集。采用前后端逻辑分离的工程体系，也使得信息系统项目研发工作分工更加明确，也有利于提升代码编写人员的技术专一性，使得工程设计研发效率大幅度提升。
基于REST框架的前后端分离模型具有更好的平台兼容性，后端不必考虑前端使用何种展现技术，前端则适用于任何后端高级研发语言和逻辑体系架构。
2.1网络服务端
網络服务端即逻辑后端负责与数据源的交互，针对前端的网络服务请求对应访问相关数据源获取可操作数据，并对生成的可识别模型类对象进行逻辑操作反馈给业务展现端。从整体上来说，网络服务端主要包括访问权限管理OAM、Session Manager管理器、业务逻辑处理、对象解析器、序列化数据生成器等诸多细分模块，下面对该部分的关键核心模块进行解析。
访问权限管理OAM是整个网络服务端的接入控制器，负责与业务展现端进行数据对接和网络交互，其响应业务展现端发送的Web Service请求和异步刷新服务。访问权限管理OAM对接入的普通http请求和ajax请求进行合法性认证，通过其内置的认证服务中心对接收的客户端请求数据进行验证，并针对不同前端环境发放对应的通行证Ticket已标志其是否正常登录。该模块针对前端的校验技术应提供绝对安全的接入手段，目前主要包括不可逆加密型账号密码方式和全球唯一性数字证书加密服务两种类型。针对正常合法的网络服务资源请求，访问权限管理OAM采取放行策略并反馈其需求的后端资源。针对未实现前端账号登录或数字认证的用户接入和网络请求，访问权限管理OAM实行自定义拦截，拒绝提供其定位的静态资源或数据获取服务并强制进入登录转接页面。
Session Manager管理器用于保持当前合法性用户的服务时效，并且集中在网络服务端存储用户的公共数据和全局性信息。基于自定义可插拔的扩展思路，通过灵活配置实现Session信息的按需个性定制和增删服务。通常情况下的模式会话中，保存的用户信息主要涉及登录信息、权限认证、个人资料、功能操作定义、会话保持时间等内容。该模块的功能，由网络服务端应用程序和服务器servlet容器共同实现。
业务逻辑处理模块是网络服务端负责数据获取操作和结构组织的环节。通过应用封装的JDBC服务和数据库访问技术，获取包括关系型或非关系型的格式化数据，并针对结果集合进行代码处理实现数据持久化操作。该模块侧重于业务逻辑的实现，针对前端网络请求需求的不同，业务逻辑处理模块进行不同数据库访问的逻辑拼接和合法性校验。针对不同的前端操作需求，设置逻辑判断进行筛选并对应分配，对静态数据的访问直接通过服务器进行HTML文档的定位并进行反馈，而针对包含业务数据的动态信息则需要经过流程化的数据拼接和转换处理。
对象解析器模块是网络服务端进行批量数据处理的通用性构件，主要实现模型类数据到结构数据的变换和解析，以方便后面环节进行数据拼接和最终序列化数据的生成。该模块被架构赋予了较高的通用性和封装性，便于工程迁移装载和模块间的组合调用，也易于项目的后期升级改造和第三方集成扩展，避免工程的业务需求变动对核心代码层的不利影响。对象解析器模块对多种已有对象类型具有较强的兼容性和适用性，并且注重大规模格式数据的批量转换效率。对象解析器的最终输出结果之所以是通用的结构数据，是为了在基于现有的序列化技术的基础上最大程度上避免代码重构，使得平台架构拥有更好的兼容性和逻辑扩展能力。
序列化数据生成器是针对业务展现端的网路服务请求进行数据反馈的功能模块，负责将对象解析器构造的通用结构数据进行序列化。对请求的响应主体数据执行序列化这一环节，是基于REST框架的前后端分离体系和传统的MVC设计模式比较明显的不同之处。基于REST架构的网络服务器端对数据的序列化需要遵循一定的通用格式，以方便前端即业务展现端进行综合信息展示和统计分析，目前序列化的数据主要包括XML和JSON两种主流格式，基于REST架构的后端逻辑框架采用JSON格式的序列化数据。JSON格式是一种比较轻量级的信息传输和交互格式，相对于XML表现出数据格式规则简单、便于接收端进行数据解析、后端研发语言兼容性好、传输速度更快、网络带宽占用更小等诸多优势。
2.2业务展现端
业务展现端是基于REST架构的信息系统体系模型的前端工程，负责接受用户业务需求和逻辑操作并与后端进行网路服务交互，对用户尝试获取的最终数据信息进行综合界面展示和终端样式规格适配。业务展现端是用户通过与其所在机器不同规格浏览器直接接触并进行相关指令发送从而达到海事业务需求表达目标的模块，该模块同样关注UI设计和文档样式适配，表现出用户交互度高、浏览器技术格式多样话、客户端操作环境各异等特点。从整体上来看，业务展现端主要包括高度集约化的格式化前端装载器、Code Generate生成器、Code Resolver解析器等核心组成模块。
格式化前端装载器模块是一个将后端模板化的文档型数据进行格式化转换的工具集，其针对网络服务端的固化文档片段进行格式分析和完整性拼接，并最终生成固定格式的静态文档进行业务展现端的解析载入。在服务器端固定位置存储的文档型数据会被提前模板化并赋予一定的展现规则，其经过流程处理最终会被网络服务端的业务逻辑处理模块经过判断逻辑核心过滤进行定位。基于业务展现端不同用户的差异性接入处理需求，网络服务器端会准备原始的展示文档供格式化前端装载器进行配置载入以降低前端文档技术操作的实现复杂度。基于海事领域业务逻辑的分散性和数据统计展现分析需求的不确定性，一个业务展现端的用户操作请求期待获取的最终格式数据可能存在于多个文档型数据中，因此格式化前端装载器支持带有独立业务展现逻辑的片段性文档的组合拼接转换。
Code Generate生成器是对网络服务端经过信息序列化后的主要关键性动态业务数据进行处理的主要模块，通过综合运用异步操作为核心的前后端网络请求交互技术负责对用户不同功能性需求进行实时响应和操作逻辑界面的异步刷新。基于REST架构的访问端和服务端分离的逻辑架构规则，避免了客户端请求提交导致的网络服务重定向和操作界面的整体重新加载带来的不友好UI人机体验。业务展现端基于局部响应式的用户操作异步刷新服务的设计实现，对网络服务端远程传送的序列化规则数据表现出高度的技术兼容性和数据可操作性，便于业务展现端对整体的原始业务数据采取进一步加工处理和基于展示需要的后期格式改造。Code Generate通过支持对框架自定义外部插件的工程配置实现个性化可插拔式加载流程，方便于技术研发人员对第三方控件和软件中间部件的独立扩展，降低后期用户需求变更和业务功能优化升级而引发的系统间功能整合和数据集成给工程带来的改造难度。通过對由Web Service远程接口调用获取的网络服务端传递来的参数数据的不同类型进行区分甄别，通过Code Generate生成器的归类模块切分为增量替代数据和批量原生初始化载入数据。相对于基于JavaEE的传统MVC研发模型的前后端数据传递和交互显示方式，Code Generate生成器采用基于VUE前端渲染技术进行后期封装的参数传递模式，用于对网络服务端传来的用于业务逻辑展现的参数类序列化数据进行定位适配和视图界面显示。Code Generate生成器通过综合运用jQuery、跨域Ajax等前端操作交互技术和amaze等UI展示框架对用户当前的Doument模型进行操作，产生满足特定业务展现需要的格式化静态文档供后面模块进行解析并最终呈现给浏览器内核进行基于不同需求的用户访问的最终展现。
Code Resolver解析器是与浏览器内核代码解析器进行交互的前端代码分解模块，负责将格式化静态文档中封装的中间层代码进行解析生成最终可用代码供浏览器内核进行装载运行和终端业务显示。基于REST框架的前后端分离逻辑架构提供多种格式的中间件和页面控件的代码解析，支持非启动式配置文件的方式进行工程载入便于技术研发人员根据需要进行扩展，并在脚本文件中将相关控件功能进行模块化以支持通过二次研发实现定制化的功能需求。
3 系统体系架构
按照逻辑模型设计出的基于REST架构的海事信息系统体系架构如上图所示，整体上看主要采用五层体系架构，包括接入层、展现层、业务应用层、数据层和支撑层。
接入层：通过给用户进行角色授权，实现系统登录和业务操作。该层是与用户直接进行对接的最高级层次，整个体系架构从用户角度来看是全透明的，用户只需要对该层提供输入条件和需求，而无需考虑任何架构模块细节和技术实现逻辑。接入层负责用户登录逻辑的判断、系统权限的分配和载入、基于特定需求的业务办理操作等。
展现层：在浏览器端对获取的数据进行全方位多角度的表现和展示。展现层负责将基于需求的业务操作进行功能模块化，并提供用户相关功能的操作菜单和访问入口。该层次的常用功能模块可以包括信息管理、统计分析、报表展现、电子海图、船舶动态等。
业务应用层：集中处理业务逻辑，并将数据进行序列化以向前端进行传输。业务应用层针对数据处理逻辑可以划分为多个模块，主要包括船舶数据信息处理发布业务模块、船员数据信息处理发布业务模块、从业企业信息处理发布业务模块、管理机构信息处理发布业务模块、船检数据信息处理发布业务模块、访问授权及身份认证服务模块等。
数据层：实现业务数据的格式化，并进行高效存储和管理。该层是基于REST架构的海事信息系统信息处理的数据源头，主要维护的数据包括海事业务领域相关的企业信息、船舶信息、船员信息、机构信息等。数据层也可以根据今后海事信息系统业务升级的需要，通过信息整合和数据迁移的方式获取其他业务系统的相关数据。
支撑层：为系统运行提供物理设备和软件中间件支持。支撑层是基于REST架构的海事信息系统体系架构的最底层，为上层的各项服务提供软硬件支撑，以满足用户对功能、性能、操作等多方面的需求。特别是当前数据日趋集约化的信息时代大背景下，海事领域的各方面业务数据量日益庞大，而海事从业管理人员和相关业务办理用户对数据的快速一致性获取需求不断增长，这就对支撑层如何提供更好的存储服务、操作性能、高效展现等多方面提出了更高的要求。
4 结论
通过综合分析并总结当前阶段信息系统在设计模式和逻辑架构中面临的诸多问题，并在对REST架构进行深入研究的基础上，融合海事领域信息提出了一种基于REST架构的海事信息系统逻辑模型和体系架构。该模型打破了当前传统的基于JavaEE的MVC设计和研发模式并解决了该模式存在的诸多缺陷，基于REST架构的海事信息系统模型架构兼具前后端耦合度低、功能可扩展性强、逻辑分工明确、系统升级改造难度小、个性化定制便利等诸多特点。该研究立足当前海事信息系统需求更新快、对工程集成改造便利性要求迫切等领域信息化发展形势，有利于增强系统研发人员的技术专业性和提升各系统间的协同办公能力，对当前简政放权背景下凸显海事领域职能部门的社会服务属性具有积极推动作用，使海事信息化工作在设计研发模型上朝着高效、便利、健康的方向发展。
参考文献：
[1]何红，步红，崔越，周一航. “引航家”国产智慧船舶交通管理系统——无纸化电子值班与交班[J]. 中国海事，2017，（07）：35-36.
[2]任中方， 张华， 闫明松，等. MVC模式研究的综述[J]. 计算机应用研究， 2004， 21（10）：1-4.
[3]劉小龙， 陈岚， 李莹，等. 基于REST的园区数据管理系统的研究[J]. 计算机工程与应用， 2017， 53（18）：208-212.
[4]孙祖汉， 李莹， 罗智凌，等. 可视化REST服务组合框架的设计与实现[J]. 小型微型计算机系统， 2017， 38（1）：10-14.
[5]王进， 黄志球. 面向超媒体链接的RESTful服务隐私建模方法[J]. 计算机研究与发展， 2017， 54（4）：886-905.
[6]杨凤攀. 基于SOA架构的智能终端云服务平台设计与实现[D]. 吉林大学， 2017.
[7]仇小花，秦栓栓，邱果. 基于WEB开发中的XML与JSON数据传输格式研究[J]. 信息技术与信息化，2017，（04）：123-125.
摘 要：为了解决当前海事信息系统架构内部逻辑耦合度较高、技术平台间通用性较低、不利于系统升级改造和第三方集成等问题，提出了一种基于REST架构的新型海事信息系统设计研发模型。打破了传统的基于JavaEE技术的信息系统MVC开发模式，在系统集成、数据整合、信息共享、网络服务发布、平台兼容性等方面表现出诸多优势，从业务管理信息系统的角度进一步消除海事信息化领域的信息“孤岛”现象。
关键词：海事信息系统；REST架构；系统集成
中图分类号：U665.2 文献标识码：A 文章编号：1006—7973（2018）1-0044-04
MVC信息系统研发模型从上世纪七十年代问世到如今的四十多年间被很多信息系统所采用，而基于J2EE的Spring mvc、Struts等MVC研发框架在当前海事信息系统研发中具有很强的影响力。MVC 模型即Model-View-Controller模型，它包括称为模型、视图和控制器的三个组成部分，基于其设计模式产生的逻辑框架在信息系统项目设计研发中较其他模式表现出一定的技术优势。
MVC模式也慢慢地表现出其明显的不足和设计逻辑缺陷，主要表现在：①任何一个网络服务请求的发起到最终得到相关业务数据并在页面上进行逻辑展示，都要严格遵从模型、控制器、视图这个MVC设计模式规定的业务处理流程，操作过程较为复杂、模块间交互繁琐、每个模块之间功能可能存在重复。②设计模式对数据模型的耦合度较高导致其必须首先通过生成相关数据源的对象实体，才可以根据相关依赖性操作来实现业务信息的逻辑处理和数据计算。③每一次客户端的请求所需展现的代码都需要服务器端进行处理并渲染后返回给前端，客户端和服务器端分工设计不够合理导致服务器端的工作强度压力较高，也降低了网络传输效率和对前端展示技术的兼容性。
1 REST架构
综上所述，当前海事业务管理信息系统所面临的诸多问题核心主要包括：传统MVC工程研发设计模式的处理逻辑分工不明确，引发整体业务处理流程过于冗余，前端显示和后端处理结合在一起导致彼此模块间耦合度较高。
那么应该尝试一种更好的研发方式或设计模式，能够将紧耦合的整体工程进行切分使之彼此分离，前端只关注展现，后端只关注业务逻辑。而基于REST风格的研发框架为基于前后端分离的设计思想付诸实践提供了很好的借鉴和技术支撑，因此决定采用REST框架实现前后端即静态展现和动态逻辑的隔离。
REST一般称表述性状态传递是一种松耦合的逻辑设计风格，其关键核心是对资源的表示和获取，该架构注重将资源使用统一资源标识符URI来唯一进行表示。REST是在现有的网络服务技术体系基础上，加强约束和相关应用规范以增强逻辑架构可扩展能力。基于REST风格的设计架构整体分为前端和后端两个部分，前后端的交互过程可以概括地用图1进行描述：
如图可以看出，前端和后端进行了分离，由紧耦合的单工程应用分为逻辑清晰的前端应用和后端应用。前端关注用户展现，后端关注业务逻辑，前后端的信息交互通过Web服务请求和序列化的格式数据来实现。
REST架构遵从的设计原则核心主要包括：工程中所有应用服务资源都需进行统一定位标识，展现端即前端与业务端即后端的交互采用无序的数据传递，前端发起任何一个网络服务请求应携带发起者客户端的全部数据，对数据量较大的信息交互前端应该提供缓存机制以优化整体操作性能，对前端的任何请求后端只负责响应而不负责回溯，后端的体系架构变动不会对前端的业务展现造成任何影响，前端在分布式情况下发起的网络服务请求可以被任何一台处于工作中的后端服务器响应。REST关键核心内容可以用图2进行表示：
2 逻辑模型
基于前端应用和后端处理逻辑彼此分离的行为模式，设计出基于REST架构的海事信息系统的逻辑模型，如图3所示：
基于REST架构的逻辑模型打破了传统基于JavaEE的MVC固有研发框架，设计模式更加清晰。整个逻辑模型采用B/S架构，对海事应用系统用户层面来说是透明的，用户只要根据自身需求在客户端进行界面操作即可，不用去关注任何业务逻辑和技术实现细节。
模型进一步降低了前后端的耦合程度，前端应用负责对页面进行组织并进行用户工作台综合展示，后端应用只关注海事业务实现并返回指定格式的序列化结果集。采用前后端逻辑分离的工程体系，也使得信息系统项目研发工作分工更加明确，也有利于提升代码编写人员的技术专一性，使得工程设计研发效率大幅度提升。
基于REST框架的前后端分离模型具有更好的平台兼容性，后端不必考虑前端使用何种展现技术，前端则适用于任何后端高级研发语言和逻辑体系架构。
2.1网络服务端
網络服务端即逻辑后端负责与数据源的交互，针对前端的网络服务请求对应访问相关数据源获取可操作数据，并对生成的可识别模型类对象进行逻辑操作反馈给业务展现端。从整体上来说，网络服务端主要包括访问权限管理OAM、Session Manager管理器、业务逻辑处理、对象解析器、序列化数据生成器等诸多细分模块，下面对该部分的关键核心模块进行解析。
访问权限管理OAM是整个网络服务端的接入控制器，负责与业务展现端进行数据对接和网络交互，其响应业务展现端发送的Web Service请求和异步刷新服务。访问权限管理OAM对接入的普通http请求和ajax请求进行合法性认证，通过其内置的认证服务中心对接收的客户端请求数据进行验证，并针对不同前端环境发放对应的通行证Ticket已标志其是否正常登录。该模块针对前端的校验技术应提供绝对安全的接入手段，目前主要包括不可逆加密型账号密码方式和全球唯一性数字证书加密服务两种类型。针对正常合法的网络服务资源请求，访问权限管理OAM采取放行策略并反馈其需求的后端资源。针对未实现前端账号登录或数字认证的用户接入和网络请求，访问权限管理OAM实行自定义拦截，拒绝提供其定位的静态资源或数据获取服务并强制进入登录转接页面。
Session Manager管理器用于保持当前合法性用户的服务时效，并且集中在网络服务端存储用户的公共数据和全局性信息。基于自定义可插拔的扩展思路，通过灵活配置实现Session信息的按需个性定制和增删服务。通常情况下的模式会话中，保存的用户信息主要涉及登录信息、权限认证、个人资料、功能操作定义、会话保持时间等内容。该模块的功能，由网络服务端应用程序和服务器servlet容器共同实现。
业务逻辑处理模块是网络服务端负责数据获取操作和结构组织的环节。通过应用封装的JDBC服务和数据库访问技术，获取包括关系型或非关系型的格式化数据，并针对结果集合进行代码处理实现数据持久化操作。该模块侧重于业务逻辑的实现，针对前端网络请求需求的不同，业务逻辑处理模块进行不同数据库访问的逻辑拼接和合法性校验。针对不同的前端操作需求，设置逻辑判断进行筛选并对应分配，对静态数据的访问直接通过服务器进行HTML文档的定位并进行反馈，而针对包含业务数据的动态信息则需要经过流程化的数据拼接和转换处理。
对象解析器模块是网络服务端进行批量数据处理的通用性构件，主要实现模型类数据到结构数据的变换和解析，以方便后面环节进行数据拼接和最终序列化数据的生成。该模块被架构赋予了较高的通用性和封装性，便于工程迁移装载和模块间的组合调用，也易于项目的后期升级改造和第三方集成扩展，避免工程的业务需求变动对核心代码层的不利影响。对象解析器模块对多种已有对象类型具有较强的兼容性和适用性，并且注重大规模格式数据的批量转换效率。对象解析器的最终输出结果之所以是通用的结构数据，是为了在基于现有的序列化技术的基础上最大程度上避免代码重构，使得平台架构拥有更好的兼容性和逻辑扩展能力。
序列化数据生成器是针对业务展现端的网路服务请求进行数据反馈的功能模块，负责将对象解析器构造的通用结构数据进行序列化。对请求的响应主体数据执行序列化这一环节，是基于REST框架的前后端分离体系和传统的MVC设计模式比较明显的不同之处。基于REST架构的网络服务器端对数据的序列化需要遵循一定的通用格式，以方便前端即业务展现端进行综合信息展示和统计分析，目前序列化的数据主要包括XML和JSON两种主流格式，基于REST架构的后端逻辑框架采用JSON格式的序列化数据。JSON格式是一种比较轻量级的信息传输和交互格式，相对于XML表现出数据格式规则简单、便于接收端进行数据解析、后端研发语言兼容性好、传输速度更快、网络带宽占用更小等诸多优势。
2.2业务展现端
业务展现端是基于REST架构的信息系统体系模型的前端工程，负责接受用户业务需求和逻辑操作并与后端进行网路服务交互，对用户尝试获取的最终数据信息进行综合界面展示和终端样式规格适配。业务展现端是用户通过与其所在机器不同规格浏览器直接接触并进行相关指令发送从而达到海事业务需求表达目标的模块，该模块同样关注UI设计和文档样式适配，表现出用户交互度高、浏览器技术格式多样话、客户端操作环境各异等特点。从整体上来看，业务展现端主要包括高度集约化的格式化前端装载器、Code Generate生成器、Code Resolver解析器等核心组成模块。
格式化前端装载器模块是一个将后端模板化的文档型数据进行格式化转换的工具集，其针对网络服务端的固化文档片段进行格式分析和完整性拼接，并最终生成固定格式的静态文档进行业务展现端的解析载入。在服务器端固定位置存储的文档型数据会被提前模板化并赋予一定的展现规则，其经过流程处理最终会被网络服务端的业务逻辑处理模块经过判断逻辑核心过滤进行定位。基于业务展现端不同用户的差异性接入处理需求，网络服务器端会准备原始的展示文档供格式化前端装载器进行配置载入以降低前端文档技术操作的实现复杂度。基于海事领域业务逻辑的分散性和数据统计展现分析需求的不确定性，一个业务展现端的用户操作请求期待获取的最终格式数据可能存在于多个文档型数据中，因此格式化前端装载器支持带有独立业务展现逻辑的片段性文档的组合拼接转换。
Code Generate生成器是对网络服务端经过信息序列化后的主要关键性动态业务数据进行处理的主要模块，通过综合运用异步操作为核心的前后端网络请求交互技术负责对用户不同功能性需求进行实时响应和操作逻辑界面的异步刷新。基于REST架构的访问端和服务端分离的逻辑架构规则，避免了客户端请求提交导致的网络服务重定向和操作界面的整体重新加载带来的不友好UI人机体验。业务展现端基于局部响应式的用户操作异步刷新服务的设计实现，对网络服务端远程传送的序列化规则数据表现出高度的技术兼容性和数据可操作性，便于业务展现端对整体的原始业务数据采取进一步加工处理和基于展示需要的后期格式改造。Code Generate通过支持对框架自定义外部插件的工程配置实现个性化可插拔式加载流程，方便于技术研发人员对第三方控件和软件中间部件的独立扩展，降低后期用户需求变更和业务功能优化升级而引发的系统间功能整合和数据集成给工程带来的改造难度。通过對由Web Service远程接口调用获取的网络服务端传递来的参数数据的不同类型进行区分甄别，通过Code Generate生成器的归类模块切分为增量替代数据和批量原生初始化载入数据。相对于基于JavaEE的传统MVC研发模型的前后端数据传递和交互显示方式，Code Generate生成器采用基于VUE前端渲染技术进行后期封装的参数传递模式，用于对网络服务端传来的用于业务逻辑展现的参数类序列化数据进行定位适配和视图界面显示。Code Generate生成器通过综合运用jQuery、跨域Ajax等前端操作交互技术和amaze等UI展示框架对用户当前的Doument模型进行操作，产生满足特定业务展现需要的格式化静态文档供后面模块进行解析并最终呈现给浏览器内核进行基于不同需求的用户访问的最终展现。
Code Resolver解析器是与浏览器内核代码解析器进行交互的前端代码分解模块，负责将格式化静态文档中封装的中间层代码进行解析生成最终可用代码供浏览器内核进行装载运行和终端业务显示。基于REST框架的前后端分离逻辑架构提供多种格式的中间件和页面控件的代码解析，支持非启动式配置文件的方式进行工程载入便于技术研发人员根据需要进行扩展，并在脚本文件中将相关控件功能进行模块化以支持通过二次研发实现定制化的功能需求。
3 系统体系架构
按照逻辑模型设计出的基于REST架构的海事信息系统体系架构如上图所示，整体上看主要采用五层体系架构，包括接入层、展现层、业务应用层、数据层和支撑层。
接入层：通过给用户进行角色授权，实现系统登录和业务操作。该层是与用户直接进行对接的最高级层次，整个体系架构从用户角度来看是全透明的，用户只需要对该层提供输入条件和需求，而无需考虑任何架构模块细节和技术实现逻辑。接入层负责用户登录逻辑的判断、系统权限的分配和载入、基于特定需求的业务办理操作等。
展现层：在浏览器端对获取的数据进行全方位多角度的表现和展示。展现层负责将基于需求的业务操作进行功能模块化，并提供用户相关功能的操作菜单和访问入口。该层次的常用功能模块可以包括信息管理、统计分析、报表展现、电子海图、船舶动态等。
业务应用层：集中处理业务逻辑，并将数据进行序列化以向前端进行传输。业务应用层针对数据处理逻辑可以划分为多个模块，主要包括船舶数据信息处理发布业务模块、船员数据信息处理发布业务模块、从业企业信息处理发布业务模块、管理机构信息处理发布业务模块、船检数据信息处理发布业务模块、访问授权及身份认证服务模块等。
数据层：实现业务数据的格式化，并进行高效存储和管理。该层是基于REST架构的海事信息系统信息处理的数据源头，主要维护的数据包括海事业务领域相关的企业信息、船舶信息、船员信息、机构信息等。数据层也可以根据今后海事信息系统业务升级的需要，通过信息整合和数据迁移的方式获取其他业务系统的相关数据。
支撑层：为系统运行提供物理设备和软件中间件支持。支撑层是基于REST架构的海事信息系统体系架构的最底层，为上层的各项服务提供软硬件支撑，以满足用户对功能、性能、操作等多方面的需求。特别是当前数据日趋集约化的信息时代大背景下，海事领域的各方面业务数据量日益庞大，而海事从业管理人员和相关业务办理用户对数据的快速一致性获取需求不断增长，这就对支撑层如何提供更好的存储服务、操作性能、高效展现等多方面提出了更高的要求。
4 结论
通过综合分析并总结当前阶段信息系统在设计模式和逻辑架构中面临的诸多问题，并在对REST架构进行深入研究的基础上，融合海事领域信息提出了一种基于REST架构的海事信息系统逻辑模型和体系架构。该模型打破了当前传统的基于JavaEE的MVC设计和研发模式并解决了该模式存在的诸多缺陷，基于REST架构的海事信息系统模型架构兼具前后端耦合度低、功能可扩展性强、逻辑分工明确、系统升级改造难度小、个性化定制便利等诸多特点。该研究立足当前海事信息系统需求更新快、对工程集成改造便利性要求迫切等领域信息化发展形势，有利于增强系统研发人员的技术专业性和提升各系统间的协同办公能力，对当前简政放权背景下凸显海事领域职能部门的社会服务属性具有积极推动作用，使海事信息化工作在设计研发模型上朝着高效、便利、健康的方向发展。
参考文献：
[1]何红，步红，崔越，周一航. “引航家”国产智慧船舶交通管理系统——无纸化电子值班与交班[J]. 中国海事，2017，（07）：35-36.
[2]任中方， 张华， 闫明松，等. MVC模式研究的综述[J]. 计算机应用研究， 2004， 21（10）：1-4.
[3]劉小龙， 陈岚， 李莹，等. 基于REST的园区数据管理系统的研究[J]. 计算机工程与应用， 2017， 53（18）：208-212.
[4]孙祖汉， 李莹， 罗智凌，等. 可视化REST服务组合框架的设计与实现[J]. 小型微型计算机系统， 2017， 38（1）：10-14.
[5]王进， 黄志球. 面向超媒体链接的RESTful服务隐私建模方法[J]. 计算机研究与发展， 2017， 54（4）：886-905.
[6]杨凤攀. 基于SOA架构的智能终端云服务平台设计与实现[D]. 吉林大学， 2017.
[7]仇小花，秦栓栓，邱果. 基于WEB开发中的XML与JSON数据传输格式研究[J]. 信息技术与信息化，2017，（04）：123-125.
