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

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

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

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

兼容性。

[@more@]

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

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

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

这里我想说的是，对软件而言，没有一个必然最好的发展思路，正如同对人而言，没有一个必然最好的性格一样。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会发现，这对翅膀不只为了好看与流行，而是要真正能让自己飞，甚至要逐步取代自己脚下的轮胎。。。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8866403/viewspace-900902/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8866403/viewspace-900902/