Sybase 在线课堂第 3 期内容回顾:详细解析—SUP 移动应用开发平台

阅读数:1237 2011 年 1 月 13 日

话题:Java.NETRubyDevOps语言 & 开发架构

在 2010 年 12 月 9 日第二期 Sybase 在线课堂上,来自赛贝斯软件(中国)有限公司的移动商务咨询顾问王楠为大家初步介绍了 SUP 移动应用开发平台(点击查看相关内容)。27 日,王楠又在第三期的 Sybase 课堂上详细为大家进行了讲解了 SUP 的关键原理、机制。

详细解析—SUP 移动应用开发平台点击下载相关音视频资料

在对上次课堂进行了简单的回顾后,王楠从三个方面对 SUP 移动应用平台进行了深入的解析。在介绍中,王楠首先指出,移动开发的难点主要在于移动应用的多样性。

基于 PC 的应用现在已经很成熟,开发桌面应用很容易,但是在移动领域就不一样,设备和系统的多样化自然的增加了移动开发的难度。我们如何把开发出来应用放到不同的平台使用,同时还有一个数据整合的问题,如何把现在的各种系统和接口融合起来,是我们必须面临的问题。另外就是移动用户对界面和功能的需求也越来越多。

通过上次讲活动后的 Q&A 和课后的反馈中,发现大家对上次介绍中提到的“离线应用”还不是十分了解。这次王楠提到一个“永远在线”的概念,对此进行了补充。

“永远在线”是相对于不稳定的网络而言。移动应用模式大多数是在一种在线应用,或者说是 Web 应用。其特点是在使用的时候,终端必须连接后台。终端上很多操作都是在后台上实现的。这种做法的优点是随时可以去后台查询数据,不足之处却是相关的移动应用会在没有网络支持的情况下不能进行。“永远在线”提供了一种本地支持,在没有网络的情况下,大家依然可以执行相关操作,并被缓存在本地,有了网络支持便可传输到后台。这种概念和操作方式的加入,给大家的是一种真正永远在线的感受,网络问题并不影响大家使用移动应用。

移动应用运行时环境:

上一堂课中提到了 SUP 的几个特性,这次主要是要介绍 SUP 是怎样做到上次提到的那些特性的。首先从运行时环境开始。移动应用开发完毕之后,在运行时就叫做运行时的环境,也可以叫做生产系统。我们可以在这里看看 SUP 有那些不同的特点:

先看普通移动应用的架构:后台系统提供相关接口和进行安全认证,后台系统通过有线网络连接到应用服务器,应用服务器通过移动网络连接到移动终端,接受终端的请求发送到后台系统,并把后台系统数据传输到移动终端。

再回过头来看 SUP 的物理架构,在基本架构上也是一样,由后台系统、SUP 服务器(应用服务器)和移动的终端组成。

SUP 是符合经典的移动应用架构的,除此之外还提供了一个 Relay Server 的架构。普通的移动应用架构一定是把应用服务器暴露到外网。但是对安全性要求比较高的客户是不允许这么做的。我们就提供了 Relay Server,帮我们穿透内网的防火墙,不用在上面开端口就能实现移动终端通过 SUP 服务器进行数据交换。

因为对于大多数安全系统来说,忌讳在内网的防火墙开端口。他们可以容忍外来攻击进入 DMZ(缓冲区),但是不能容忍进入到内网中来。有了 Relay Server 之后,既不需要在内网防火墙上开端口,也不影响移动终端的数据交换。

接下来,王楠又详细介绍了 SUP 的三大组成部分:终端应用程序、SUP 服务器、后台系统。

终端应用程序可以通过两种不同的方式进行移动应用开发。第一种是 Workflow 开发方式做的通用应用程序,只要在移动终端上安装标准版本的应用程序,就可以把所有相关的应用推送到移动终端。第二就是定制的移动应用程序。

在普通的应用服务器中,我们需要开发跟终端和后台交互的应用模块,甚至一些数据转换模块。在 SUP 服务器中,这些工作都是不需要的。我们需要做的事情就是部署安装 SUP 服务器,然后把我们做好的接口定义、数据结构定义、权限控制以及数据同步规则等模块部署到 SUP 服务器里面。

后台系统如果能提供标准接口,我们就不需要做开发。即使没有标准接口,我们就依据标准协议来定制开发接口进行转换就可以了。

介绍完 SUP 的三个主要组件后,王楠对中间的两个传输的部分进行了解释。第一部分是 SUP 服务器和终端之间的 Synchronization,即同步传输。第二个是 SUP 服务器和后台之间的传输 Date Refresh。

Synchronization 主要有以下几个特性:两种不同的传输和数据推送方式;统一的用户管理机制;数据的个性化。

两种传输方式 MBS 和 RBS。MBS(Message based Synchronization)类似消息队列这样的传输模式,数据以消息的方式在 SUP 服务器和终端之前交互传递。从推送角度上来看,消息是一个天生的良好的推送通道。这种传输模式适合信息量小,即时性要求高的信息传递;RBS(Replication based Synchronization)基于移动数据库的数据复制的基础上实现的一种传递方式。它本身就是一个偶连接的方式,是针对不同平台提供不同的推送方式。RBS 比较适合大数据量的传输,而且大多数时间是离线的。适合那种在有 WiFi 的环境,并且数据一次传输量大的信息传送。

用户管理机制,SUP 可以实现统一管理,主要体现在两方面,终端在线的时候可以提供基于 SUP 服务器的认证;当我们在线完成正确的认证的时候,信息会被存在移动用户的终端,所以在离线的状态下,用户仍然可以完成本地认证,这是第二点。

还有一个特性就是数据的个性化,因为移动终端用到的数据基本都是少量数据,但后台系统存储的数据量则很大。SUP 采用了同步参数过滤数据的方式来实现这一目标。

Date Refresh 主要涉及以下几个话题:

数据模型的定义:MBO(Mobile Business Objeckt)和 Relationship;

数据同步方式:上次提到 SUP 有个很重要的功能叫做 Cache,可以缓存用户的数据,也许有人会问,如果你做了 Cache 以后,如何保证数据的实时性,以及推送的时候新的信息是怎么来的?我们 Cache 的刷新是可以支持三种不同的方式:On-Demand:数据的刷新完全由移动终端驱动;Schedule:SUP 定时到后台取数据;DCN(Date Change Notification):后台发起的数据刷新 ;

数据过滤机制:通过过滤和转换把原始数据变成用户需要的方式表达出来。

移动应用开发过程:

在介绍完移动运行时环境后,王楠接下来对移动应用开发过程进行了讲解:

刚才提到运行时,SUP 会提供一个终端的运行程序,由用户整个的定义决定我们如何和后台交互。所有这些内容都是开发出来的。开发过程中主要有两个模式:自底向上、自顶向下。二者的区别在于创建 MBO 的方式不一样,前者是从数据源出发,后者从业务流程出发。在开发过程中主要有下面几个步骤:先针对 MBO 做开发,然后是针对应用程序做开发。在这里需要注意两点,第一是在开发中有两次机会生成代码,第一次生成的代码只涉及数据访问;第二次生成代码,第二次生成代码除了涉及到数据访问 API 外,还有大量的通过 SUP 生成应用界面。

前面一直提到 MBO,MBO 是什么?在介绍完开发过程后,接下来王楠详细做了解释:

MBO 全称是 Mobile Business Objeckt,这个概念是 SUP 提出来的。大家可以把 MBO 和实体跟关联的关系进行对比。每一个 MBO 往往都对应数据库里的一个表,对应 Web Service 里面的一个方法的返回,它就是一个结果集,当你操作完任何一个操作后,都会得到一个数据集,这个数据集就会被映射成 MBO。MBO 其中一个功能就是定义从后台读取的数据内容,另一个就是决定终端的数据显示。

刚才也说了开发的第一步就是开发 MBO,那么开发 MBO 的过程是怎样的呢?

开发的第一步就是开发 MBO,开发 MBO 首先要识别数据源,对数据源做一个配置。我们只要把开发界面提供的数据源的元素变成 MBO 的元素,移动终端就可以进行访问后台的数据源。

MBO 是一种后台的开发,那么 SUP 的终端开发又是怎样的呢?

终端应用程序有两种开发方式,一种是基于工作流(WorkFlow)的开发方式,只需要安装一个通用的客户端。在后台开发出移动应用就可以被推送到终端。这种开发比较简单,都是标准化的,界面可能会受到标准的限制,胜在开发速度;

第二种是本地应用开发,适合相对复杂或者对界面要求比较高的应用。后台的开发跟 WorkFlow 基本一样,区别在移动终端上。这种开发是通过终端的本地代码进行终端开发。这种方式的好处就是可以最大化的定制移动终端的应用程序。

针对本地移动终端开发也分为几种不同的方式:

DAD(Device Application Designer)全部通过 SUP 提供的工具完成开发,最简单高效;

DAD+ 本地代码的方式进行开发,如果我们需要定制化程度更高的应用程序,光凭 DAD 的能力不能满足的话,就在 DAD 的基础上加一些本地代码进行开发;

Client API+ 本地代码,通过 SUP IDE 生成 Client API 代码,直接通过终端本地的工具创建应用程序。

以上几种方式各有优缺点,我们可以根据自己不同的需求选择开发方式。

移动平台管理功能:

在运行过程中 SUP 提供了一个基于 Web 的管理界面,对整个集群界面进行管理。在功能上,这个界面可以实现对整个 MBO 包的管理、安全的管理、用户的管理、工作流的管理、设备的管理,以及大家看到的对系统的监控等等。

最后王楠又演示了一些 SUP 的开发界面,并在现场回答了大家在网上的提问:

SUP 中的数据是如何在服务器及移动终端传输的?

SUP 支持两种传输方式,MBS 以消息方式进行传输,RBS 以数据库复制方式进行传输,协议都是基于 HTTP 或 HTTPS 方式完成传输。

SUP 中的 push/notification 是自己做的吗?还是适配的 APNS、C2DM?

SUP 的 Push 功能是结合了终端现有 Push 机制实现,我们用到了 APNS 在 iPhone 上,在黑莓上我们也用了 BB 本身的推送机制。

问一下,对于 Android 操作系统的支持,不知道现在 SUP 做得如何?

这个需要在后面的版本才能支持,现在的版本还没有。

不知道 SUP 对于 RESTFul 方式的 WebService 支持得如何?

SUP 可以支持 REST 方式的 Web Service 接口。

Push 功能需要联系运营商才能使用呢,还是直接就可以使用?

各个平台不一样,由于 BB 的 Push 机制需要依赖运营商,所以在 BB 上如果使用 Push 那么必须是在运营商开通了服务的终端,而其他平台不需要。

这个开发工具是否支持一些主流的开发语言?

终端开发使用终端本地开发语言,BB 使用 Java,iPhone 使用 Objective C 等。

通用客户端我理解就是一个解释引擎。这种方式开发的应用在 App Store 上能申请通过吗?

我们已经有类似的客户端在 App Store 可以提供下载。

刚才看操作,只支持 Blackberry 和 WM 吗?

还可以支持 Win32 及 iPhone 系列平台,Sybian 方面可以支持基于工作流的开发方式。