幻化的蓝莲花——Notes的兼容性

    等了好久，终于从Long Horn等成了Vista。一夜之间，层层叠叠的Windows窗口沸沸扬扬洒在无数公车站，广告牌，报纸，网站上。

    如果有一台干净机器，我会毫不犹豫的试用Vista，但现在不行，因为在这个时候选择Vista，意味着我机器上装的各式各样，乱七八糟的软件都要重新再装一遍。不过这还不是最重要的问题。

    最重要的是，当你下定决心，把各式各样，乱七八糟的软件重新在Vista上装一遍后，你会发现它们中有一多半在现阶段无法正常运行。对此，微软提供给你的原因也很简单：

    兼容性。

    兼容性包括很多方面，例如对硬件的兼容性，对系统的兼容性，对其他软件的兼容性以及同一软件不同版本的兼容性。对一个软件而言，兼容性是有特殊意义的。对兼容性的注重与否，体现的是软件的总体发展思路。而发展思路对软件的影响，就如同性格决定人的命运一样。

    特立独行的软件强调自身架构的优化，不破不立，勇于否定和创新。

    兼容并包的软件喜新而不厌旧，注重与其他软件的合作，善于吸收和改良。从软件发展史来看，这样的气魄可以让它们成为某个业界的强者，甚至王者。——虽然软件发展史也告诉我们，能更进一步，成为霸主并垄断一域的，往往却是那些咄咄逼人，瞻前不顾后的前者。

    这里我想说的是，对软件而言，没有一个必然最好的发展思路，正如同对人而言，没有一个必然最好的性格一样。Notes的市场定位和发展环境，决定了它要顾及的东西太多。一方面，IT的时代在进步，不与时俱进就死路一条；另一方面，原有大量用户的投资（硬件和软件的）要保护，因此技术的更替又不能太猛。所以Notes选择的发展路线是“北溟神功”而不是“吸星大法”，是在自身架构上不断吸收新技术去符合新标准，而不是颠覆原有架构来一次彻底的再造。——这种做法有利也有蔽。

    利处在于，这种做法可以在“向后发展”与“向前兼容”上找到平衡点。既满足了新需求，又保护了老用户。从Notes整个的发展来看，这几乎也是它所能做的唯一正确选择。

    不利之处在于，任何架构都有它的局限性。把一辆轿车改装成货车，有时不是在屁股后面加个拖斗那么简单。

    幸运的是，在Notes的发展初期，所面临的变更需求大都不是这种“轿车变货车”的大改，而是一些锦上添花的需要。Notes R2增加表单，视图，公式；R3增加代理，ODBC访问；R4增加编程语言Lotusscript，以及支持电子邮件标准SMTP。。。这些变化顺应整个市场的技术发展潮流，对产品原有功能也是必要的补充，因此也都收到了预期的效果，逐步构建了我们今天看到的Domino/Notes架构雏形，纵横多种硬件与系统平台，沿用至今。

    在此有必要先简单介绍一下Notes的架构，这是一种可以跨多个硬件与系统平台，甚至跨服务器与客户端（同一个程序可以分别运行在客户端本地和服务器上）运行的软件架构。对软件而言，可以实现跨平台的江湖派别有很多，大体分为编译派，虚机派和调用派。

    编译派的做法最经典，利用具有多平台支持的语言（例如C,C++）编写程序，在各个不同平台上编译，使得程序可以运行于多个操作系统；

    虚机派也可以叫做解释派，代表人物也赫赫有名——java，在不同平台上构建运行时环境，屏蔽底层细节，解释执行相同的代码；

    调用派剑走偏锋，使用远程调用的方式达到跨平台的效果，多个平台的客户端通过COBRA或者EJB等形式使用服务器上的应用。

    这三种做法中，调用派暂不评论（个人认为这不是严格意义上的跨平台技术），而编译派与解释派的优劣也不赘述，因为相关文章太多太多，总结起来无非四个字：

    各有利弊。

    我们关心的是：Notes使用的是哪种做法？事实上，在跨平台方法的选择上也体现了Notes的兼容思想。通常，我们把Domino/Notes称为一个平台软件。作为一个软件，Notes的服务器程序（Domino），客户端程序（Notes），以及其他服务程序均使用编译派的做法实现跨平台，更具体一点，都是用C或C++编写在不同平台上编译而成（当然，新Notes客户端的研发计划Hanover基于eclipse，不在此列）。而作为一个平台，基于Notes运行的程序和数据（nsf）则是走的虚机派的路子，Notes程序本身起到了虚拟机的作用，解释执行不同Notes应用的公式和脚本，这也是为什么不同平台的Notes应用可以自由迁移，无须改动的原因。

    从实现来看，Notes这种做法很类似于Java虚拟机JVM。作为软件，JVM本身同样需要在各个平台上编译，编译好的JVM再去解释执行class文件。我的一个前辈，一个Notes资深人士曾基于二者实现的相似点，慨叹若IBM将Notes如JAVA般全力支持，未必搞不出个N2EE。对此我可以理解，但无法认同。Notes不单纯是一种编程语言，所以它做不到JAVA所能做的全部，但也因为Notes不仅仅是一种编程语言，所以JAVA也做不到Notes所能做的全部。

    闲话少说，继续来看Notes的架构。在这个架构中最核心的内容是NSF，全称是Notes Storage Facility——我一直不确定这个NSF和Notes数据库的后缀名.nsf有没有直接的关系，但请不要因此把NSF理解成一种存储方式。实际上，NSF是一种服务，是Notes对象服务NOS（Notes Object Service）中最大，最复杂的一种服务。NSF负责处理所有底层数据库相关的操作，比如说，创建一个nsf数据库，增加一个文档，修改一个域等等。

    既然NSF是NOS中的一种，那么毫无疑问，除了NSF之外，还有其他的NOS，包括NRPC（Notes远程调用），NIF和FT（这两个相信大家也不会陌生，分别做Notes索引和全文索引）等等，在此不一一列举了。特别介绍的是其中非常重要的一类NOS：Portability Service——顾名思义，这类NOS主要负责的就是屏蔽操作系统的底层细节，让其他NOS可以portable，因此可以说Portability Service是所有NOS的基石，包括Operating system services，On-disk structure (ODS) services，Network transport services。

    另外两个不提也罢，但是ODS是必须要简单说几句的：这是Notes对存储数据结构的一个抽象。为什么需要这个抽象？原因还是那三个字：兼容性。因为不同平台，不同处理器对诸如数据位对齐，低位优先还是高位优先这些问题的处理方式是不同的，不做抽象的话没法在不同平台上进行数据交换。关于ODS还需要多一句嘴的是，在Notes的发展过程中，ODS也同样经历了一些变化。R4,R5以及ND 6的ODS版本都是不同的，虽然这不会造成兼容性上的问题，但是某些新版本的新功能只能在特定的ODS上才能使用，例如单一模板技术（SCT）。

    当然，这些NOS之间也存在着相互调用关系，可惜当时没有一个专门的服务总线(Enterprise Service Bus)来协调这种服务调用，否则SOA的概念可以早提出10年。对于这些NOS，虽然我们开发和管理Notes时并不会直接感受到，但它们是时刻存在于Notes客户端和服务器之上的。如果你有幸（或者更应该说不幸）看过nsd文件——很多情况下，这种文件包含了系统崩溃之后服务器自动收集的故障信息——那么你会在线程的堆栈记录中看到NOS留下的蛛丝马迹，然后去查找相应的问题。——恕我直言，对于像我这样的非专业人士，nsd文件真的是很残忍。

    顺带说一句，Notes也能产生类似的nsd文件。因为无论是Notes客户端也好，还是Domino服务器也好，底层都是NOS。NOS能跨越客户端服务器，能跨越不同的操作系统，能跨越不同的硬件设施，其兼容性可见一斑。在Domino 7中，它甚至跨越了文件与关系型数据库的界限——虽然目前仅仅是DB2，但如果不考虑商务（请注意这个前提），对普通关系型数据库的支持也只是迟早的事情。对Notes而言，底层如何实现不重要，重要的是上层的NOS可以兼容于各种环境。

    对Notes兼容性的描述到此为止吧。毫无疑问，Notes是一个兼容性非常出色的软件，市场上主流的硬件和操作系统平台几乎都可以运行Domino(HP-UX除外)。即使是HP-UX，虽然从ND 6开始不再支持，但是在R5的时候也曾经支持过（不支持恐怕又是商务的原因）。另一方面，Notes承前启后的兼容策略保护了原有用户的投资，同时吸引了大量新用户的眼球，使得用户数在几年之内激增。如果没有这样的平台兼容性与前后兼容性，在微软帝国的强势进攻面前，一个非J2EE的系统要做到坚守邮件市场半壁江山是不可能的。

    不过我们前面说过了，兼容并包式的发展适用于锦上添花的变化需求，而在R 4.5以前，Notes也的确没有遇到“轿车变货车”式的挑战。但是很快，一种新的技术导向会让Notes面临一个新的需求。这种需求在未来若干年之内，让Notes从内到外经受了非常大的考验。为了满足这种需求，Notes增加了相应的功能，但该功能从加入Notes到现在，围绕它的争议与改进就从来没有停止过，直到今天，依然有许多人对Notes的这项功能持怀疑态度。

    因为这次要Notes变的，不是轿车也不是货车，而是飞机。也许在这潮流的一开始，Notes只给自己加了一对装饰用的翅膀，但很快Notes会发现，这对翅膀不只为了好看与流行，而是要真正能让自己飞，甚至要逐步取代自己脚下的轮胎。。。

    幻化的蓝莲花——Domino与浏览器

    米国的《独立宣言》告诉我们：人生来是平等的。站在人权的层面，这或许是正确的。

    但事实告诉我们，站在能力与天赋的层面，人生来是不平等的。有些人天生会唱歌，有些人天生会跳舞，有的人天生语言能力强，有的人天生对数字敏感。

    “Born to be or not to be”，天生适合什么不适合什么？这是摆在每个人面前的选择。但可惜我们大都没有行使这个选择的权力，在很多因素的影响（家庭，教育等）下，人们只能随着惯性，顺着大流去从事一些自己不那么喜欢或者不那么擅长的事情。

    但比天赋更重要的是：只要够勤奋，肯努力，我们一样可以把这些事情做得很好。

    人尤如此，软件亦然。对软件而言，同样有天生适合与不适合的分别。在某种特定背景下诞生的软件，自然而然具有某种特定的架构，适合于特定的用途。如果让某个方面已经较为成熟的一个软件，忽然面临一个崭新的需求，那么它也同样会有一个适应和转变的过程。

    对R 4.5时的Notes就是如此。IT界继PC之后最猛的一股浪潮席卷而来，给Notes带来的与其说是新需求，不如说是新压力。

    这股浪潮就是互联网技术，给Notes带来的压力就是对Web的支持。

    事实上，对互联网的影响力，Notes体现出了足够的技术敏感。虽然Notes在R 4.5才正式成为交互式的Web服务器，但对Web的支持早在两年前R 4.0的时候就已经提供。在R 4.0时用户已经可以将Notes转换成HTML页面，然后显示在web上。虽然只是一个静态的格式，但毕竟是一个开始。

    而互联网的飞速发展很快让Notes意识到，对Web的支持只做到这个程度是远远不够的，因为来自竞争对手的压力越来越大。所以1996年12月，IBM（95年完成收购） 推出Notes R 4.5，这种新服务器把互联网标准和协议的开放联网环境和 Notes 强大的应用程序开发设施结合起来，使企业和组织能够开发出业务的Web解决方案。也许是为了让这次变化更加有纪念意义，IBM为服务器取了一个全新的名字：

    Domino。

    可以说，Domino这个名字为了Web而生的，而此后的每一代Domino设计时，也都把对Web的支持改进作为非常重要的一个课题。

    1996年，Domino R4.5支持将Notes的内容动态发布到网页上，开创了OA系统的Web新时代；

    1999年，Domino R5问世，宣传口号是“生来与Web集成”；

    2002年，Domino ND 6诞生，这次它的身份是三元归一的服务器（以Domino+Notes为代表的客户/服务器体系结构(“C/S”)；以浏览器+Web服务器为基础的瘦客户机模式(“B/S”)；以关系数据库内容管理为主的体系结构(“RDBMS”)）,将Domino的B/S功能提到了与C/S功能等同的高度.

    。。。

    可以这样说:从诞生到现在，围绕着Domino服务器的web功能的改进就没有停止过.这些改进决不仅限于一些bug的修正，其中也包括很多模式上的修改。尤其是R5到ND 6，诸如活动线程处理模型这样的核心模块也做出了相应的调整，许多API或者函数也发生了变化（这也是为什么从R5到ND 6的B/S应用升级相对于C/S应用而言要复杂的原因），凡此种种，其目的只有一个，提高HTTP进程整体处理性能，降低对资源的占用。从实际使用来看，Domino的HTTP性能与功能确实是在不断的提高，而且每一个版本的改进相当显著。

    然而从诞生到现在，围绕着Domino服务器的Web功能的争议也从来没有停止过。

    对Domino服务器HTTP功能的置疑包括：

    HTTP容易挂起或宕机，访问速度慢，Web服务器功能相对简单。。。

    一句话，Domino不适合开发Web应用，因为它天生是做C/S应用的软件。

    后半句我绝对同意，Notes从诞生之初就是用作C/S应用。从上一节Notes的架构介绍中我们也能感受到这一点，Notes客户端既可以远程访问服务器上的nsf库，也可以不经过服务器直接本地操作nsf库，本地库通过复制技术与服务器进行同步。毫无疑问，这是一个非常漂亮的C/S（客户端/服务器）架构——更确切一点——胖客户端架构（可惜这个年头，连客户端都流行减肥）。

    回到本节的开始，“Born to be or not to be”，天生是什么不是什么？虽然R5时，Domino宣称过“生来与Web集成”（注意这个提法“集成”），但从根本上来说，Notes或Domino生来就是一种客户端/服务器应用，NOTES BORN TO BE A C/S APPLICATION! 这根本不用否认也无需否认，因为C/S绝不意味着落后与过时！（关于C/S与B/S的比较，在Domino的未来发展中我们还会提及，这里就不再赘述了。）

    没错，Notes天生是C/S架构，更适合开发C/S的应用。无论是在客户端开发中更多的设计元素，还是客户端使用中更多的界面功能，都表明了Lotus对Notes客户端的器重，但是，这不能作为Domino不适合开发Web B/S应用的理由。