创建移动Wi-Fi应用程序_小米Wi-Fi创建失败

1、北卡罗来纳州运输部(NCDO)T曾面临在数据同步移动计算环境里通常存在的许多难题，Mobile Inspector应用程序的同步组件就解决了移动环境下需要在桥梁检查小组内部及时交 换信息的问题。 2004年春天来到北卡罗来纳州首府罗利之前，我从来没有过多地关注过桥梁和天桥。我 认为没必要为了安全而定期检查桥梁，当然更没听说过“桥梁检查员”这个职衔。我只知道，那些头 戴安全帽、身穿安全背心的人负责清理路上被车扎死的动物。 当使用了 Mobile Inspector应用程序的同步组件后，我马上改变了这种想法。北卡罗来纳州共有大 约19000座桥梁和涵洞桥需要定期检查，大约有60名现场检查员负责检查

2、工作，包括水下作业的四个小 组。这些检查员在现场作业时忙于记笔记、拍照片，然后回到总部后还要准备检查报告，用来确定哪些桥 梁可以用一段时间、哪些桥梁需要立即检修。 Mobile Inspector应用程序用于收集检查员测量及观察的数据，并用来存储数字照相。目的就是把数 据录入工作从总部扩大到现场，从而节省成本、满足要求以电子方式记录桥梁检查数据的联邦政府法规。 为了有可能完成这项工作，该应用程序使用了语音控制、手写识别及定制的速记工具。 架构描述 每个检查员在现场使用运行Windows 2000的平板电脑(Tablet PC),如果这是传统的客户机/服务 器两层结构，或者甚至是两层分布式层次结

3、构，所有平板电脑就可以直接与中央数据库进行通信或者保 持同步。不过由于安全因素，只有总部才可以连接到中央数据库。这意味着，每趟现场检查之前，数据 都要拷贝到小组负责人的平板电脑上，检查报告制作完毕后，还要把数据拷回去。数据还要在小组负责人 的PC和小组成员的PC之间来回拷贝。如果遇到 大型桥梁，得拷贝好几次，这些操作使用无线连接在现场进行。 图1表明了 Mobile Inspector应用程序涉及的计算机是如何在三层环境中排列的：中央数据库服务器 位于顶层，小组负责人的平板电脑位于中间层，小组成员的PC位于底层。小组 负责人通过有线局域网与中央数据库进行通信，通过WiFi与小组成员进行通信。同

4、步服务器软件同时放 在中央数据库的计算机和小组负责人的PC上运行，这些服务器分别与小组负责 人的PC和小组成员的PC的同步客户软件进行联系。 应用程序本身使用关系数据库管理系统把数据存储到平板电脑上，其中包括数据照片。这么做是为了 获得以下优点：提供数据完整性、可恢复性、强大功能以及简洁性，这些优点也是人们使用关系数据库管 理系统(RDBMS的通常理由。不过缺点同时存在，从单一中央数 据库移到涉及众多远程数据库的三层分布式结构并非易事。因为无法为每支检查小组随派一名数据库管理 员，但哪怕在无线连接不可靠的情况下也要做到同步过程不出差错，且同步过 程都必须做到可靠。 NCDOT(The Nort

5、h Carolina Department of Transportation)的数据库配置环境使用 Oracle 9i作为中央数据库、 Adaptive Server Any where ( ASA作为平板电脑上的远程数据 库，使用MobiLink同步软件来处理Oracle-to-ASA和ASAtoASA的传输任务。ASA和MobiLink都作为 iAnywhere Solutions 公司的 SQL Anywhere Studio Version 9 的一部分来交付。 无线移动下的同步 MobiLink软件由客户机和服务器两部分组成。远程客户机连接到本地数据库后，开始同步过程，它 能够收集

6、自上一次同步后出现变化的所有行数据，然后把这些数据上传到MobiLink服务器。随后服务器把 上传的变化数据添加到中央数据库，选择所要下载的行数据，再把这些数据发送到客户机。最后， MobiLink客户机把下载的变化数据添加到本地数据库，并向服务器发回确认信号。 在任何环境下，故障处理都是同步过程的一个重要环节，在连接经常中断或者偶尔中断的移动Wi-Fi 环境下更为重要。有了 MobiLink ,就可以在上传和下载数据库事务这一层面处理故障。如果上传失败， 上传的所有变化数据都恢复原状，整个过程停止。恢复工作包括再次运行同步过程。上传数据流从头开始 重新组合，重复上传过程，就好像从未遇到过失败

7、。 下载期间的故障采用类似方式加以处理：如果下载失败，下载数据恢复原状，恢复方法如出一辙： “再试一次” o不过这回只是重复下载过程，因为前一次上传是正确的，事务已提交。使用 MobiLink ,这一切都是自动的。 Mobile Inspector应用程序解决了两大问题：首先，使移动环境下的数据同步简化，人们往往会低估 同步环境具有的复杂性，如果它是大型业务应用程序当中不可或缺的一部分，更是如此。其次，关系数据 库数据层面的同步可以简化这种环境，因为它可以把同步逻辑与应用程序代码分开来，把复杂的数据结构 精简成简单的行和列，并且可以利用数据库的基本特性，譬如事务提交和列默认值。 实施业务规则的

8、重要性 MobiLink的主要优点之一在于，能够利用事件驱动型架构，从而定制同步过程。你可以提供定制脚 本，明确规定针对任何特定事件而应当采取的处理步骤。MobiLink提供了极佳的控制能力。譬如在涉及 100张表的同步过程中，几乎会有成千上万的不同事件。当然，大多数事件并不需要脚本，默认操作就可 以了。以NCDOT为例，针对以下事件编写了定制脚本: 先进的应用程序往往会给同步过程带来复杂的业务规则，Mobile Inspector也不例外。 MobiLink脚本既用于“只有地区主管才能得到地区主管检查表里面的行”这么简单的业务规贝I,也用于 比较复杂的选择规则。譬如说，下面的download

9、_cursor脚本选择的Inspection行(1)被赋予特定的检查 小组；(2a)还没有被下载，或者(2b)自上一次下载以来得到了更新。这里显示的Select禾U用了 BRI_RECD_SYNCD表，以确定被赋予给该小组的行；早些时候的内容多得多的begin_download脚本 可以为这张表批量载入数据，以便可用于类似这样的脚本: SELECT BRI INSPCTNNSPCTN ID, BRI INSPCTN.STRCTR ID, BRI INSPCTNNSPCTN DT, BRIJNSPCTN.APRVL_DT FROM WIGINS_UNIT.BRI_INSPCTN WHERE EX

10、ISTS (SELECT * FROM WIGINS_UNIT.BRI_RECD_SYNCJDS,WIGINS_UNIT.BRI_TMP_SYNC_VRBLS WHERE BRI_TMP_SYNC_VRBLS.SESSION_ID=TO_NUMBER ( USERENV ( SESSIONID ) ANDBRI_RECD_SYNCJDS.GLOBAL_DBJD=BRLTMP_SYNC_VRBLS.GLOBAL_-D Bf_olrD this remote AND BRI_RECD_SYNCJDS.STRCTR_ID =BRI_INSPCTN.STRCTR_ID - matches on str

11、ucture id AND BRI_RECD_SYNCJDSNSPCTNJD =BRIJNSPCTNNSPCTNJD - matches on inspection id AND ( BRI_RECD_SYNCJDS.FRST_DOWNLOAD_TS=n1900-01-01not yet been downloaded OR BRI_INSPCTN.LST_MDFD_TS =?) updated si nee the last synch MobiLink脚本由MobiLink服务器来调用，但它们实际上由中央即“合并”数据库服务器来执行，在 与MobiLink服务器之间来回传送行。在NCDO,

12、 T用两套MobiLink服务器和两 套脚本来实施三层数据库架构。在顶层，用Oracle PL/SQL编写的脚本由Oracle中央服务器来运行， 上面显示的示例就是这些脚本当中的一个。行传送到中央位置运行的MobiLink服务器，再从这里传送到检 查办公室处小组负责人的平板电脑。 在现场，另一个MobiLink服务器在小组负责人的平板电脑上运行。它调用在同一台PC 运行的 ASA数据库服务器里面的SQL脚本。这些行传送到MobiLink服务器上，再从这里通 过无线链接传送到小 组成员的PCO在这种结构下，与Oracle中央服务器进行同步时，小 组领导人的数据库充当远程数据库；与小组成员进行同步

13、时，它又充当合并数据库。 分布式数据面临的难题 彼此并非不断联系的分布式数据库无法为整个系统的锁定提供任何机制。尤其是，没有办法阻止你把 有着同一主键的两行插入到两个不同的远程数据库上，因而如果这些行上传到合并数据库，就会导致主键 冲突。 一个解决办法就是使用包含普通的自动递增列的组合主键以及“数据库标识符”，解决不同数据库 的自动递增值相互重叠的问题。多列主键会让应用程序开发人员觉得不便，因为这使得外键定义过于复 杂，所以全局惟一标识符(QUID有时被认为是单列主键方案。GUID是 128位的整数，有着“ 6F9619FF-8B86-D011-B42D-00C04FC964F这样的值。虽然它

14、们具有 惟一性, 可是会导致数据库索引结构庞大，而且调试时，其值处理起来很麻烦。另一个常见的解决办法就是使用键 池(key pools ) o在键池，一组组惟一键值由中央服务器生成，供一个个远程数据库以后下载使用。键池 确实可行，可是要合理实施及管理颇有难度，在多级层次结构下更是如此。另外，它们也会带来额外的网 络流量。 ASA提供了比较巧妙的办法，可以解决全局惟一主键的问题:通过Global Autoincrement列默认值 的分区自动递增工具(partitioned autoincrement facility )。每个数据库被赋予 惟一的数据库标识符：1、 2、3,依次类推，该值可以自

15、动用来确定使用哪个分区即哪个范围的值来为该数据库赋予主键值。 这对Mobile Inspector应用程序来说至关重要，原因是新行经常被插入到每个远程数据库上面的许 多表里面，它们都有自动赋予的或者“人工的”主键。以下示例表明了用来把徒 手画的草图保存在BLOB 列当中的BRI_SKTCH表。分区大小被设成2000000,这意味着在每个分区被用尽之前，每个检查员可以 画这么多的草图。有符号的32位整数主键可以长达 2147483647,除以2000000得到1073,这就是在不引起任何主键冲突的情况下，可以使用该 机制的数 据库的最大数量。这适用于Mobile Inspector应用程序；如果

16、是其他比较庞大的应用程序，可以使用无符 号的64位整数。 CREATE TABLE BRI_SKTCH ( SKTCHJD INTEGER NOT NULL DEFAULT GLOBAL AUTOINCREMENT ( 2000000 ), STRCTRJD INTEGER NOT NULL, SKTCH_TTL VARCHAR ( 45 ) NOT NULL, SKTCH_DES VARCHAR ( 130) NULL, FILE_NM VARCHAR ( 32 ) NULL, DEL_FLGJND BIT NOT NULL DEFAULT 0, LST_MDFD_TS TIMESTAMP

17、NOT NULL DEFAULT TIMESTAMP, SKTCH_LOB LONG BINARY NULL, SKTCH_NBR INTEGER NOT NULL, SKTCH_SZ_AMT INTEGER NULL, PRIMARY KEY ( SKTCHJD ); 分布式数据的另一个难题就是减少让数据库保持同步所需的网络流量。专用同步软件出现之前，要确 定需要来回传送哪些数据，就得编写应用程序代码。有时候，该代码需要传送大量的数据，旨在确保没有 任何遗漏。在另一些情况下，搜索需要调和的差异情况所用时间多久，传输时间就有多久。 MobiLink客户机通过读取远程数据库事务日志来确定需要上传哪些数据，从而减少了网 络流量。只 有自从上一次同步后被插入、更新或者删除的行才会被发送。另外，如果某行在同步过程中改动了多次， 那么只是最终版本才会被上传。 MobiLink服务器在确定下载数据流时不具备同样的优点。因为要处理不同的数据库，如Oracle、 SQL Server和DB2, MobiLink无法访问事务日志。如果你不想每次都下载整张表，就必须在 download_cursor脚本里面编写相应的 WHER子