移动应用的架构设计

移动应用的架构设计（精选8篇）

移动应用的架构设计 篇1

1. 引言

大型企业信息系统的推广与发展,一方面极大提高了企业业务处理能力,另一方面也促进了计算机设备的发展。随着智能移动设备的日新月异,人们的办公地点不再局限于办公室的计算机前。智能设备作为企业信息系统的移动终端,是未来企业信息化的一个重要的发展领域。

微软的移动设备在全球的PDA市场中拥有45%的市场占有率,其移动智能产品覆盖全球93个运营商55个国家。在硬件设备与操作系统相对稳定的条件下,如何更好地设计移动应用系统的架构,成为了移动信息系统性能与稳定的决定因素之一[1]。

2. 移动应用系统架构

普通用户可能早已对PC有着熟悉而丰富的体验,然而智能设备不同于一般的PC机,它在许多方面和PC有着较大的差距。作为智能设备,其突出的功能优势在于对数据的“移动处理”,能够提供没有地域限制的工作环境。所以,数据的传送和同步功能是移动应用系统的关键所在。

一方面,大型企业一般都已经发展成型了相关的信息系统,移动客户端的引入只能在原系统的基础上扩充发展。另一方面,由于智能设备的网络通信需要借助当地的移动网络供应商提供接入服务,增加移动网关层次可以减轻原有信息系统服务器的负担。再者,移动应用不可能同时完成企业信息系统的所有数据通信访问。作为应用的业务来说,也不会要求一次的处理涉及太多的逻辑数据关系[2]。

为此,在移动应用系统设计中,需要增加一个逻辑层次———移动网关层。整体结构如图1。

现有系统部分包括原来已经建设好的信息管理系统、知识库或其他的遗留系统。为了更好地与移动网关进行通信,利用Web Services的形式将在现有系统处理,从而提供一套标准的服务接口。

移动网关部分将提供一个对外的地址,用于移动客户端的接入。同时负责将现有系统的数据进行重新整合,快速准确地实现数据在移动设备与信息系统之间的交换。另外,移动网关还可以作为安全策略控制的平台,对每一个接入的移动客户端进行访问控制。

移动客户端则主要负责用户的交互处理,基本业务逻辑的应用,以及离线数据的缓存,通信队列管理等。

移动应用系统总体是以原有的管理信息系统作为依托,从架构上添加数据的过渡处理层次辅助原有系统工作[2]。为此,数据网关与原有系统直接的工作关系是结合较紧密,作为移动客户端的功能实现,仍有赖于移动客户端的内部架构。

3. 分层架构在移动设备中的实现

目前的智能移动设备运算能力已经可以与当年的奔腾级PC比拟,PC机中的程序逻辑架构也适用于移动设备上运行。特别在微软.net compact framework平台的支持下,使得大部分桌面开发的应用模式可以在移动应用程序中使用,这样既可以大大方便开发人员的设计,也提高了程序在设备中的运行效率[2,3]。

在桌面程序设计中已经广泛使用的分层架构,在移动程序中也可以实现。详细架构内容如图2。

3.1 用户表示层实现[4]

表示层负责从用户方接收命令、请求、数据,传递给业务层处理,然后将结果呈现出来。作为应用程序中至关重要的一部分,构建不适当的表示层可能会导致复杂性太高、缺少灵活性,并使得用户控制效率低下,不尽人意。在复杂应用的系统中,状态与流程的管理是必须要考虑的因素,它们同样是业务逻辑的一部分,如果不加以封装的直接写在事件函数中将导致业务依赖表示层。除了在设计中抽象业务的处理过程行程驱动类外,针对移动设备的显示范围较小,处理速度相对较慢的问题,在UI的设计尽量做到以下两点。

(1)优化窗体的加载速度。减少控件的数目,减轻窗体绘制所需要的处理的工作;减少初始化的Method,尽量在后台或驱动类中实现数据的初始化,减少控件加载时间。

(2)优化程序的运行速度。数据直接加载到控件而不是绑定到控件,最好自己设计一个适配器按照某种映射关系来自动处理这样的绑定。使用Xml Text Reader而不是XmlDocument来进行XML数据的读取。使用后台线程技术来处理耗时的工作,独立的驱动类设计就是为了减轻窗体的负担,让用户从UI的等待中解放出来。

3.2 业务逻辑层实现[5]

业务数据又是业务逻辑的核心,最终业务数据将以一种固定的格式表现于内存中,在系统的各个层次间传输,充当数据传送对象的角色。表达业务数据的方式一般分为表格模式和域模式。

表格模式是将数据库中的表直接映射成为业务数据对象,这样的优点是适合于机器操作。ADO.NET直接提供了这种操作的便利,VS中绝大多数的控件都支持数据绑定操作,这样虽然可以在数据直接显示到相应的控件内,但不能表示复杂的业务逻辑关系,只适合于业务需求与数据表对应关系很直接的需要快速开发的情况。使用数据绑定的缺点比较明显,复杂数据表现不直观,作为数据传送对象在各个层次间传输,尤其是分布式环境,庞大的体积,相对缓慢的实例化对于性能造成很大压力。

域模式则需要根据实际业务逻辑,按照现实方式使用面向对象思想建模,这种方法比较适合业务复杂的系统。通常采用自定义数据实体方式表达。自定义数据实体,有着良好的性能,编译时的类型检查,数据表现方式非常直观符合实际业务的操作方式等优点,但需要自己定义维护类,在分布式环境下需要自己编写序列化方法。

综合各种因素考虑,虽然业务简单对应直接的系统,我们以表格模式建模开发效率很高但难免保证系统日后不会变的复杂,因此出于复用性,扩展性,性能等方面选用域模式建模为佳。

3.3 数据层实现[5,6]

数据层的宗旨就是为数据源提供一个可供外界访问的接口,我们应该选用一种能够提供数据源无关的抽象数据访问接口并通过在其下挂接各种不同的数据连接件来访问数据源的数据层组件,这样做便于移植到不同的数据源上。

但是移动设备对数据处理与应用有着它独特需要解决的问题——移动数据的同步。通过SQL Server CE可以建立一个本地的数据存储空间。SQL Server CE与移动网关所连接的数据库有着相一致的数据组织结构,通过移动网关可以实现订阅的管理,或者数据的同步。

对于偶尔的连接访问,可以通过服务代理程序直接访问外部的Web Services调用。这样可以第一时间获取重要的资料或回送及时采集的数据信息。

3.4 移动业务应用程序的公用组件

除了MVC模型三层次的实现外,设计和结构构建应用程序还需要实现常见任务的基础结构组件。

管理组件:1)记录。这包括存储关于规范事件的数据,连接时可从服务器收集这些数据。2)部署。这使将应用程序部署到设备上以及在添加新功能时更新应用程序变得更容易。3)配置。这包括支持丰富的存储机制和允许服务器传送复杂数据,例如每个用户或每个设备的特定配置。

安全性组件:凭证管理。这包括存储用户凭据,从而能够验证对偶尔连接的Web Service的验证。

连接性组件:连接和网络管理。这包括提供评估设备的当前连接性和对连接性的更改做出反应的功能。

4. 结语

在多层架构的系统应用中我们可能会从其他的业务系统中获取数据,也有可能我们的数据库存在于服务器上而不是设备本地。甚至乎我们的业务规则或计算引擎根本不在本地。

这个时候我们需要与这些外部系统进行数据和业务的交互。从外部系统获取数据或者提交本地的数据到外部系统进行规则运算或检测。我们可能需要使用数据库直接连接访问、MCSF无连接代理、Remote Data Access(RDA)、XML Web Services等技术来实现。

作为架构设计师,必须确保移动智能客户端应用程序来自可靠的、基于实践检验的基础。同时,这个基础能够提供应用程序开发的标准方法;提高常见体系结构组件的重复使用性;隐藏复杂性,使开发人员能够将精力集中于业务问题,而不是集中在基础结构组件上[1,3]。

参考文献

[1]温昱.软件架构设计[M].北京:电子工业出版社,2007.

[2]陈新.应用框架的设计与实现——.NET平台[M].温昱,靳向阳译.北京:电子工业出版社,2007.

[3]移动客户端软件工厂-社区技术预览版本[EB/OL].http://ms-dn2.microsoft.com/zh-cn/library/aa480471.Aspx.

[4]选择正确的表示层体系结构[EB/OL].http://msdn2.mi-crosoft.com/zh-cn/library/aa480039.Aspx.

[5]设计模式:Model-View-Presenter[EB/OL].http://www.mi-crosoft.com/china/msdn/library/architecture/architecture/architecturetopic/MVP.mspx

[6]使用Visual Studio创建数据应用程序[EB/OL].MSDN2005:ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.VisualStudio.v80.chs/dv_raddata/html/28edce21-220a-484c-b461-a75b0232d293.Htm.

移动应用的架构设计 篇2

关键词：电力企业;运营监测信息;架构设计

引言

电力能源与燃气能源、矿物能源以及其他能源相比有着方便、快捷、洁净、持续等优势，电力能源未来将成为我国主要能源，电力企业的可持续发展对社会有着重要意义，电力企业在国家发展和社会中都占有重要地位。目前由于我国电力企业的特殊性，电力市场一直处于垄断状态，在这种情况下，电力企业就放松了经营管理，导致电力企业运营监测信息系统不完善、不可控、不能控，这极为不利于我国电力企业的可持续发展，我国电力企业必须针对原有运营监测信息系统应用架构进行改革和创新。

1.电力企业运营监测信息系统应用的科学内涵研究

全球化经济发展的大背景下，促使我国电力事业也加快了发展脚步。信息化时代的到来，为电力企业运营带来了新转机，电力企业发展为了顺应时代需求，信息化运营已经成为必然趋势[1]。信息化运营能够为电力企业运营管理工作提供便利，提高工作效率。虽然我国电力企业信息化建设应用起步较晚，但在不久的将来我国电力企业信息化建设将实现“技术标准化、制度规范化、网络化、系统平台化、数据资源化、业务集成化”，想要有效实现电力企业信息化建设目的，运营监测信息系统非常重要，因为运营监测信息系统是电力企业信息化建设的关键，直接关系着整个信息化建设的质量和效果。运营监测信息系统实现了对企业的可视化管理操作，24小时企业运营监控，不仅能提高管理效率和企业经营效率，更加强化了领导层对企业的管控能力，实现了对电力企业运营中的紧急事件、异常、异动等问题实时监控分析、预警，科学的帮助电力企业规避了运营风险，提升了电力企业运营水平和管理水平，提高了电力企业市场竞争力，促进了电力企业健康可持续发展。

2.电力企业运营监测信息系统应用的架构设计原则研究

目前我国电力企业处于发展阶段，在不断发展及改革的过程中，企业运营监测信息系统起着积极作用，企业运营监测信息系统有着全面监测、运营分析、协调控制、全景展示等功能，是整个电力企业运营发展的科学依据，为了保证企业运营监测信息系统的有效性和科学性，在架构设计中必须遵循一定的原则。下面通过几点来分析，架构设计的原则：

2.1实用性原则

由于我国电力企业的特殊性，所以运营监测信息系统必须坚持实用性原则，必须充分了解电力企业自身情况和发展状况以及我国国情，在确保实用的前提下再考虑先进性和前瞻性，这样才能有效确保运营监测信息系统架构设计的有效性及目的的实现，避免只做无用功，最终浪费财力物力[2]。

2.2安全性原则

在运营监测信息系统架构设计中必须充分考虑信息系统的安全性问题。随着信息化时代的到来，信息安全问题一直备受各界关注，信息的泄漏威胁着整个电力企业的发展及运营，因此在运营监测信息系统应用架构设计时应优先考虑系统安全、软件安全、硬件安全，加强先进安全技术的引进，制订相关安全机制和制度，确保整个运营监测信息系统的安全应用、数据安全、信息安全、网络安全、主机安全[3]。

2.3可靠性原则

电力企业在运营经常遇到突发状况，因此运营监测信息系统必须实行对企业的24小时监控，实现为企业运营提供科学依据和方向。如果数据不及时或严重失真，那将给企业运营造成不良影响，所以在运营监测信息系统应用架构设计时，必须保障整个系统运行时有着高度的可靠性，避免无信息或失真信息等现象的出现。

2.4可扩展性原则

电力企业的发展和运营中避免不了实时的根据自身运营情况作出制度及标准的调整，因此，运营监测信息系统应用架构设计时也必须采取柔性设计，以适应电力企业的调整和改革，所以运营监测信息系统应具备一定的可扩张性，以此保障架构的柔性设计及可扩张，使整个系统能够灵活适应电力企业业务的变动，更有效保障运营监测信息系统的科学性。

2.5经济性原则

运营监测信息系统应用架构设计目的不仅仅是确保整个运营监测信息系统的有效和科学性，保障整个系统的实施。另一方面，也是一种成本控制、节约成本的有效手段，因此在进行运营监测信息系统应用架构设计时应考虑经济性，以便于有效节约投资成本。

3.结束语

随着时代的发展，电力行业随着社会发展也取得了优异成绩，电力企业未来将成为我国主要能源，整个社会对供电需求越来越大，对供电的稳定性更是提高了标准，为了应对庞大的市场需求及经常竞争带来的运营风险，电力企业必须加强运营监测信息系统应用架构设计的改革创新，进而确保整个运营监测信息系统的科学性、先进性、实用性、经济性，实现有效增强电力企业市场竞争力，改善电力企业运营管理状态，促进我国电力企业的可持续发展。

参考文献：

[1]徐梅玉.浅析电力企业运营监测（控）信息系统应用架构设计J].湖北经济管理技术学院，2012，13（11）：119-124.

[2]李力旺.电力企业运营监测（控）信息系统应用架构设计思路[J].浙江信息职业技术学院，2011，11（14）：132-136.

移动应用的架构设计 篇3

伴随着互联网从PC端向移动端的迅速延伸,使移动端成为互联网最重要的入口,而这些移动端的设备每天产生以十亿计的海量信息,这些海量信息已经渗透当今每一个行业和业务智能领域,成为重要的生产因素。传统的处理数据方法是把静止数据库中的数据带进程序进行分析。而移动互联平台时刻产生数据没有办法停止,最佳处理方法是把程序带进活动的数据进行分析,因此基于移动互联平台下如何采集、存储、整理分析和挖掘海量信息,成为亟待解决的问题。本文采用Lambda架构作为系统的通用大数据处理框架,整个系统划分为Batch Layer、Speed Layer和Serving Layer 3层,在这3层中集成Hadoop、Kafka、Storm、Spark、Hbase等各类大数据组件,解决移动互联平台读写分离和复杂性隔离等问题,为构建移动互联平台解决方案提供宝贵经验。

1 Lambda简介

数据是与时间有关的,数据一定是在某个时间点上产生的,因此数据的本身是不可变的。移动互联平台分布式系统中的数据产生于不同的系统中,时间决定了数据发生的全局先后顺序,移动互联平台必须实时存储和处理数据。

Lambda架构是由Nathan Marz提出的一个实时大数据处理框架,其核心思想是既能兼顾低延迟的计算需求,同时也具有处理全量数据的能力,最后通过将2个部分的视图聚合起来提供外部服务。

Lambda架构(如图1所示)是集成Hadoop、Kafka、Storm、Spark、Hbase等各类大数据组件,设计出一个能满足实时大数据系统关键特性的架构,包括高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算,融合不可变性、读写分离和复杂性隔离等一系列架构原则。

2 移动互联大数据平台架构的设计

移动互联大数据平台(如图2所示)是基于Lambda架构,由数据采集层、数据接入层、数据计算层、数据服务层和数据存储层构成。

数据采集层面临高并发、数据量大和扩展性等亟待解决的问题。本文在数据采集层引用Finagle Server开源异步服务器框架,该服务器框架契合移动互联网访问特点:高并发,小数据量,单台服务器的处理能力得到了极大地提升,同时支持横向扩展收集日志服务。对于移动终端如手机、平板和盒子等设备,数据采集层提供通过APP集成SDK,移动互联平台通过SDK将移动终端设备的日志返回到移动互联平台,移动互联平台在nginx负载均衡下,通过唯一标识、数据标准化和数据格式对数据进行清洗,最后把数据送入基于Finagle框架的日志接收器,最后传入数据接入层。

数据接入层使用2个Kafka集群来承担数据接入功能,最上面Kafka集群被实时计算消费,下面kafka用于离线数据消费,2个集群之间通过Kafka的Mirror功能进行同步。

数据计算层为了实现IO负载分离,通过业务解耦,把计算分为实时计算、离线计算、准实时计算3个部分。时效性是实时计算首先要面对的问题,从实时方面考虑,就不能放一些太复杂的计算,计算结果会存储到MongoDB。离线计算数据倾斜是贯穿离线计算始终的问题,通过改造Hadoop的公平调度算法来保证大任务能得到充分的计算资源在可接受的范围内计算完毕,同时使用Hive建立数据仓库,使用pig进行数据挖掘,离线分析的结果存储在H Base。准实时计算主要处理如下载服务、消息推送中的圈人服务等。最后通过统一的REST Service来对外提供数据服务。

3 移动平台数据存储和增值

本文利用云存储技术构建移动互联系统平台的存储系统,该存储系统不仅是一个并行的硬件,而且是由网络设备、存储设备、服务器、软件、接入网络、用户访问接口及客户端程序等多个部分构成的。为了方便维护,把该存储系统分为存储层、基础管理层、应用接口层及访问层。存储层是云存储系统的基础,由存储设备(满足FC协议、iSCSI协议、NAS协议等)构成。基础管理层是云存储系统的核心,其担负着存储设备间协同工作、数据加密、分发及容灾备份等工作。应用接口层是系统中根据用户需求来开发的部分,根据不同的业务类型,可以开发出不同的应用服务接口。访问层指授权用户通过应用接口登录和享受云服务,其主要优势在于硬件冗余、节能环保、系统升级不会影响存储服务、海量并行扩容、强大的负载均衡功能、统一管理、统一向外提供服务及管理效率高。云存储系统从系统架构、文件结构、高速缓存等方面入手,针对监控应用进行了优化设计。数据传输可采用流方式,底层采用突破传统文件系统限制的流媒体数据结构,大幅提高了系统的性能。

移动互联大数据平台存储系统的数据如何实现增值?数据是从统计到挖掘到大数据的阶段,只有通过这种数据的相互分享,才能够得到数据的红利和反馈。

第一,它们从顾客需要的数据(能够创造商业价值)开始,而不是聚焦在它们已有的数据及这些已有数据能告诉他们什么。主要工作是在幕后找出什么是顾客需要的(通过数据、工具、信息),然后得到答案。

第二,不是把你的见解分享给一小撮商业领袖,而是直接把它融入、应用到商业应用或者工作流程中,让尽量多的人来利用这些大数据的结论。

第三,拥有绝对的数据使用权。在这个基于云的大数据世界,第三方数据的获取、管理、使用都必须是合法的。

本文认为主要通过数据统计及APP的推送,为移动开发者提供支持。“友盟”的“一站式”解决方案整合了应用统计分析、游戏统计分析、社会化组件、微社区、消息推送、友盟指数等产品和服务,并基于数据将产品之间横向打通,以求充分发挥和运用数据的价值:其一,内部数据打通,“友盟”不光是做统计分析,还有即时通信、社会化分享、工具推荐等业务。把这些业务的数据尽可能地进行横向打通,这样一来,就可以利用用户自身的自定义事件,进行一些有针对性的推送。其二,用户画像。“友盟”还与其他的数据方合作,给用户进行画像,这样就可以进行更加精准的推送。用户画像可以根据现有的数据更精准地确定自己用户的属性和兴趣、行为等。其三,设备评级。对于APP开发者来说,了解渠道的推广效果,如哪些渠道的推广价值用户大,哪些渠道推广的用户价值小,哪些渠道有作弊行为,推广的全是一些虚假的用户。其四,APP健康度评估。通过APP健康度估价能使开发者了解自己这一款APP当前是处于生命周期的哪个阶段,是属于快速增长阶段、平稳发展阶段,还是属于衰减阶段。这样就能更好地了解自己的产品目前的健康状况,同时也能了解自身产品,如用户群体中有多少是垃圾设备,有多少是有价值的设备。

4 总结

本文介绍了Lambda架构的基本概念。Lambda架构通过对数据和查询的本质认识,融合了不可变性、读写分离和复杂性隔离等一系列架构原则,将大数据处理系统划分为Batch Layer、Speed Layer和Serving Layer 3层,从而设计出一个能满足实时大数据系统关键特性(如高容错、低延时和可扩展等）的架构。Lambda架构作为一个通用的大数据处理框架,可以很方便地集成Hadoop、Kafka、Storm、Spark、Hbase等各类大数据组件。

参考文献

[1]孙广中,肖锋,熊曦.MapReduce模型的调度及容错机制研究[J].微电子学与计算机,2007,24(9).

[2]刘鹏.实战Hadoop——开启通向云计算的捷径[M].北京:电子工业出版社,2013.

移动应用的架构设计 篇4

KJava是Sun公司专门用于嵌入式设备的Java软件。以KJava编程语言为手机开发应用程序,可以提供游戏、个人信息处理、股票、电子地图等服务程序。KJava在设计其规格的时候,遵循着“write once,run anywhere”这个基本原则。于是KJava先将所有的嵌入式装置大体上区分为两种:一种是运算功能有限、电力供应也有限的嵌入式装置,例如:PDA、手机等;另外一种是运算能力相对较佳、并且在电力供应上相对比较充足的嵌入式装置,例如:冷气机、电冰箱、电视机上盒(set-top box)。因为这两种区分,所以Java引入了一个叫做Configuration(配置)的概念,然后把上述运算功能有限、电力有限的嵌入式装置定义在CLDC(Connected Limited Device Configuration,连接受限设备配置)规格之中;而另外一种装置则规范为CDC(Connected Device Configuration,连接设备配置)规格。也就是说,KJava先把所有的嵌入式装置利用Configuration的概念区分成两种抽象的形态。

Java并不认识硬件,它是把Java编写的程序转换为机器运行指令的一个管理者,叫K虚拟机,运行在它上面的程序就可以叫做K-Software,或者K-Program,用来编写这些K-Program的Java语言也就被理所当然地俗称为KJava了。

2 KJava的特性

平台独立性:利用Java的“write once,run anywhere”特性,可以真正达到“一次编写,随处运行”。而不必为每一个目标平台各写一个版本。

安全性:KJava拥有Java技术本身的各种特点:支持定长数据类型,与机器无关;没有指针;对数组边界进行检查;保证合法地进行对象转换;提供垃圾收集机制等;同时采用两阶段类验证的底层KVM也能在该应用程序的执行过程中保证其不会对设备或网络造成损害。除此之外,KJava的沙箱模型也尽可能地消除了Java语言中某些可能由于缺乏安全管理器而引发的安全问题。同时,垃圾回收机制不仅把程序开发人员从繁琐的内存资源管理任务中解脱出来,还避免了因忘了释放某一块内存而导致程序无法执行甚至死机现象的发生。

简单性:KJava拥有大量丰富实用的类库,可以直接使用或经稍许修改而不需再重新设计,使得程序开发变得简单的同时,还可以大大缩短开发周期,尤其是KJava对网络协议如HTTP、TCP等提供大支持,从而可以简单快速地开发网络应用程序。

除此之外,KJava还具有很强的可扩展性,从而使得利用KJava技术编写的应用程序可被很容易地升级扩展至J2SE和J2EE平台。

3 KJava体系结构

KJava平台由多种配置Configuration、简表Profile和可选包Optional Package组成。平台的实现者和应用程序的开发者可以从中选择并组合出一个完整的Java运行环境来满足特定范围内的设备需求。每种组合都应该使这一系列设备的内存、处理器和I/O能力达到最优化。KJava平台的体系结构如图1所示。

从图1可以看到,设备的操作系统位于KJava运行环境的最低层。操作系统可以是Linux、Symbian或者PalmOS,这充分体现了Java语言跨平台的特性。配置由Java虚拟机和一系列的API集合组成,为某一范围内的嵌入式设备提供基本的功能,这些设备通常在硬件和软件上具有类似的特点。简表位于配置之上,和配置一起构成了KJava运行环境。

3.1 Java虚拟机

在KJava中提供了2种Java虚拟机(JVM)。由于JVM是Java代码运行时必须的,只有任何设备上有了JVM才能够很好地解释“write once,run anywhere”的关键技术。那么在嵌入式或移动设备中也需要JVM作为操作系统和Java应用程序间的接口。但是由于内存的限制,嵌入式设备的JVM也要特殊提供。

KJava中提供的JVM分为CVM和KVM,都是JVM的缩减版。CVM,最初解释为Compact Virtual Machine,但是后来对于C没有任何意义了。只是CVM虚拟机主要运行在存储量较大的嵌入式设备,比如可视电话、POS收款机等。KVM比CVM功能稍弱,KVM主要用于移动电话、个人数字助理(PAD)等小型设备。

3.2 配置Configuration

底层的配置Configuration为应用程序提供硬件抽象基础,它定义了硬件所必须具备的能力,如硬件至少具备多少ROM、RAM,CPU的时钟周期最少应该是多少,连接网络时频宽至少要多宽。除此之外,配置Configuration还定义了Java virtual machine所支持的程度和对核心类库所支持的程度。针对硬件的数据处理能力、存储容量、网络连接能力与用户输入输出设备,KJava将电子产品区分为不同的类并定义了两种配置Configuration,分别是连接设备配置CDC与连接受限设备配置CLDC。

其中,CDC应用于相对内存量较大、更强处理器的移动设备,它要求微处理器或者控制器为32位,并有网络连接,大多用CVM虚拟机,其用户接口较多,所以有很多不同的简表。而其最大的特点就是支持浮点数。包含了所有CLDC中定义的类和接口。如银行的POS机、车用计算机和机顶盒之类的高端设备。

而CLDC则主要用于资源较小的、更轻便、更便宜、不能满足CDC要求的小型设备中,采用KVM虚拟机。其特点是很多J2SE的类和接口没有实现,最大的特点就是不支持浮点数,比如手机及PDA等。

3.3 简表Profile

简表Profile是构建在配置层之上的一层类库,它比配置的针对性更强,提供配置层中所缺失的功能,以支持特定的设备,这些功能包括对UI、对持续性存储的支持等。简表层提供了应用程序级的接口,应用程序就建立在简表层上,一个配置可能会有好几个简表,也就是说,一个设备可以支持多个简表。

下面介绍几种主要的简表:

(1)Foundation Profile。主要用于CDC,其虚拟机几乎等同于标准的虚拟机,因此可以访问完整实现的J2SE特性集。不过没有GUI的支持。

(2)Personal和Personal Basis Profile。Personal Profile用于Foundation Profile上层,提供对GUI的支持。Personal Basis Profile相对于Personal Profile更小,针对与设备要求更简单的GUI场合。

(3)RMI Profile。位于CDC的Foundation Profile上层的Profile,以支持RM(Remote Method Invoke,远程方法调用)。

(4)MID Profile。CLDC为那些资源受限、不足以支持整个J2SE虚拟机环境以及J2SE核心类库的设备提供了运行Java程序的基础。然而作为一位应用程序开发者,如果只能通过CLDC提供的API来进行编程集合是不可能的,因为CLDC中并没有提供与用户、存储设备、网络直接交互的工具。CLDC是一个基础层,其上层可以架设一系列的简表层来提供CLDC所缺失的功能。每一种Profile被设计成适应某种类型设备的形式,而移动信息设备简表就是这些Profile中的一种。

3.4 可选包Optional Package

在配置(CLDC或者CDC)和相关简表的基础上组合不同的可选包可以对KJava进行扩展。可选包通常是为了满足特殊的时常需求,如蓝牙、无线消息服务和Web服务。可选包是模块化的,设备制造商可以有选择地把它们添加到自己的Java平台,这将大大丰富设备的特性。

3.4.1 无线消息API(Wireless Messaging API,WMA)

开发者可以使用WMA以平台无关的方式访问无线通信资源,例如短消息服务。WMA2.0还为无线消息增加了发送多媒体信息的功能。

3.4.2 移动多媒体API(Mobile Media API,MMAPI)

MMAPI在资源受限设备上提供了音频、视频和其他基于时间的多媒体文件的支持。作为一个简单、轻量级的可选包,MMAPI允许开发者访问目标设备上本地的多媒体服务,例如,调用设备上的摄像头捕获图像。

3.4.3 PDA简表

PDA简表由两个部分组成,分别是FileConnection和PIM。其中FileConnection为KJava提供了访问手机文件系统的编程接口。PIM(Personal Information Management,个人信息管理)提供了访问用户个人信息的编程接口,通过PIM可以访问用户的通信录、日程安排等私有数据。

3.4.4 蓝牙API(Bluetooth API,BTAPI)

BTAPI提供了一系列开放的、标准的API,使用这些API可以开发出使用蓝牙通信的应用程序。设备需要同时实现蓝牙API和蓝牙技术才可以运行此类应用程序。

3.4.5 Web服务API(Web Service API,WSA)

WSA使得KJava设备可以作为Web服务的客户端访问Web服务,同时还提供了与标准Web服务一致的编程模型。

3.4.6 移动3D图形(Mobile 3D Graphics,M3G)

它的目标平台是基于CLDC的KJava。开发者使用M3G可以在资源受限设备上开发3D图形的应用程序,这当然少不了Java 3D游戏。由于M3D需要浮点数运算的支持,因此需要的最小配置是CLDC1.1。

4 开发技术

KJava平台的CLDC、MIDP规范规定了手持移动终端的所有基本特征,保证了应用程序在各个终端上的可移植性和兼容性,为广大软件开发商提供了统一的开发平台,从而使KJava获得了广泛的应用。现在市场上绝大多数手机的配置是CLDC1.0+MIDP2.0,但由于使用支持MIDP1.0的手机用户太多,所以现在主要还是使用CLDC1.0+MIDP1.0作为开发平台。因此以MIDP应用程序为例,如图2 KJava应用程序开发过程,简要介绍一下KJava应用程序开发过程。

MIDP应用程序源代码的编写可以在PC机上面进行,然后再把应用程序转换成可以在嵌入式设备上运行的二进制代码,这一过程包含3个步骤:编译、链接和定址。编译后形成类文件形式,经过类文件的验证(验证是否有不符合KVM规范的方法调用等)后,被链接成一个目标文件。定址过程会把物理存储器地址指定给目标文件的每个相对偏移处,该过程生成的文件就是可以在嵌入式设备上执行的二进制文件。完成手机程序的编写后,先要将程序上传到仿真器上进行调试运行和修改工作,直到该软件达到了预期的效果后再上传到实际的设备中试运行。

MIDP的核心是一个MIDlet应用程序,这个应用程序继承自MIDlet类,而MIDlet类是提供了运行时环境和MIDlet应用程序之间的接口。在开发MIDP应用程序时必须要利用CLDC/MIDP所提供的AIP,利用SDK所提供的Java编译工具将写好的程序代码进行编译,得到字节码。因为多种Java平台的源程序都使用标准版本的JDK编译,但不同平台支持的AIP和安全特性又不同,为保证装到设备的类符合特定规范,KJava采用更加紧凑,更加有效的两阶段校验机制对编译产生的字节码进行审核,这个机制是要确保所有下载的Java类文件都是正确的,不会进行有安全顾虑的行为。第一个阶段称为预先验证。第二个阶段在CLDC设备中执行,因此也被称为设备内验证。

5 技术应用

目前,国内外越来越多的厂商在SUN公司、摩托罗拉、西门子等公司的技术支持下,已经开发出基于KJava的无线应用服务,这些服务可以让用户使用移动设备像使用桌面电脑一样方便,使得所有现在固定Internet上的服务与应用,都可以应用在移动网络上。比如:FTP、浏览网页、聊天、Email,乃至获取实时股票报价或最新货币汇率等等。

这些应用虽然很多,但大致可被分为两类。一类是单机版,下载以后不需要再和网络通信,比如单机游戏等。另一类使用时需要和网络进行通信,比如移动商务和电子定位等,这类应用需要基于KJava十J2EE解决方案,将移动设备上的客户应用与后台J2EE服务环境结合起来。在此方案中,移动设备充当客户端和浏览器,工作在KJava平台,服务器工作在J2EE平台。KJava和J2EE的结合使建设一个无线接入的企业网络成为可能,任何时间、任何地点的自由访问不仅扩大了企业市场影响力,提高了客户服务水平,而且降低了企业运行成本。

除了上述典型应用外,KJava还可与其他技术结合以实现特殊需求。例如,在开发基于多Agent的智能家居系统MAIHS时,就将KJava技术与Agent技术相结合,实现了系统中负责各项控制功能的智能Agent。此外系统也是借助于KJava技术实现了远程认证和监控功能。

6 结语

KJava把Java平台的以网络为中心和平台不可知论的特性移植到存储器和处理器受限的设备中,成为嵌入式领域强大的开发工具。它能使服务提供商、设备制造商、用户通过无线网络进行连接,根据需要随时随地使用丰富的应用程序。利用KJava技术编写的应用程序开发和部署具有很高的灵活性。此外,KJava应用程序还可被轻松升级扩展至J2SE和J2EE平台。

摘要：KJava是一个移动终端运行和开发的统一平台,提供对越来越多的移动应用的支持。介绍了该技术的体系结构与功能优点,以及其应用程序的开发步骤,还对其应用领域及相应解决方案进行了简单分析。

关键词：KJava,移动服务,KJava开发技术

参考文献

[1]戴丽萍,李磊,许永辉,等.JavaME手机游戏开发从入门到精通[M].北京:国防工业出版社,2009.

[2]詹建飞.Java ME核心技术最佳实践[M].北京:电子工业出版社,2007.

移动应用的架构设计 篇5

随着移动互联网的发展以及智能手机的普及, 人们以往的电脑生活已逐渐被手机生活所取代, 而传统的办公应用系统也逐渐拓展到移动终端。但随着App时代的快速发展, 问题逐渐暴露, 第一, 手机应用逐渐泛滥, 手机桌面变成图标海洋, 同类型的应用重复下载, 造成手机“负荷”加重;第二, App的激烈竞争推进应用的不断改版, 同时导致了频繁的更新版本提示, 加重用户的排斥感;第三, 多种业务应用之间的相对独立, 导致用户在图标海洋中重复切换, 造成事务处理低下, 信息混淆。

本文针对移动办公的集中化进行了研究, 并推出基于混合架构的移动AIO应用平台 (All in One, 一体化平台;简称“移动AIO”) , 该应用支持不同业务应用的整合, 满足多种任务的集中处理, 采用Web App+Native App的混合型架构, 摆脱传统手机应用的各种难题。

2 移动办公一体化混合应用的架构设计

移动办公一体化是将企业的各种业务应用集成在一个客户端, 实现单点登录、集中办公、统一处理的平台。系统采用了本地应用+网页应用 (Native App+Web App) 的混合架构模式, 即通过简易的UI Web View访问具备业务功能的Web App, 有效地让Native App和Web App形成互补, 各显优势。

2.1 混合架构应用的必要性

移动AIO是集成Web App的平台, 通过该平台, 将不同的业务性系统整合到一个入口, 形成一个面向政企业务的针对性平台。考虑到平台的移植性、跨平台等核心特性, 通过对Native App和Web App的应用模式的对比, 选择了混合模式并得出结论:虽然Web App是设计者和开发者所期待的理想化结果, 开发成本低、轻松跨平台、迭代更新快, 但Native App也是现阶段用户更依赖的用户体验, 对于移动AIO而言, Native App+Web App的混合型应用Hybrid App是更好的选择。三种App的对比见表1。

2.2 Native App+Web App的混合架构设计

Hybrid App虽然看上去是一个Native App, 但其实有一个Web View, 里面访问的是不同的Web App。移动AIO平台的架构如图1所示。

移动AIO分为客户端和服务端, 服务端提供应用的接入功能以及其他配置管理功能, 客户端通过Native App运行, 上层展示平台界面, 并提供网页视图 (浏览器) , 下层则提供语音、定位等业务能力。用户访问平台时发送请求, 由服务器提供数据并返回客户端的Web View来显示。Native App实现基础功能, 而嵌入的Web View实现Web App的展现, 包括OA系统、新闻中心、车辆管理等子系统。在这种结构中, 对于侧重性能、体验、设备特性、本地数据管理的部分, 采用Native的方式, 其余的部分采用Web方式, 如核心的业务性功能。这样可以有效地形成互补, 即发挥本地应用的优势, 又能有机地整合后端资源。

移动AIO通过Phone Gap框架令开发者用普通的Web技术编写出能够轻松调用API接口和进入应用商店的HTML5应用, 并且兼容Android、i OS等系统, 从一定程度上实现跨平台和终端设备, 而且更容易迭代更新版本, 避免了用户手动的频繁更新。

2.3 移动办公一体化集成的应用接入

移动办公应用的一体化集成可以使用户直接到达内容本身, 令用户大量的长尾需求能够更方便地被满足, 从根本上解决政企单位信息分流、信息独立的问题;而子应用的随意搭配更满足了不同政企单位对业务系统的个性化需求。移动AIO的接入适用于各种类型的移动Web应用, 集成的过程均可由企业管理员手动完成, 个性设置后即时可在客户端展现。

2.3.1 移动Web应用接入设置

移动Web应用的接入通过后台服务端来完成, 即使是业务独立的Web应用, 通过少量接口规范和改造, 便可集成到移动AIO。

移动AIO的Web App接入过程如图2所示。

(1) 规范Web App:遵循规范标准进行对接改造, 以便接入后保证数据管理、用户体验的统一性。

(2) 站点接入:在服务端设置需接入的Web App的站点地址。

(3) 参数设置:设置Web App的应用名称、Icon、简介等基础信息。

(4) 完成配置:配置完成后, 便可在客户端查询到对应的应用入口, 同时移动AIO将该Web App产生的待办工作、待阅工作、消息等统一呈现, 并可及时通知用户。

2.3.2 移动Web应用接入规范

对于支持集成接入的Web应用, 系统提供了一套规范标准, 只要开发商按照指定的标准开发, 便可以轻松接入移动AIO, 具体接口见表2。API规范、数据架构规范和UI交互规范是接入移动AIO的核心要素。开发者可根据具体业务需求参照规范开发功能以便于平台与应用的统一管理。

3 移动AIO在办公产品中的应用

政企客户信息化统一门户是基于PC端的协同办公自动化信息管理统一平台, 包括企业OA、车辆管理、报销管理、物资管理等业务类型不同且相对独立的应用系统。随着移动互联网的发展, 该平台通过移动AIO平台完成应用集成, 陆续推出对应的移动Web App, 实现信息随时随地管理, 见图3。

移动AIO不仅令应用摆脱Web App的浏览器体验的限制、消息推送不及时等束缚, 而且实现了不同应用的任意接入、集成, 支持政企客户的个性化业务需求, 还能轻松满足一键登录、集中办公等需求, 在政企信息化领域将移动办公推上更高的层面。

4 结语

移动应用的一体化是对日趋丰富的业务应用的整合和管理, Hybrid App使Native App能够和网页信息流之间真正互通, 令App保留“优良基因”的同时, 摆脱繁重的安装文件, 使日常办公事务简洁明了。一体化的概念更不仅仅局限在移动办公, 更是未来的移动互联网的发展趋势, 实现“去应用”、全业务一体化应用, 这对整个移动互联网的发展意义重大。

参考文献

[1]李慧云, 何震苇, 李丽, 等.HTML5技术与应用模式研究[J].电信科学, 2012 (05) :24-29.

移动应用的架构设计 篇6

随着人口流动呈常态化, 交通便利, 社会治安形势日趋复杂, 特别是各地暴恐案件的多发突发, 对公安警务工作模式的变革提出了要求, 迫切需要建立新一代的巡逻接处警和指挥调度模式。

近十年来, 公安各业务工作基本实现了信息化, 特别警务信息综合应用平台、警用地理信息平台 (PGIS) 、图像信息综合应用平台、移动警务平台等平台系统的建成[1], 使公安日常警务工作中产生了大量的业务信息数据, 同时“部门间信息共享平台”整合了大量的外部数据资源。这些为改进110电话接处警系统提供了技术和数据基础。下面介绍运用视频监控技术和移动警务技术, 对现有相关业务系统和海量数据进行资源整合, 构建基于视频监控的移动巡逻接处警系统。

2 总体架构设计

基于视频监控联网系统, 利用PGIS/GPS定位、移动警务, 将处警应用、监控视频、智能检索、人像识别、移动警务等应用进行整合, 建设一套综合受理110/119/122报警和处理警情及巡逻任务的移动巡逻接处警系统。系统总体架构如图1所示。

2.1 系统组成

(1) 网络:运营商公网、接入区网和公安内网共三个区域。三家运营商公网通过三根专线将报警电话的位置信息经过接入网关汇集到前置定位服务器。移动警务系统所用网络是通过VPN技术在运营商公网上建设警务专网。接入区网是为了确保运营商公网的数据能实时传输汇集, 再经由安全边界接入平台单向导入公安内网电话定位服务器。[2]以避免安全边界接入平台的延迟问题, 并通过接入网关汇聚三家运营商的网络和控制网络访问权限。

(2) 巡逻接处警服务器:部署巡逻接处警系统, 系统整合移动警务系统、PGIS、警综系统、位置服务系统、110接处警系统、视频监控系统、报警定位系统、人像识别系统、请求服务系统、短信系统等多个业务系统。[3]包含:接处警、指挥调度、移动处警、警情热点、巡逻排班、应急预案等功能模块。

(3) 电话定位服务器:运营商将报警号码、移动警务号码等位置信息 (含经纬度信息或固定电话开户信息) 实时推送到前置电话定位服务器, 再经由安全边界接入平台单向导入公安网内的电话定位服务器, 以供巡逻接处警系统调用。

(4) MQTT服务器:消息队列传输服务器, 集成系统与移动警务终端之间的消息收发传输服务。

(5) 视频服务器:全省联网的视频图像联网平台, 通过调用视频服务器可全省的视频监控图像、会议终端等各类视频图像资源。

(6) 数据库:包括巡逻数据库 (移动警务手机即时位置数据、移动警务手机轨迹数据、移动警务手机状态信息数据) 、110警情数据库、警员数据库 (机构信息及警员信息数据) 。

2.2 数据交互流程

电话定位数据流:报警人通过电话拨打110;前置电话定位服务器针对每次报警将报警人的号码和接警坐席号码传输到电话定位服务器;巡逻接处警服务器将轮询电话定位服务器中的数据, 获取到新的报警信息推送到对应的坐席;巡逻接处警服务器通过调用定位服务器接口查询定位信息, 并把结果推送到接警台。

前置电话定位服务器与电话定位服务器交互采用基于TCP/IP、UDP/IP协议栈的Apache Mina S e r ve r网络通信应用框架, m i n a提供事件驱动、异步 (mina的异步IO默认使用java nio作为底层支持) 操作编程模式, mina同时提供了网络通讯的se r ve r端、cl ient端的封装, 前置电话定位服务器与电话定位服务器通过Mina建立session通道传输数据, 电话定位服务器再将号码信息通过comet发送到前置电话定位服务器, 以便让前置服务传送到运营商进行号码定位。

电话定位服务器与巡逻接处警服务器交互采用web推送技术的comet网络推送框架, 使用H T T P长连接作数据传输通道, 电话定位服务器在其数据发生变化时comet主动以异步的方式向巡逻接处警服务器推送数据。前置电话定位服务器与运营商交互采用TCP/IP网络通信协议。

2.3 数据安全及靠性性设计

为确保数据在移动警务接入网和公安内网之间传输的安全性, 确保数据库服务器和关键应用服务器的高可用性和可靠性。针对每个电信运营商都有一台前置接口服务部署在前置电话定位服务器, 前置接口服务部署在刀片服务器集群构成的V Mware v Sphere虚拟化平台上。数据库采用2个节点的Oracle RAC, Web应用程序部署在VMware v Sphere虚拟化平台上, 利用V Mware v Sphere H A的高可用确保应用系统的高可用和高可靠。前置接口程序通过移动警务VPN专网写入数据库, 电话定位服务器与前置电话定位服务器通过读写和监听数据库完成交互。移动警务VPN专网经省厅安全边界接入平台接入公安网, 可配置策略, 限定可以访问数据库的前置接口服务器。电信运营商定位平台与前置电话定位服务器绑定, 确保别的机器无法访问。

系统各个接口程序采用资源访问控制, 资源访问控制分为服务端和客户端访问控制两个层面。接口程序既是服务端也是客户端。对于电话定位服务器而言, 前置接口程序是客户端, 所提供的操作界面仅仅显示接口调用信息, 而不提供执行定位的功能组件和操作界面, 使得前置接口程序只能通过A PI调用。对于后置接口服务器而言, 前置接口服务器是服务端, 程序具有鉴权功能, 服务端的每次调用都必须通过鉴权。后置接口程序的设计也是类似的, 只是后置接口服务器对于前置接口服务器而言是客户端, 而对于Web服务器而言是服务端。

3 系统功能

本系统通过对巡逻和接处警信息的采集录入、排班, 结合PGIS/GPS车载及单兵定位系统, 实现扁平化指挥和快速警力调度。系统将警员巡逻、接处警、人事情况、执勤装备、执勤警务区等信息统筹安排。通过移动警务系统, 随时可查看警情现场视频, 提高各警务部门的快速响应和协同处理能力。[4]系统主要实现报警接入、接警台接处警、警情热力分布、巡逻排班、应急预案、移动警务终端处警等六大功能。

(1) 报警接入。作为系统的预处理模块, 与现有报警平台接口对接, 过滤出报警电话生成警情, 供后续派警等处理流程。功能包括电话上下岗功能、报警电话过滤、短信报警、人工报警、电话定位服务器报警。

(2) 接警台接处警。处理接处警各个环节的工作, 实现警情从始至终的全程跟踪, 实现接警员高效派警、实时掌控警情状态以及事后查询警情等。功能包括指定派警、周边警力派警、多警员派警、警情通知、单位派警、电话派警、人工警情派警、摄像头视频查看 (图2) 、摄像头视频的绑定及推送、视频自动上大屏等。

(3) 警情热力分布 (如图3所示) 。通过抽取警综平台的案件数据和本系统采集的警情, 可对警情和案件发生的地点频率形成点密度热力图, 将这些历史案件的热力图上图后可以为案件分析提供历史参照和对比依据。通过对警情在地图上的直观展示, 可以方便的了解辖区内警情发生的类别、发生的地点等情况, 方便对辖区警力部署及联防布控等措施提供科学根据。

(4) 巡逻排班。根据警情热力分布情况, 以及辖区民警实际情况, 制定民警的巡逻时间和巡逻线路, 使巡逻更有针对性, 民警在巡逻过程中打卡, 可监督民警工作, 提高工作效率。

(5) 应急预案。为重大案事件制定快速行动预案, 大大的节省了将警情传达到大批量的作战民警所需时间, 提高了响应速度。

(6) 移动警务终端处警。民警使用移动警务终端处理与查看警情信息。确保处警过程高效、处警过程中的协作、处警反馈的有效, 以及处警过程中对指挥中心的可监控性。功能包括:处警状态回传、处警员即时位置信息上传、联系报警人、查看视频、警情通知、领导终端派警、多人处警的协调、处警在线查证、处警人像比对、处警预案、信息采集、处警反馈、警情退单、巡逻打卡 (如图4所示) 。

以群众报警为例, 其业务流程为:

(1) 110中心接警人员接到报警后, 将警情录入系统, 接警员通过系统从电信运营商获取报警人员的坐标, 并通过PGIS平台接口把相关的报警地点展现在接处警客户端上, 同时显示周边相关的摄像头信息、警力分布信息, 进一步还可以通过警综平台查询报案人关联信息, 调用视频服务器接口调用安发地点附近的监控摄象头信息, 推送警情给处警民警。

(2) 处警人员通过移动警务终端通知接警员已经出发, 到达现场后, 对现场进行拍摄把相关的警情以文本、语音、图片、视频等方式反馈给接警人员。

(3) 接处警中心把相关的警情信息发送到值勤警员的移动警务终端。

(4) 接处警中心通过值勤警员的移动警务终端收集各种处警信息, 如现场视频图像、巡逻轨迹、辖区案件数据、案件处理情况等。

(5) 辖区负责人通过巡逻接处警系统实时了解辖区内的警力分布情况, 对警力进行调整优化或设定触发条件自化警力优化, 如案发频率、警力配比、案件级别等触发条件。

4 系统性能特点

系统在河池市公安局试点应用半年期间, 每日使用系统进行巡逻排班、接处警和指挥调度工作, 已经接警四万多起, 处理有效警情八千多起。从应用情况看, 系统有以下特点。

(1) 接警信息更精确和丰富。接警人员接到报警后, 从电信运营商获取报警人员的基本信息、定位数据, 通过PGIS快速定位报警人位置, 更准确了解事发地点的地理信息及周边警员、警车、摄像头分布情况。可调用周边摄像头, 了解事发地点的实时情况, 接警员可将文字、视频等警情内容推送到周边警员的移动警务终端, 还可通过PTT群组对讲快速调动警员安排处警。

(2) 处理警情更及时、反馈信息更客观和全面。处警员通过移动警务终端接到警情后, 根据接警人员推送过来的定位、视频等信息, 快速出警。处警员到达事发地点时, 在移动警务终端上的PGIS地图上标注更准确的事发地址, 拍摄现场图片、视频、处理结果回送给指挥调度中心, 实时反馈处警信息。实时了解周边可以协调的警力, 道路情况, 处理警情更及时、更透明反馈信息更客观和全面。

(3) 指挥协调警力更高效、更灵活、更科学。处警反馈的信息更全面、更客观、更实时, 所以能根据案件类别、重要程度有选择的把案情推送给各级领导, 各级领导层亦能通过移动警务终端或在指挥中心随时随地的对辖区进行更精确的把控, 还可以了解历史或当天辖区内的案件数量、已经处理、正处理、尚未处理的各种案件信息。系统通过可视化的方法, 展现各种警力资源, 达到全方位一体化的指挥决策。

(4) 更科学合理部署巡逻警力。系统提供历史警情的查询功能, 在PGIS地图上通过不同染色展示警情热点区域, 以便民警快速了解辖区内案情发生数量及警情高发区域, 以更科学合理地根据热点区域增配巡逻警力;通过PGIS和GPS技术相结合, 可把警员和警车的行动轨迹在电子地图上显示出来, 对警员及警车的历史轨迹进行收集, 对警车的巡逻区域进行记录标识, 结合警情热点区域, 对巡逻区域和线路提供更科学的决策参考。

(5) 资源整合、减少重复工作、业务能力提升。系统通过整合警综平台、图综平台、110平台、PGIS平台的资源, 减少系统之间交互信息的重复手工工作, 进一步的提升业务能力。

(6) 系统角色清晰、推送信息更准确。系统角色分类清晰、权限访问分类明确, 依据警情性质准确把信息推送给民警, 形成以民警为中心的信息推送方式。

5 结束语

基于视频监控的移动巡逻接处警系统, 通过整合了当前已建设的业务系统, 丰富了巡逻接处警工作的技术手段, 特别通过视频可随时查看现场警情, 极大方便了沟通、取证等工作, 提高了工作效率和能力。但其他系统稳定性直接影响到本系统的稳定性, 整合系统越多其可用性越低。[5]整合多系统数据资源, 数据得到了综合利用, 但是各系统的数据质量将严重影响到本系统的业务应用。在试用本系统过程中呈现出了系统稳定性和数据质量控制上的不足, 下一步如何在这两方面改进, 是一个系统性的问题, 包括技术标准规范制定和确保标准得以执行的机制体制。

参考文献

[1]粟雪丹.基于SOA架构的社区警务管理系统研究与实现[D].湖南大学, 2014

[2]陈浩鑫.城市治安视频监控系统设计与实现[D].湖南大学, 2014

[3]李昌忠, 周大良, 王生, 余兵.基于PGIS的社区警务管理系统研究和实践[J].现代测绘, 2010.5.P24-P26

[4]李艳芳.基于PGIS平台的新型自动化勤务管理系统的设计与实现[J].警察技术, 2011.5

移动应用的架构设计 篇7

受三星鹏泰公司委托,我公司为其开发一套基于现有E-Learning平台的Android手机客户端在线学习系统。我作为项目经理兼设计师主持了该项目各项工作,项目成果“M-Learning移动学习客户端”于2011年10月05日上线正式运行,该软件主要为三星公司全国促销及渠道人员提供各类移动设备技术和销售方面的培训服务。

2 系统架构

2.1 逻辑结构

本系统总体采用B/S架构,服务器端有数据存储模块、文件存储模块、E-Learning模块、M-Learning服务模块。客户端分为两部分:一部分是已有的电脑端在线学习功能模块,另一部分是Android手机客户端模块。其中手机客户端模块是本次开发的重点,它与服务器端的“M-Learning服务模块”实现各类数据交换及文件交换。这些数据交换功能既有B/S结构形式的程序实现,又混合着C/S结构的程序实现。而M-Learning服务模块与E-Learning模块很多数据实现了共享,例如:课程数据、试题试卷数据、每日应用推荐文件等。

2.2 部署结构

服务端由两台PC服务器和一个磁盘阵列组成,一台PC服务器提供Web服务和流媒体服务,上下载带宽为100MB/s。另一台PC服务器安装了Oracle10g数据库软件,提供数据存储服务,此服务器安装了Linux操作系统主要是考虑保证提供较高的数据访问并发性指标;磁盘阵列500G,用于存储数据库文件、培训资料文件等重要数据,采用集中备份策略。Web服务器对外提供80端口http服务、21端口ftp服务及554端口流媒体服务,其中apache负责接收处理80端口请求数据和实现动静分离,以提升系统对外服务性能,weblogic负责解析jsp及servlet请求、处理后台业务逻辑及数据存取;DB服务器没有外部IP不对外提供服务,而只与Web服务器通过内网相连,保证安全性,如图1所示。

3 设计与开发

3.1 设计思路

首先,使用Axure工具进行原型设计,原型可以模拟简易的UI样式、内容展示和操作顺序,给客户方讲解功能如何实现比较直观。然后由美工针对典型页面设计效果图,设计出来再与客户方确认。与此同时设计模块逻辑结构和交互方式、接口格式。

3.2 客户端设计

3.2.1 针对不同操作系统版本、不同分辨率

由于采用了OS版本自适应算法、分辨率及横竖屏自适应和不同机型自适应算法,这个app不区分HD版和普通版,平板手机都可以安装、大屏小屏不同分辨率都可以自适应显示。

3.2.2 针对UI占用太大空间

由于客户端功能数量较多,页面图片也较多,如果每个布局和分辨率一套图片,那么apk文件大小将达到50M,因此采用了Android规范UI设计,通过较少的、符合UI规范和格式(PNG)的图片就可以适应绝大多数机型和分辨率,做到最小失真。最终的程序包大小稳定在5M左右,更新下载安装很方便快捷。

3.2.3 针对手机学习特殊性而进行的课件格式

由于在线培训所涉及的课件较多、较大,在手机中观看遇到的直接问题就是屏幕小、流量少、网速慢。如何解决这个问题?采用下述方法:首先,将较大的scorm课件进行精简,多余篇章直接去掉,有些篇章内容进行压缩,制作成flash格式小课件。这样一来,课件文件大小减少了、字体按钮都变大了,适合在手机屏幕播放和点击操作,在提高了流畅度的同时也大大减少了下载流量。

3.2.4 针对程序和内容文件分离

由于产品介绍内容是不定期发布的,促销员会经常打开观看,因此采用离线下载方式节省流量、提高流畅度。Apk程序和产品zip文件分离,apk中只包含数据库和程序,产品介绍内容打包成zip由apk运行时自动检测下载,每个zip都在1M-3M之间。每个产品介绍内容之间也都是分离的,这样实现了单个产品信息被管理员修改后手机客户端可以局部更新下载节约流量。

3.3 系统实现

手机客户端的开发不同于传统B/S架构系统开发,主要在于服务器端程序开发人员与手机端程序开发人员需要及时和准确的沟通,需要多次试验并最终确定功能实现方式;手机开发人员还需要与美工进行大量沟通、尝试修改工作,以试验10多种不同分辨率、尺寸和型号手机的显示效果,同时也需要试验不同操作系统版本,检查样式问题、内存使用问题等。产品的开发过程采用演化模型法,即针对核心功能先开发出来试验效果,及时给客户演示并听取修改意见。经过多次修改完善,手机客户端程序包含所有功能演化到最终版本。

4 功能介绍

4.1 E-Learning

该部分为基础系统,主要功能模块:系统管理、数据管理、资源管理、培训实施、报表管理、网站发布管理、在线学习、在线考试等;其中在线学习和考试为学员角色具备的功能,学员可以使用电脑连入互联网实现在线学习课程、在线答卷考试。

其中,数据管理模块中的企业机构数据、人员数据和岗位角色数据,资源管理模块中的课程数据及课件文件、试题试卷数据、应用推荐数据和文件在M-Learning服务模块中进行了复用。

4.2 M-Learning

该部分为系统扩展开发部分,分为服务器端和手机客户端。服务器端提供服务:登录验证、检索在线课程及考试数据、记录手机学习信息和手机考试信息、提供应用推荐下载、培训管理和培训报表填写上报、通知信息编辑和发送等。

手机客户端功能(图2):产品介绍模块、行业知识模块、应用推荐模块、在线学习模块。

产品介绍模块(图3-图5):该模块以信息推送形式为三星全国促销员提供最新、最准确的产品信息。当促销员打开app后,客户端自动检测网络,如果连接网络则与服务器进行数据同步。当发现有最新的三星电子产品(例如Note2、Galaxy S4)发布时,自动提示是否下载最新产品资料。每个产品资料文件zip约1-3M,包含“产品介绍、如何给顾客讲解、产品配件信息、与竞争机型的对比信息、短视频资料”。当选择下载后,app程序进行后台下载、自动解压并更新手机内的产品资料数据库信息。再次进入产品介绍模块后,显示最新产品图标“NEW”:点击进入查看详细产品资料。通过分类按钮可以切换到“智能手机、智能平板、智能迷你本”等不同机型。

行业知识模块:该模块以信息推送形式为三星全国促销员提供最新、最流行的行业知识。其形式与产品介绍模块类似,栏目有所不同。展现形式为书架,可以上下滑动,点击图标进入。其子栏目可以由管理员自己配置,一般为1~3个。

应用推荐模块(图5):该模块是最简单的一个模块,其主要是为促销员可查看最新应用程序,并直接下载apk进行安装。展现形式为多级列表+详情介绍页面。其页面内容都在服务器端生成,而不是下载到手机本地后用内嵌浏览器打开观看,因此该模块的功能调整和页面修改不用客户端下载更新包更新。

在线学习模块(图6):该模块是最复杂的一个模块,其主要功能为:在线学习、资料下载、在线考试、SNS互动社区、讲师管理培训项目与学员参与培训项目。另外,管理员手机端管理功能包括:讲师管理、通知管理、培训报表。其中SNS社区是电脑Web版本的简化版,主要是方便手机小屏幕浏览和互动操作。SNS社区主要功能为:心情、日志、投票、相册,通过客户端可以互动交流、分享照片。

5 遇到的技术问题及采用的关键技术

5.1 技术选型

在开发过程中不断会遇到技术选择,在解决内容浏览方式的问题时,由于当时(2011年)HTML5技术还不太成熟,因此在技术选型中未选择HTML5技术。在课件内容是选用MP4还是flash的时候,我们考虑到观看流畅性和手机下载流量,最后仍采用了flash形式。Android新版本发布后采用了变通的方式实现了flash在3.1、4.2以上版本流畅播放。

5.2 问题举例

问题一:高版本Android系统内嵌浏览器不支持flash。由于flash存在安全漏洞问题、费电问题,Android新版本的内嵌浏览器chrome不再支持flash。在课件播放模块需要用到内嵌浏览器播放在线课件,课件形式为flash。根据技术分析的结果,不同Android版本采用了不同的打开策略:2.3-3.0版本采用内嵌浏览器直接打开课件,3.1-4.2及以上版本采用弹出手工选择第三方浏览器(UC支持flash播放)方式打开课件。两种方式都不影响播放质量和学习计时功能。

问题二:功能界面较多与开发工期不足之间的矛盾。根据功能特点分析,我们将一部分功能使用内嵌浏览器本地打开或远程打开方式,模拟B/S的通用方式。这样,功能界面可以由普通界面开发工程师完成,功能调整也比较方便;需要流畅操作的功能或页面由开发Android原生程序的手机工程师完成。我所采用的方式得到了客户的同意,同时节约了开发成本和工期(手机开发工程师成本远高于普通界面开发工程师)。在后期系统维护工作中也得到了很好的效果:apk不用频繁修改和下载重新安装,而只需要修改服务器端的jsp就可以实现界面更新。

问题三:数据接口设计非常关键,因为该系统采用的是B/S和C/S混合方式,接口数量多且复杂。考虑到为了减少以后的变更难度,部分固化接口采用JSON格式数据通过Servle收发;部分与更新相关接口采用配置文件方式,文件内容格式可以随意配合手机端程序更改,而不用修改服务器端程序。

以下是手机客户端各功能模块所采用的关键技术一览表,如表1所示。

6 结语

移动应用的架构设计 篇8

1.1 模型驱动体系结构(Agent)与面向服务体系结构(SOA)

模型驱动体系结构是软件开发方法上的革新,它源于解决重用和需求变化的问题。比较成熟的重用有二进制代码级(这里将Java字节码及.NET的中间代码都认为是二进制代码一级),源代码级两种层次,其中二进制代码级含主要是系统函数库和应用函数库[1]。随着应用的发展,又出现了粒度较大的类库以及粒度更大的组件库。二进制代码的重用粒度不断变大的趋势实际上反映了IT技术不断向应用需求靠拢的趋势。从源代码级来说,开源软件的发展使其有了更强的生命力。但是,从实践中看来,开源软件的源代码级重用比二进制级的重用需要耗费更大的工作量。此时,重用并没有摆脱物理形式的束缚,从逻辑上将更有价值的设计面重用起来,而设计往往才是高层次软件重用的关键。

设计层的重用一直以来受到限制的原因之一是没有通用的设计表达方式,各种软件设计采用不同的表达符号体系是导致重用困难的原因之一。正是因为没有统一的符号体系,所以也很难发展出通用的辅助设计工具。自从UML出现以后,这个问题在很大程度上得到了缓解。模型的表达有了广为接受的方式,大部分的常用设计元素都可以用UML的元素来表达,这是UML最为成功之处。随着UML推广,各种自动化工具也相应产生,其中最为著名的是IBM的RationalRose,它实现了UML图形表示到多种语言的自动映射功能。

但是UML也面临特定领域的优化和扩展问题,比如用于嵌入式实时领域的实时U侧比,就需要扩展更多的关键元素。为了解决设计重用的问题,也为了解决中间件之间的互联互通问题,OMG提出了一个元层解决方案,即模型驱动体系结构。MDA的核心在于其“元”层的思想,有了元层,整个体系就具有了无限可扩展性,这是MDA不同于其它技术的地方。基于MDA的软件开发生命周期如图1所示,其中把平台独立模型PIM转换成一个或多个平台相关模型PSM是MDA开发过程中最复杂的一步。

MDA是模型驱动体系结构,而SOA是面向服务体系结构,那么,两者之间的联系究竟是什么,为了解决这个问题,SLN.公司从企业计算的角度作了一个从应用出发的专题研究[2]。而从开放系统中间件的角度来看,SOA是为了解决更大粒度的重用所提出的概念,只不过,所采用的技术变为服务,而结构采用了三方模型而已。

传统的组件和对象级重用较为强调重用粒度和互通互操作性,而作为企业计算来说,更加强调敏捷性和跨企业互通性。这就需要更大粒度的重用。此时,组件己经不能满足需要,服务作为更大粒度的组件被提了出来,而且其使用方式上十分强调三方模型。

所以,MDA和SOA都是为了解决重用问题而出现的,而MDA强调模型重用和自动开发过程,SOA强调大粒度重用和跨域协作。它们都反映了敏捷性,敏捷性实际上与IBM按需计算是一个思想。即软件可以按照需求的不同而快速变化重组[3]。从而避免需求的变化导致软件的大规模重写。总结一句,可以将重用、动态、敏捷、模型的关系概括如下:动态必须有重用的支持,而敏捷则必须以动态为基础,模型则是设计层的重用。

1.2 服务组合中的模型方法

服务组合作为服务计算中的重要元素,其有效运行是服务计算动态性和敏捷性得以实现的保证。对服务组合建立模型是学术界和工业界一直共同努力的方向。其中有借鉴原有成果如UML为组件建模的,或者新辟描述语言如WSBPEL和WSCDL的,还有结合UML与WSBpEUWseDL的,都取得了一定的成果。

但是,服务组合必须用严格的形式化方法加以验证,才能保证服务组合的正确性和可验证性。

模型有形式化模型和非形式化模型以及半形式化模型的区别,如:U L就是一种半形式化模型,它定义了符号系统,但是没有定义推理规则;而诸如进程代数和Petri网等就是典型的形式化系统。

2 基于Pi演算的驱动服务组合设计框架

2.1 UESTC-PLATFORM:一个服务计算可视化平台

UESTC-PLATFORM是一个可视化的服务计算平台,它支持服务设计、服务组合、服务仿真、服务部署等功能。其系统体系结构如图2所示。

平台提供了一套良好的访问和管理系统的组件,以便用户程序可以采用B/S方式和C/S两种方式调用系统平台。系统平台采用了SOA架构进行设计,支持BPEL4WS1.1规范,从而保证系统能够向企业级应用提供良好的松散藕合性,满足企业业务的决速变化,并且支持在应用平台中居于主流地位的国际规范。

UESTC-PLATFORM系统将服务划分为两大类:内部服务和外部服务。内部服务指的是与应用程序运行在同一个虚拟机下并被WSDL包装成服务的JAVA组件;而外部服务即Web services,它和应用程序运行在不同的虚拟机,不同的进程、甚至是不同的网络环境下。内部服务适用于企业内同构环境下的组件调用,外部服务适用于企业间异构环境下的组件调用。为了提高服务的调用效率,对内部服务的调用方式是直接解析服务并调用相应组件。

图2中虚线框部分是属于UESTC-PLATFORM的部分。其中具有可移植性、高效率、高性能的内核管理组件是系统的核心部分(点划线虚框所示),它对外提供了监视系统资源和运行状态的接口,对内管理系统的各个组件和服务。此外,内核组件还具有一定的灵活性,可插拔、替换(采用foci技术)其他的实现技术。在本系统平台中,采用基于IOC的技术来实现具体组件,并用Megaserver管理系统内的组件模块,其下挂接了5个系统组成模块:

BPEL工作流引擎:它是平台的重要组成部分,符合业界BPEL4WSvl.1标准。使得基于本平台的企业级应用能够全面实现SOA架构和企业商业、办公过程自动化。

内部服务:实现企业内部业务组件服务化。

规则引擎:按照业界标准实现业务规则的随需应变。

相关资源:包括了排队队列、流程连接池、工作队列、系统平台参量、服务参数等。各种组件:指构成本系统的组件,包括服务管(Serviceman age)、日志、事务、持久化等。

2.2 基于Pi演算的形式化框架PIFF

1)PIFF:一个基于Pi演算的形式化框架

PIFF是一个基于Pi演算的形式化框架。它包括三个部分:第一个部分表明了WSCDL-WSBPEL的关键元素和Pi演算之间的关系;第二部分表示了如何将高级结构——进程模式——建模为Pi演算的agent表达式;第三部分是一些指导和辅助验证的工具。PIFF的结构如图3所示。

2)WSCDL,WSBPEL和Pi演算元素的对应关系

Pi演算可以描述各种数据结构和控制结构。无论WSCDL还是WSBPEL,其组合描述都可以分为两个逻辑部分,一是静态信息描述;二是流控描述。映射关系描述在表1中。

3)将高级结构映射到Pi演算

WS将高级结构映射到pi演算

CDL的核心信息交换部分包括在"Interaction"、"exchange"子元素,"exchange"有"send"和"receive"元素中。子元素。iteration有因为WSCDL描述服务之间的交互规则,交互模式可以总结为三种模式之一:单向(one-way),同步发送/接收和异步发送/接收。这些模式可以映射为相应的Pi演算,如表2所示。

WSBPEL交互模式比起WSCDL来说更加复杂一些,因为它可以用来描述组织内的业务流程。根据Alisati:Barros和Frar Puhimann的研究工作,Pi演算可以表达任何的工作流模式。通过分析和比较,该文选择出一些核心模式,作为PIFF支持的内容。表3展示了这些模式。

4)PIFF框架的验证方法

如前所述,PIFF不仅提供了用Pi演算表示WSCDL和WSBPEL的方法,也涉及如何验证关键属性的方法。在服务组合的过程中开发者必须保证服务组合的结果能满足系统用户的需求。系统设计者从全局观点设计系统,但是开发者从本地的内部流程视角来看待服务组合[4]。因此,必须保证每个参与者产生与全局协议一致的交互方式。作为一种编排语言,WSCDL指定了交互行为的全局特征,也表示了全部参与者必须满足的交互规则。怎样形式化地验证wscDL与WSBPEL的一致性是一个重要的问题。在PIFF的辅助下,可以保证这种一致性[5]。

当系统设计者提出一个WSCDL的服务组合描述时,全局设计可以映射为Pi演算表达式,此时,表达式就描述了系统需求,该表达式被称为服务组合需求模型serum(service。composition irementmodel)。为了达到Serum的目标,一些本地流程必须创建出来,本地流程可表达为WSBPEL,设有N个本地服务被创建出来完成组合。

3 使用PIFF框架的实例

在此组合中,有五个参与者。Client Proxy是客户代理。TravelAgentis负责联系宾馆、接受客户请求。Balk负责支付服务。Elmer是Hotel的内部通道,检查是否有空余房间。

1)根据PIFF,一个SCRM可以构建如下:

(缩写:CP-Client Proxy,TA-Travel Agent,BK-Bank,HT-Hotel,CK-HT内对外不可见的内部动作)

SCRM=CPTA.TAHT.(HTTA.TACP+HTBK).BKCP.CPBK.BKHT.HTTA.TACP).SCRM

每个发送操作都有相应的接收动作。SCRM可以解释为:

CP发送请求(req)到TA;

TA接收到req,并且发送预定请求到HT;

HT检查空余房间(通过发送que到CK,通过内部通道Inner进行)。如果CK的回答是有(ok),HT发送支付请求(Pay)给BK,否则(nok)HT发送拒绝信息(rer)给TA,然后TA发送拒绝信息(dec)给CP;如果HT发送pay,BK发送请求给要求cP支付,CP支付(fee);BK发送已支付信息(pok)给HT,HT再发送预定成功信息(suc给TA,TA则发送确认信息(efhi)给CP。

2)根据PIFF,一个essC RM模型可以创建如下:

3)根据PIFF,为了检查是否escort与scrim一致,每个cascara中的服务都必须验证其一致性。在该例中,把Travel Agent作为样例来说明如何验证单个服务一致性。

4 结论

该文的研究工作实现了初步的融合,即可以通过UESTC PLATFORM调用MWP平台工具。这里实现了两个工作,一是将Pi演算描述的流程映射为WS-BPEL的框架;二是将WSBPEL的流程描述逆向转出(建模)为Pi演算的流程描述。这个研究工作仍在进行中,现在所定义的两个映射器(正向映射和逆向映射)是进一步改进的重要基础,也是以后实现对WSCDL支持的重要参考。

摘要：论文从服务计算试图用自动分解需求,全网搜索小粒度服务,组装出符合需求的应用逻辑的方式来完成以前的软件开发任务。在这个框架中,研究的基本点是如何描述服务、如何发现服务、如何组装服务、如何测试和验证服务。具有形式化模型的服务组合能够更好地保证组合正确性以及其它的相关特性。

关键词：Agent,SOA,引擎设计方法,PI-演算,Web服务

参考文献

[1]徐伟,金蓓弘,李京,等.一种基于移动Agent的复合认服务容错模型[J].计算机学报,2005,28(4):558-567.

[2]吴建,吴朝晖,李莹,等.基于本体论和词汇语义相似度的Web服务发现[J].计算机学报,2005,28(4):595-602.

[3]李曼,王珊.基于领域本体的Web服务动态组合[J].计算机学报,2005,28(4):644-650.

[4]刘必欣,王玉峰,贾焰,吴泉源.一种基于角色的分布式动态服务组合方法[J].软件学报,2005,16(11):1859-1867.