面向资源架构的移动应用系统设计与实现

2018-05-03陈廷伟管泽华王传琦王智鹏

计算机应用与软件 2018年4期

陈廷伟管泽华王传琦王智鹏丁蕊王烨

(辽宁大学信息学院辽宁沈阳 110036)

0 引言

在移动互联网时代，随着移动智能终端设备性能的不断完善，各行业领域，逐渐将基于PC环境的传统网络应用系统逐渐转换为移动分布式网络应用系统。移动应用利用移动设备的便携性与灵活性，使得原有业务实施变得更方便与高效，为行业注入新的活力。这也是政府所提倡的“互联网+”的主要体现形式之一。目前对于国内外已有移动分布式网络应用系统设计方案主要是针对Web Service的研究，它根据对系统事物抽象认知的不同分为：面向服务的架构SOA与面向资源的架构ROA两种实现形式。与之相对应的实现方案分别是基于远程过程调用RPC协议的Big Web Service和基于表述性状态转移REST架构风格的RESTful Web Service。

面向资源架构的RESTful Web Service以资源为核心，利用HTTP协议与URL定义资源、标识资源以及统一资源接口等，将资源瞬间的快照通过标准的表述格式，实现在各组件之间灵活的交互，支持繁杂异构平台之上的应用系统。标准的资源设计使得RESTful Web Service极具可扩展性，用于承受服务的快速增长。相比Big Web Service，RESTful Web Service更为轻量级，更能够解决现有的移动网络应用系统的复杂性问题。

本文主要研究利用基于面向资源架构的RESTful Web Service来进行移动分布式网络应用系统的设计。

1 面向资源的移动应用系统

1.1 面向资源架构

Leonard Ricbardson在《RESTful Web Service》一书中，论述了REST将资源作为核心的理念，并首次提出面向资源架构(ROA)是RESTful Web Service的具体实现[1]。ROA是一种将系统中所有事物抽象成资源，并以资源为核心的系统架构实现形式。ROA在系统设计原则上，遵循REST架构风格的约束与Web Service技术规范。ROA利用已有的HTTP、URI以及标准数据传输格式(XML、JSON等)等技术实现资源的定义、标识以及表述等，使得资源极具确定性、层次性、可扩展性，并且使得资源数据在低耦合的系统组件之间传送便捷。

REST是Roy Fielding博士在《Architectural Styles and the Design of Network-based Software Architectures》论文中，首次提出的一种全新的基于网络的架构风格，并将其作为软件架构设计的标准。论文详细阐述了REST的主要约束：客户-服务器、无状态、缓存、统一接口、分层系统、按需代码等。Web Service技术规范定义了应用程序如何实现交互操作，即提供标准的交互方式，使得各独立平台的应用程序之间能够完成信息交换或者集成，无须第三方软硬件的支持。

由REST约束与Web Service技术规范可知，ROA的主要包括以下特征：分离关注点、资源寻址、状态转化、连通、统一接口等。关注点是指表现部分、资源支持，将其分离后使得表现层可以在多个平台之间移植，但是保持资源支持组件独立更新，有利于各分离点的独立扩展。资源寻址是指由资源组件所发布URI可以唯一定位资源，一个资源可对应多个URI，这将简化资源的访问与扩展。状态转化利用HTTP协议的无状态特性，使得提供资源时服务器不会进入某种状态，进而加强了系统的可见性、伸缩性以及可靠性。连通是指资源之间通过链接进行关联，主要包括的连通形式为：超媒体作为应用程序状态引擎Web Link与HATEOAS(Hypermedia As The Engine Of Application Statue)。统一接口是指利用HTTP协议所规定的方法完成资源CRUD操作，并结合通用性软件工程原则，使得各组件方便地获得资源支持的同时降低组件与资源耦合度，促进系统独立性并完善交互的可见性。

1.2 移动应用系统

移动网络应用打破了传统网络应用时间与空间的束缚，增加了应用的灵活性，提高了业务处理的效率。由于移动平台环境繁多、硬件与网资源限制以及传统网络应用影响等因素，使得移动应用系统的设计与实施具有多样性与复杂性。移动应用系统主要具有以下特征：

(1) 分布式系统：移动分布式网络应用系统基于移动处理机执行本地处理与远程访问，属于典型的分布式超媒体网络应用系统。它的设计重点在于资源支持、资源通信以及系统结构的搭建。

(2) 异构平台：移动操作系统平台繁多，如：Android、IOS、Windows Phone等。移动应用系统设计，需要满足异构平台环境下应用与资源的稳定运行。

(3) 开发模式：移动应用开发模式根据是否依据本地操作系统可分为：Native App、Web App、Hybrid App。每种开发模式所对应的开发环境、开发语言以及与资源访问的方式等都存在差异。移动应用需要依据用户体验、开发成本等需求，选择有效的、合适的开发模式。

(4) 资源局限：为了保证移动设备的灵活性与便携性，移动设备硬件以及移动互联网的资源都存在局限性。移动应用在本地操作以及资源交互时，信息的数量与复杂度都需尽可能的轻便。移动应用系统很难承受过于繁琐或者重量级的应用系统架构。

(5) 集成复杂：多数移动应用是从传统的网络应用扩展或者平移而来，完整的移动应用系统需要考虑与传统网络应用系统的集成，使得资源信息能够统一、高效、便捷地管理。

1.3 面向资源服务架构选择

现在国内外对异构的分布式网络应用系统的研究较多，但是针对移动环境主要的关注技术为Web Service。其中Web Service主要包括SOA的实现与ROA的实现，相对应的经典方案为Big Web Service和RESTful Web Service。Big Web Service主要包括三部分：服务请求、服务注册以及服务提供。利用WSDL对资源描述后注册在UDDI并发布，并利用SOAP作为通信协议使用XML数据传输格式进行完整的服务支持运行模式。其SOA的调用关系如图1所示。

图1 SOA调用关系

Big Web Service是解决传统分布式网络应用系统搭建与集成的有效解决方案。针对移动平台环境应用，Big Web Service显得过于繁琐重量级，如移动服务的爆炸式增长，会使得UDDI服务注册文件过于复杂管理困难，很容易出现瓶颈问题。传输数据存在大量冗余，增加了带宽等资源的消耗等。

ROA遵循REST架构风格，以资源为核心，对于编程实现语言没有要求，其基本实现形式为：HTTP+URI+XML/JSON。HTTP作为通信协议，与URI用于资源的定义、标识以及资源统一接口。ROA的资源调用关系如图2所示。

图2 ROA调用关系

相比ROA的特征，ROA应用于移动应用系统存在以下优势：

轻量级：直接利用HTTP协议，抛去繁琐的附加通信协议；支持简洁的数据格式如JSON等；灵活易用：省略UDDI的注册与发布机制，URI进行资源寻址更加灵活方便；易扩展：只需遵守REST约束，通过URI的通用设计便可以实现对资源支持的扩展等。

2 面向资源的移动应用系统架构设计

2.1 系统架构模型

借鉴传统网络应用系统的架构设计的思维模式，对于基于面向资源的移动应用系统架构主要采用关注点分离与功能逻辑分层的原则进行分析与设计。一般的移动应用系统无论是否保留传统网络应用体系，都会有基于浏览器或者PC主机的后台管理系统负责对移动应用数据的基本管理支撑。一般的移动应用系统属于C/S与B/S的混合架构类型，依据关注点分离的原则，移动应用系统的总体架构可以划分：移动端应用平台设计、资源交互模型设计以及后端服务器平台设计。各关注点间相互独立，各自的编程语言、架构实现没有明确的规定，这十分符合移动应用系统特征的需求。移动应用系统总体架构模型如图3所示。

图3 移动应用系统架构模型

2.2 系统分层架构

移动应用系统架构依据功能逻辑对系统进行划分，形成系统分层架构。移动端应用平台主要分为三部分：用户交互UI、本地操作以及远程资源访问。本地操作主要是指离线操作功能的实现，如：用户基本信息管理、数据存储管理、基于本地资源的业务逻辑处理以及本地应用系统之间的交互等。远程资源访问主要任务在于遵循REST约束规则，设计合理的REST Client。本文以Android移动操作系统为例，依据功能逻辑分层的原则，并基于MVC架构模式进行系统分层。分层架构如图4所示。

图4 Android移动端应用平台分层架构

在基于Android操作系统的移动端应用平台分层架构中，模型层主要功能是封装数据以及处理方法，用于系统的业务逻辑。模型独立于视图、控制器，与它们没有依赖关系即模型不关心调用者。除此之外，模型还涉及到请求远程数据和本地数据资源的访问，因此模型又可以被分为：业务逻辑层、数据访问层以及远程请求层等。视图层是用户与客户端交互的入口，并有目的地将模型数据进行呈现。Android平台的视图主要以XML格式的布局文件来实现，文件的内容又有各种布局组件或者控件组件嵌套组成。控制层掌握了系统运行的流程，即接收视图层发来的请求并组织相应的模型进行响应，起到接收、选择模型并做出响应的作用。

资源交互模型作为移动端应用平台与后台服务器平台的交互桥梁，负责资源的请求与响应，是一个独立的关注点。资源交互模型具体实施需要两端按照ROA的规范，实现以“资源”为媒体的对接，由于其特殊性无需在进行分层。以ROA基本的实现形式，展示资源的请求、响应流程，如图5所示。

图5 资源交互模型

后台服务器平台作为资源的提供者，包括了资源访问入口、资源服务处理、数据库访问以及持久化。具体的分层架构设计如图6所示。

图6 后台服务器平台分层架构

资源层作为后台服务器平台资源支持的门户，其主要功能包括：发布资源、接收资源请求、调用服务处理、封装资源并响应。它是ROA的主要体现，设计的重点在于明确资源、依据URI标识资源、资源接口统一以及资源数据传输的格式选择。为了快速高效地实现，各技术社区依据REST约束以及Web Service规范公布了相应的框架，如：Jersey、CXF、Restlet等。

3 基于面向资源移动应用资源设计

资源设计为基于面向资源移动应用设计的主要内容。如何依据ROA规范以及移动应用业务逻辑进行合理的规划与设计资源，将决定整个应用系统的可扩展性、可维护性以及高效性等。资源设计一般包括：资源定义、资源标识、资源统一接口以及资源传输数据格式等。

3.1 资源定义

依据REST架构约束与业务逻辑明确资源，并形成一个资源分析图，不仅仅能够提高编码利用率，更使得资源的扩展变得清晰。在设计中对于资源的分类务必遵循“业务逻辑”与“资源粒度”综合考虑的标准。如果只考虑“资源粒度”将可能会按照面向对象的思想直接将对象实体映射为资源，这可能使得资源划分过于细化，导致资源利用效率降低，甚至难以使用。综合考虑“业务逻辑”与“资源粒度”，以“资源粒度”划分为基础，再以满足业务需求简化业务逻辑为主导，将存在某些直接或间接关系的资源整合。资源的分类如表1所示。

表1 资源分类表

3.2 资源标识

ROA利用URI作为资源设计的标识。资源标识的设计需要非常谨慎，良好的设计可以统一资源接口风格，使得系统具有较好的可维护性与可扩展性。资源标识设计需要遵循“层次结构”和“面向资源”原则。“层次结构”原则主要依据业务逻辑和URL表达式组织上的层次结构来定义。经典URI表达式的组成结构如下：

Http://localhost:8080/ContextPath/ServicePathlnfos/Pathlnfo?Scope1=xx&Scope2=xx……

根据URI组成结构可知，URI分为：资源地址与作用域，并以“？”作为分界线，详情分析如表2所示。

表2 URI组成结构表

由表2可以了解，URI存在着明显的层次结构而这种结构层次与业务逻辑层次相结合，标识在资源上可以描述为“自左至右依次为集合资源、资源、子资源或整体、局部或一般、具体”。“面向资源”的原则主要体现为资源命名的直观性和准确性。

3.3 资源统一接口

资源标识与资源接口唯一定位一个资源，因此资源接口统一设计也是ROA中对资源描述的重要组成部分。ROA通过HTTP已定义的方法作为资源接口的标准，将服务所提供的操作信息隐藏在方法中。统一资源接口设计的实质是依据资源的CRUD(Create 增加、Retrieve读取查询、Update 更新、Delete 删除)操作，为资源选择合适的HTTP方法。而HTTP方法的选择有应当依据该方法“幂等性”与“安全性”。其中，“幂等性”指多次访问资源接口而资源状态相同，“安全性”指访问资源接口不会改变资源的状态。HTTP方法对应的属性以及相应的操作详情信息如表3所示。

表3 HTTP方法说明

3.4 资源传输数据格式

ROA对于资源传输数据格式没有特殊的要求，但是针对移动应用系统，考虑到网络带宽与移动设备硬件等资源的限制，JSON更适合移动环境下资源传输数据的格式。相比传统XML数据格式，JSON是一种轻量级的数据交换格式，随着数据传输量的增加，传输所消耗时间明显短于XML。JSON格式简单与灵活，易于阅读与编写，它使用数据分隔符简化了数据的访问，并且其文本格式独立于编程语言。

4 实例分析

“翻转课堂”移动教学辅助系统是针对在校大学生与任职教师的高校移动教学辅助系统。本文将以该系统的“学生课程管理”模块为实例，详细了解如何基于ROA的移动应用系统设计流程。

1) 资源定义首先明确业务需求，该模块具体业务功能分析如下：课程详情浏览、课程提醒设置以及自定义课程管理操作(添加、删除、修改)等。以业务分析为基础结合资源划分准则定义资源，如表4所示。

表4 资源定义

2) 资源标识与统一接口根据资源标识设定原则与资源操作属性，设计资源地址标识与统一接口。具体如下：“课程资源集成信息”属于整个模块的根资源，其中与资源标识都在其“左”侧，主要为查询操作，因此统一接口设定为：“GET”；“某学生-课程集合资源(非自定义课程)”为根资源的二级资源主要用于展示某学生的所有课程信息，主要操作为查询，接口方法设定为：“GET”；“某学生-单个课程信息(非自定义课程)”为根资源的三级资源，“根资源的二级资源”的耳机资源，主要操作为查询，设定统一接口为：“GET”。依次类比设计其他资源。最终形成资源设计性情如表5所示。

表5 资源详情设计

3) 数据传输格式为更好地演示资源数据传输格式，将以学生添加自定义课程资源操作为例。学生发送请求资源地址：http://localhost:8080/fcapp/courses/{学号}/{课程ID/课程信息}方法为PUT，相应的JSON串如下：

{

″sid″: ″4031541925″,

″remindMark″: 0,

″remindTime″: 0,

″scheduleId″: null,

″scheduleName″: ″软件工程″,

″scheduleSite″: ″博远楼309″,

″scheduleTeacher″: ″陈老师″,

″scheduleTerm″: ″201602″,

″scheduleTime″: 504,

″type″: 0

}

4) 组件资源交互实现本案例利用符合JAS-RS(Java API for RESTful Web Services)标准的Jsersey项目构建资源层，主要用于实现资源标识指定、资源发布、接收资源请求、资源数据解析、资源响应以及资源推送、异步处理等内容。为了更有针对性地演示该模块的移动端远程资源请求层与服务器资源层组件交互流程，将以资源表中的“自定义课程”远程资源操作为例，分析资源请求、处理、响应流程，并具体分析编码实现中与资源相关的各对象之间消息传送顺序，利用时序图显示它们之间的动态协作关系。资源操作时序如图7所示。

图7 “自定义课程”资源操作时序图

依据以上资源设计以及操作时序图，最终实现的“学生课程管理”模块交互界面，如图8所示。

图8 “学生课程管理”模块交互界面展示

在该移动应用中，利用不同的“单元格”颜色(以不同灰度表示)标识不同课程的类别：必修课程、选修课程、自定义课程、无课程。对于“自定义课程”的具体操作界面展示，如图9所示。可以对自定义课程进行信息的修改，删除自定义课程以及设置课程提醒，具体页面就不一一展示了。

图9 “自定义课程”操作页

5 结语

本文研究了面向资源架构的移动应用系统设计，

并详细分析了面向资源架构与移动应用系统的特征。基于面向资源架构提出一般性的移动应用系统架构设计与资源设计，并以“翻转课堂”移动教学辅助系统为实例分析。面向资源架构不仅可以满足移动应用系统的复杂性，而且能够更好地提高系统的可扩展性、高效性以及可维护性等。面向资源架构仍存在一些缺陷，如：安全机制等，这将成为下一步需要思考与完善的主要内容。

[1] Richardson L,Ruby S.RESTful Web Services[M].O’ReillyMedia,Inc.,2007.

[2] 毛峰,刘婷,刘仁义,等.基于REST面向资源的地理信息服务设计[J].计算机工程,2011,37(8):238-240.

[3] 毛力锐.基于REST面向资源的企业信息集成平台框架[D].上海:交通大学,2010.

[4] 黄宁海.基于REST的轻量级J2EE架构实现[D].杭州:浙江大学,2008.

[5] Fielding R T.Architectural Styles and the Design of Network-based Software Architectures[D].Irvine:University of California,2000.

[6] 尹兆冰,王加阳.Web Service及其关键技术研究综述[J].软件导刊,2010,9(2):121-123.

[7] 赵启升,李存华,吴庚午,等.一种基于REST架构的高校移动教务数据开放平台设计方法[J].江苏科技大学学报(自然科学版),2014,28(5):500-504.

[8] 李莉,张超然,刘丹,等.移动APP开发模式研究[J].长春理工大学学报(自然科学版),2016,39(5):110-114.

[9] 卢致杰,覃正,韩景倜,等.SOA体系设计方法研究[J].工业工程,2004,7(6):14-19.

[10] 李刚,孙红梅,李智,等.资源受限Web服务[J].计算机学报,2010,33(2):193-207.

[11] 胡天云,林庆.RESTful服务及跨平台移动应用[J].软件导刊,2015(4):87-89.

[12] 高嘉泽,高强,吴国全,等.面向移动应用的后端服务平台[J].计算机系统应用,2014,23(2):22-27.