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

在 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 方面可以支持基于工作流的开发方式。