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

　　北卡罗来纳州运输部（NCDOT）曾面临在数据同步移动计算环境里通常存在的许多难题，Mobile Inspector应用程序的同步组件就解决了移动环境下需要在桥梁检查小组内部及时交换信息的问题。
　　2004年春天来到北卡罗来纳州首府罗利之前，我从来没有过多地关注过桥梁和天桥。我认为没必要为了安全而定期检查桥梁，当然更没听说过“桥梁检查员”这个职衔。我只知道，那些头戴安全帽、身穿安全背心的人负责清理路上被车扎死的动物。
　　当使用了Mobile Inspector应用程序的同步组件后，我马上改变了这种想法。北卡罗来纳州共有大约19000座桥梁和涵洞桥需要定期检查，大约有60名现场检查员负责检查工作，包括水下作业的四个小组。这些检查员在现场作业时忙于记笔记、拍照片，然后回到总部后还要准备检查报告，用来确定哪些桥梁可以用一段时间、哪些桥梁需要立即检修。
　　Mobile Inspector应用程序用于收集检查员测量及观察的数据，并用来存储数字照相。目的就是把数据录入工作从总部扩大到现场，从而节省成本、满足要求以电子方式记录桥梁检查数据的联邦政府法规。为了有可能完成这项工作，该应用程序使用了语音控制、手写识别及定制的速记工具。
　　
　　架构描述
　　
　　每个检查员在现场使用运行Windows 2000的平板电脑(Tablet PC)，如果这是传统的客户机/服务器两层结构，或者甚至是两层分布式层次结构，所有平板电脑就可以直接与中央数据库进行通信或者保持同步。不过由于安全因素，只有总部才可以连接到中央数据库。这意味着，每趟现场检查之前，数据都要拷贝到小组负责人的平板电脑上，检查报告制作完毕后，还要把数据拷回去。数据还要在小组负责人的PC和小组成员的PC之间来回拷贝。如果遇到大型桥梁，得拷贝好几次，这些操作使用无线连接在现场进行。
　　
　　图1表明了Mobile Inspector应用程序涉及的计算机是如何在三层环境中排列的: 中央数据库服务器位于顶层，小组负责人的平板电脑位于中间层，小组成员的PC位于底层。小组负责人通过有线局域网与中央数据库进行通信，通过Wi-Fi与小组成员进行通信。同步服务器软件同时放在中央数据库的计算机和小组负责人的PC上运行，这些服务器分别与小组负责人的PC和小组成员的PC上的同步客户软件进行联系。
　　应用程序本身使用关系数据库管理系统把数据存储到平板电脑上，其中包括数据照片。这么做是为了获得以下优点: 提供数据完整性、可恢复性、强大功能以及简洁性，这些优点也是人们使用关系数据库管理系统（RDBMS）的通常理由。不过缺点同时存在，从单一中央数据库移到涉及众多远程数据库的三层分布式结构并非易事。因为无法为每支检查小组随派一名数据库管理员，但哪怕在无线连接不可靠的情况下也要做到同步过程不出差错，且同步过程都必须做到可靠。
　　NCDOT(The North Carolina Department of Transportation)的数据库配置环境使用Oracle 9i作为中央数据库、Adaptive Server Anywhere（ASA）作为平板电脑上的远程数据库，使用MobiLink同步软件来处理Oracle-to-ASA和ASA-to-ASA的传输任务。ASA和MobiLink都作为iAnywhere Solutions公司的SQL Anywhere Studio Version 9的一部分来交付。
　　
　　无线移动下的同步
　　
　　MobiLink软件由客户机和服务器两部分组成。远程客户机连接到本地数据库后，开始同步过程，它能够收集自上一次同步后出现变化的所有行数据，然后把这些数据上传到MobiLink服务器。随后服务器把上传的变化数据添加到中央数据库，选择所要下载的行数据，再把这些数据发送到客户机。最后，MobiLink客户机把下载的变化数据添加到本地数据库，并向服务器发回确认信号。
　　在任何环境下，故障处理都是同步过程的一个重要环节，在连接经常中断或者偶尔中断的移动Wi-Fi环境下更为重要。有了MobiLink，就可以在上传和下载数据库事务这一层面处理故障。如果上传失败，上传的所有变化数据都恢复原状，整个过程停止。恢复工作包括再次运行同步过程。上传数据流从头开始重新组合，重复上传过程，就好像从未遇到过失败。
　　下载期间的故障采用类似方式加以处理: 如果下载失败，下载数据恢复原状，恢复方法如出一辙: “再试一次”。不过这回只是重复下载过程，因为前一次上传是正确的，事务已提交。使用MobiLink，这一切都是自动的。
　　Mobile Inspector应用程序解决了两大问题: 首先，使移动环境下的数据同步简化，人们往往会低估同步环境具有的复杂性，如果它是大型业务应用程序当中不可或缺的一部分，更是如此。其次，关系数据库数据层面的同步可以简化这种环境，因为它可以把同步逻辑与应用程序代码分开来，把复杂的数据结构精简成简单的行和列，并且可以利用数据库的基本特性，譬如事务提交和列默认值。
　　
　　实施业务规则的重要性
　　
　　MobiLink的主要优点之一在于，能够利用事件驱动型架构，从而定制同步过程。你可以提供定制脚本，明确规定针对任何特定事件而应当采取的处理步骤。MobiLink提供了极佳的控制能力。譬如在涉及100张表的同步过程中，几乎会有成千上万的不同事件。当然，大多数事件并不需要脚本，默认操作就可以了。以NC DOT为例，针对以下事件编写了定制脚本:
　　
　　先进的应用程序往往会给同步过程带来复杂的业务规则，Mobile Inspector也不例外。MobiLink脚本既用于“只有地区主管才能得到地区主管检查表里面的行”这么简单的业务规则，也用于比较复杂的选择规则。譬如说，下面的download_cursor脚本选择的Inspection行（1）被赋予特定的检查小组; （2a）还没有被下载，或者（2b）自上一次下载以来得到了更新。这里显示的Select利用了BRI_RECD_SYNC_IDS表，以确定被赋予给该小组的行; 早些时候的内容多得多的begin_download脚本可以为这张表批量载入数据，以便可用于类似这样的脚本:
　　SELECT BRI_INSPCTN.INSPCTN_ID,
　　BRI_INSPCTN.STRCTR_ID,
　　BRI_INSPCTN.INSPCTN_DT,
　　...
　　BRI_INSPCTN.APRVL_DT
　　FROM WIGINS_UNIT.BRI_INSPCTN
　　WHERE EXISTS
　　( SELECT * FROM WIGINS_UNIT.BRI_RECD_SYNC_IDS,WIGINS_UNIT.BRI_TMP_SYNC_VRBLS
　　WHERE BRI_TMP_SYNC_VRBLS.SESSION_ID = TO_NUMBER ( USERENV ( SESSIONID ) )
　　AND BRI_RECD_SYNC_IDS.GLOBAL_DB_ID = BRI_TMP_SYNC_VRBLS.GLOBAL_DB_ID -- for this remote
　　AND BRI_RECD_SYNC_IDS.STRCTR_ID
　　= BRI_INSPCTN.STRCTR_ID -- matches on structure id
　　AND BRI_RECD_SYNC_IDS.INSPCTN_ID
　　= BRI_INSPCTN.INSPCTN_ID -- matches on inspection id
　　AND ( BRI_RECD_SYNC_IDS.FRST_DOWNLOAD_TS = "1900-01-01" -- not yet been downloaded
　　OR BRI_INSPCTN.LST_MDFD_TS
　　>= ? ) ) -- updated since the last synch
　　MobiLink脚本由MobiLink服务器来调用，但它们实际上由中央即“合并”数据库服务器来执行，在与MobiLink服务器之间来回传送行。在NCDOT，用两套MobiLink服务器和两套脚本来实施三层数据库架构。在顶层，用Oracle PL/SQL编写的脚本由Oracle 9i中央服务器来运行，上面显示的示例就是这些脚本当中的一个。行传送到中央位置运行的MobiLink服务器，再从这里传送到检查办公室处小组负责人的平板电脑。
　　在现场，另一个MobiLink服务器在小组负责人的平板电脑上运行。它调用在同一台PC上运行的ASA数据库服务器里面的SQL脚本。这些行传送到MobiLink服务器上，再从这里通过无线链接传送到小组成员的PC上。在这种结构下，与Oracle中央服务器进行同步时，小组领导人的数据库充当远程数据库; 与小组成员进行同步时，它又充当合并数据库。
　　
　　分布式数据 面临的难题
　　
　　彼此并非不断联系的分布式数据库无法为整个系统的锁定提供任何机制。尤其是，没有办法阻止你把有着同一主键的两行插入到两个不同的远程数据库上，因而如果这些行上传到合并数据库，就会导致主键冲突。
　　一个解决办法就是使用包含普通的自动递增列的组合主键以及“数据库标识符”，解决不同数据库的自动递增值相互重叠的问题。多列主键会让应用程序开发人员觉得不便，因为这使得外键定义过于复杂，所以全局惟一标识符（GUID）有时被认为是单列主键方案。GUID是128位的整数，有着“6F9619FF-8B86-D011-B42D-00C04FC964FF”这样的值。虽然它们具有惟一性，可是会导致数据库索引结构庞大，而且调试时，其值处理起来很麻烦。另一个常见的解决办法就是使用键池（key pools）。在键池，一组组惟一键值由中央服务器生成，供一个个远程数据库以后下载使用。键池确实可行，可是要合理实施及管理颇有难度，在多级层次结构下更是如此。另外，它们也会带来额外的网络流量。
　　ASA提供了比较巧妙的办法，可以解决全局惟一主键的问题: 通过Global Autoincrement列默认值的分区自动递增工具（partitioned autoincrement facility）。每个数据库被赋予惟一的数据库标识符: 1、2、3，依次类推，该值可以自动用来确定使用哪个分区即哪个范围的值来为该数据库赋予主键值。
　　这对Mobile Inspector应用程序来说至关重要，原因是新行经常被插入到每个远程数据库上面的许多表里面，它们都有自动赋予的或者“人工的”主键。以下示例表明了用来把徒手画的草图保存在BLOB列当中的BRI_SKTCH表。分区大小被设成2000000，这意味着在每个分区被用尽之前，每个检查员可以画这么多的草图。有符号的32位整数主键可以长达2147483647，除以2000000得到1073，这就是在不引起任何主键冲突的情况下，可以使用该机制的数据库的最大数量。这适用于Mobile Inspector应用程序; 如果是其他比较庞大的应用程序，可以使用无符号的64位整数。
　　CREATE TABLE BRI_SKTCH (
　　SKTCH_ID INTEGER NOT NULL DEFAULT GLOBAL AUTOINCREMENT ( 2000000 ),
　　STRCTR_ID INTEGER NOT NULL,
　　SKTCH_TTL VARCHAR ( 45 ) NOT NULL,
　　SKTCH_DES VARCHAR ( 130 ) NULL,
　　FILE_NM VARCHAR ( 32 ) NULL,
　　DEL_FLG_IND BIT NOT NULL DEFAULT 0,
　　LST_MDFD_TS TIMESTAMP NOT NULL DEFAULT TIMESTAMP,
　　SKTCH_LOB LONG BINARY NULL,
　　SKTCH_NBR INTEGER NOT NULL,
　　SKTCH_SZ_AMT INTEGER NULL,
　　PRIMARY KEY ( SKTCH_ID ) );
　　分布式数据的另一个难题就是减少让数据库保持同步所需的网络流量。专用同步软件出现之前，要确定需要来回传送哪些数据，就得编写应用程序代码。有时候，该代码需要传送大量的数据，旨在确保没有任何遗漏。在另一些情况下，搜索需要调和的差异情况所用时间多久，传输时间就有多久。
　　MobiLink客户机通过读取远程数据库事务日志来确定需要上传哪些数据，从而减少了网络流量。只有自从上一次同步后被插入、更新或者删除的行才会被发送。另外，如果某行在同步过程中改动了多次，那么只是最终版本才会被上传。
　　MobiLink服务器在确定下载数据流时不具备同样的优点。因为要处理不同的数据库，如Oracle、 SQL Server和DB2，MobiLink无法访问事务日志。如果你不想每次都下载整张表，就必须在download_cursor脚本里面编写相应的WHERE子句。
　　这时候，ASA的另一项特性可以派上用场:每次只要更新以及插入行，用Default Timestamp特殊属性定义的时间戳列（timestamp column）就会自动加以更新。比较前面的CREATE TABLE表明了每张表可以有LST_MDFD_TS列，不必编写触发器就可以保持最新。之前显示的SELECT语句含有“LST_MDFD_TS >= ?”来把下载结果集限制在自上一次同步以来发生变化的那些行。
　　MobiLink服务器可以自动用“上一次同步时间戳”值代替“?”占位符，这样就不必为了跟踪每个远程数据库何时同步而编写任何定制代码。（沈建苗译）