【IT168 专稿】

    今天在版上看到一篇文章，Lotus的范畴。指出了现在Lotus产品线包含的四个系列：Domino/Notes，WebSphere Portal，Lotus Workplace，WebSphere Everyplace。

    这个范畴，也对也不对。对是因为在很多IBM官方的介绍中，确实是这样描述的。不对的原因也很简单：一切事物都是发展变化的。上面这种划分并不能代表Lotus软件最新的技术发展。Lotus在变，正如同一朵幻化的蓝莲花。

    如果你仔细关注过Lotus的变化，你会发现这种变化中有明灿，也有暗涌；有绚烂，也有阴霾。Lotus这朵蓝莲花，美丽，但并不完美。Lotus的变化，积极，但并不平稳。

    所以它在变，因为它所生存的土壤叫IT，依赖的水分叫软件，这个环境下，想不变？那就等着拿回家做莲藕排骨汤吧。

    但所有的变化都是无法确定的，可以衡量变化的只有一样东西：结果。在惨烈的软件市场竞争中，能够适应并生存下来的就是正确的变化。否则即使概念再好，也无法形成主流。

    成王败寇，有时就这么简单。大浪淘尽的，是无数风光的噱头和虚名，留下的才是真正值得信赖的东西。

    从莲花软件幻化出的Lotus

    现在去很多客户那里，他们还称Lotus叫莲花软件，问及现在所用的邮件系统或者OA系统，回答都是Notes而不是Domino。

    我知道他们的回答并没有任何问题，只是他们的回忆停留在了更早远的年代。在那个年代，莲花公司的Notes，是服务器和客户端的共同的名字。这个光荣的名字几乎代表了整个Lotus软件的全部；在一段时期内，它也代表了群件(Groupware)的全部；在更长的一段时间内，它还代表了办公自动化的全部。

    “冲天香阵透OA，满城尽带黄莲花！”

    但一切事物都是发展的，Lotus也不例外。当J2EE、.NET越来越多地出现在人们的视野；当OA系统越来越不只是一个简单的OA；当Notes从一个整体的名字演变成客户端的代号；当Lotus从激情的黄变成深沉的蓝。一个时代结束了，一个时代开始了。

    现在还听到有人在感叹：IBM收购Lotus，对Lotus软件本身带来了很大的负面影响，例如老用户的流失、产品的变化等等。言外之意，如果莲花仍然是黄色的，那么现在在协作市场，基本上就没有微软什么事儿了。

    真的如此吗？一个事实足以说明问题，IBM收购Lotus是在1995年（对软件而言，这已经是远古的事情了），而在这之前Lotus的用户数是350万。而被IBM收购之后，2001年左右，这个数字是1.2亿，现在则是1.8亿到2亿。

    还是那句话，结果说明一切。

    除了接近2亿的用户，IBM还给Lotus软件带来了其他东西。

    98年即时消息产品Sametime诞生。

    99年收购德国OneStone公司产生工作流引擎LotusWorkflow。

    2002年WebSphere Portal产品划归Lotus。

    2003年Lotus Workplace诞生。

    2004年收购澳大利亚APTRIX形成Lotus WCM产品。

    2005年收购PureEdge提供eForm电子表单解决方案。

    同年收购Bowstreet形成Portlet factory解决方案。

    2006年WEA、WED等无线解决方案加入Lotus阵营。

    2007年Quickr、Lotus Connections等企业内社区软件进入Lotus产品发布的起跑线。

    IBM收购Lotus，得到了它的名字、它的技术、它的产品。这之后，IBM把黄色的莲花重新染成深蓝色，并修剪它的枝蔓。在这场变革中，IBM当然不可能只做我们上面列出的这些加法。事实上，有许多曾经（注意是曾经）出色的Lotus产品慢慢退出了历史舞台。在软件业的减法中，这些产品渐次凋零，如同盛开的蓝色莲花下飘落的黄色花瓣。但抛弃它们的不是IBM，而是软件市场适者生存的法则。

    Lotus，IBM得到你，改变了你。从你身上，IBM获得了一个最好的IT前端，获得了一个最稳定的邮件方案。以此为依托，IBM可以建设它的SOA前沿阵地，在协作和人员整合领域与最强大的竞争对手相抗。没有你，IBM怎么构建完整的SOA？没有你，IBM怎么去谈“端到端的整合”？

    这一切，都是你给IBM带来的。然而，IBM给你的更多。

    Notes的诞生

    关于Domino/Notes的历史，我们不用重复赘述，版上曾有一篇文章详细介绍了它的诞生过程。官方的资料显示第一代Notes诞生于1989年，但是产品成型的时间比这个还要更早。

    1984到1986，一个简单的原型＋几个志同道合的伙伴＋无数天才的创意＝一个划时代的产品。不是所有的软件产品都可以获得“划时代”的评价，但Notes当之无愧。

    时光倒转20年。

    你现在是一家公司的员工，你每天上班要面对的是一大堆文件和用信封装好的邮件，然后给客户挨个打电话，接电话。也许你所在的公司财大气粗，给你配备了一台奢侈的电脑，最老式的苹果机或者x86。

    聊胜于无吧（事实上，在20年前，你拥有一台苹果或者x86，其NB程度远胜于你现在拖着一个T60p）。对此你很不满意，但只好作罢，但接下来你老板很宽宏大量的对你说，小陈啊，这台机器归你用了，你可以用它打打字，输入一些公司的重要资料。然后故作神秘的对你说：下班后，还可以用它玩玩游戏。我知道有个《警察抓小偷》（不知道大家是否记得这个游戏，可能有的地方管它叫吃豆子）的游戏，很好玩哦。

    你可能会请示老板，我能不能上个MSN或者QQ呢？另外，我的公司电子邮件是什么？（很多现在的上班族都具有没有电子邮件不能活的恶习）。

    然后你老板会问：什么是MSN？什么是电子邮件？我们这里邮件很多，都很安全，不带电。

    五分钟以后，你醒过来，对你的老板说：那我能上个网吗？

    这次你的老板没让你失望：网络？没问题，我们公司刚建好了内网。现在机器之间也能共享一些文件。速度很快，1秒能有好几k呢，就是老断......什么？你要上Internet？什么是Internet？

    十分钟之后，你醒过来，这次你没有再去骚扰老板，而是挣扎着开机。你等了很久，看到了Windows几个大字，但是看不到屏幕上出现蓝天白云，取而代之的是一个极其简陋的图形界面。你以为是Windows启动故障，所以不断的重启机器，直到烧了主板......

    省省吧，你生活在20年前，那个年代，没有一个真正封装完好的个人操作系统，没有互联网，极少的内网系统还面临着网络速度慢，运行不稳定的问题。更不要提什么即时消息、网上办公等等这些概念了。

    那个年代，没有人想过，电脑可以用来构建一个虚拟社区，可以用来彼此传递消息，可以有一种商用的客户端/服务器的架构来搭建系统，可以有一种名叫群件(Groupware)的软件改变无数人的生活。

    直到Lotus Notes告诉大家：是的，你们可以。虽然这个时代的IT缺少很多东西，但是有了我，上面这一切就不再是梦想。

    因为所谓的传奇就是“无”中生有。

    没有一个成熟的操作系统，Notes就编写大量系统级代码，设计了可运行于多种平台的NSF结构；没有一个稳定的网络环境，Notes就引入了replication复制技术，保证数据同步。

    在这种环境下诞生的莲花，不折不扣的是一朵奇葩。

    左手NSF，右手Replication，Notes凭借着天才的构想开始了它的征服。

    还是让我们来看看，Lotus Notes在它的征程上究竟做出过怎样的创举吧。

    Lotus Notes——第一套重要的客户端-服务器形式的协作软件系统。事实上，如果考虑到那个年代的软件应用的实际情况，我们完全可以把“协作”二字去掉。

    Lotus Notes——第一套（目前依然是最大的）应用PKI加密算法的重要软件。

    Lotus Notes ——第一套使用内置SMTP协议的消息平台系统。

    Lotus Notes ——......

    这样的软件不能被称为“划时代的”，谁能？

    1989年，普华永道(Price Waterhouse)在看了Notes的演示之后，购买了10000个licence。

    这在今天看来实在不算一个很大的单子，但在20年前，10000个licence是有史以来一种软件产品的最大PC销售量。而普华永道给Lotus的也不仅仅是这样一个“巨单”，通过对Notes的使用，它做了一个预言。

    作为一个咨询公司，普华永道平生说过无数的预言，但是这一个我认为是最准确的。

    “毫无疑问，Lotus Notes将改变人们的商务模式。”

    是的，改变！在那样简陋的IT环境下，Lotus看到了将会发生的改变，它看到了人们将坐到电脑前进行他们的日常办公而不再只依靠电话和传真，它看到了沟通将伴随着网络的发展而无所不至，它看到了电子邮件，即时消息成为交流的首选，它看到了虚拟办公室，虚拟社区替代了真实。

    相信我，这一切一定会发生。但是眼下，Lotus Notes，就从这里出发吧！

    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应用的理由。

    那么其他理由呢？

    HTTP容易挂起与宕机？

    ——在我的印象中，所有Domino任务里面，HTTP的确是比较容易宕机或者挂起的一个，尤其是挂起。HTTP挂起往往带来比较恶劣的影响，因为用户会在第一时间发现服务请求得不到响应，管理员的电话瞬间就会被各式各样的投诉占满。HTTP挂起往往是所有Domino故障中最让人痛苦的一个，因为可能造成HTTP挂起的原因非常多，要准确定位HTTP挂起的原因一般需要打开服务器的debug参数，获取故障时所有HTTP线程的httpr记录。。。一句话，管理员们都不喜欢看到HTTP挂起，但很多情况下却不得不面对。

    我曾经在很多Notes开发论坛上看到请教解决挂起问题的帖子，也有很多人分享自己的一些经验，不过很多时候，这类帖子往往以这样一句话收尾：“Domino的HTTP进程就是容易挂起，升级一个新版本吧。”

    升级的确是一种解决问题的好办法，但是对挂起并不总是有效——或者应该说，很少有效。这是因为，从IBM 800以及IBM 服务人员解决挂起问题的经验来看，绝大多数的HTTP挂起的原因都不是Domino自身的bug，而是应用开发。

    举一个例子，比如在应用开发中，如果用到了java代理或者servlet，申请了Notes object之后，有没有释放？有释放的话，释放语句写在什么位置？是try模块里还是finally模块里？这看似一个很初级的问题，但是在很多情况下就是这种编程风格的巨大漏洞会造成java的内存无法回收，从而引起挂起。——补充一点，我个人认为，JAVA的GC（垃圾回收）机制是一个非常可怕的东西，不是说这个思路不好，而是说很多开发者错误的认为有了GC机制就不用在编程中考虑Java的内存回收，这是非常致命的编程隐患，对J2EE和Domino应用都是如此。

    其他可能的问题还有，对一些共享资源没有添加锁机制，导致http线程间出现死锁。初步确定这种问题的方法也很简单（注意，是确定而不是解决），把server文档中同时运行web代理的选项选成否之后问题往往会消失，但性能也会大幅下降（所以只能用来确认问题而不是解决问题）。这种情况下需要仔细排查代码，找到问题的所在。所用的工具嘛。。。sigh，还是那个残忍的nsd。。。建议最好还是交给专业人士去分析吧。

    还有用户或者开发商希望在Domino HTTP挂起之后，可以通过调整参数解决问题。例如增加活动线程数，取消持久连接，增加最大连接数等等，某些情况下，这种做法可以降低挂起几率，但正如上面提到的，绝大多数的HTTP挂起的原因还是在应用开发上。如果代码中的问题不彻底找到，那么负载一旦加大，挂起依旧会出现。

    另一方面，Domino HTTP自身有没有bug或者漏洞？当然有，也不少（只要是软件就一定有bug），但是远远没有多到可以把所有的HTTP问题都推给升级或打补丁来解决的地步。即使在R5甚至更早的版本上，Domino都不乏大量B/S成功案例，而在今天国内许多开发商也都是基于Domino的Web功能在开发应用。在开发调试或者运行过程中，谁没有碰到过挂起？恐怕很少。但好的开发商会按照相应的步骤去调试，在厂商的帮助下定位挂起的真正原因，而不是一遇到挂起就去归咎于产品本身。类似于Java内存回收漏洞这样的错误，无论是放在Domino的什么最新版本上，或者放在WebSphere，WebLogic的什么最新版本上，都注定会引起系统的崩溃。

    总而言之：

    一，Domino的HTTP本身并不会那么频繁地挂起，但某些不好的开发习惯会引发这一点；

    二，升级或者打补丁可以防止一些问题，但永远不是解决问题的最好手段，除非厂商在分析原因之后建议你这么做。

    至于Domino HTTP访问慢，我想这个问题较之挂起更加难于解释（或者说易于解释）。因为性能调优绝对不是某一个功能的责任，而实在是一个难以一言蔽之的东西。

    首先，没有任何测试结果表明Domino在动态页面这个领域的表现上弱于JSP，ASP或者PHP（著名的3P）——而有很多数据表明JSP的性能的确是优于ASP和PHP的——如果考虑到Domino支持servlet，而servlet与JSP实际上就是一种技术的两个层面这个事实的话，那么完全可以说，Domino的动态页面能力是相～～当不错的。

    更重要的是，HTTP的访问速度取决于很多东西，HTTP服务器的处理能力只是其中一环，且并不是决定性的一环，相比之下，页面的复杂程度，架构模式以及服务器的硬件调优是更加影响用户响应时间的因素。很多情况下，用户只是看到了最终结果——用浏览器访问Domino速度慢，便得出了Domino HTTP访问慢的结论，而没有看到这个慢的原因可能是慢在Domino与外界关系型数据库的连接上，可能是慢在服务器的IO上，可能是慢在那一时刻的代理大量运行上，可能是慢在网络传输上。。。在很多情况下，用户看不到也不需要看到这一切，他们只需要得出结论：HTTP 访问慢！

    作为用户，做出这样的判断无可厚非，因为他们只需要也只应该面对浏览器去使用Domino系统。但是作为管理员或者开发商，要做的事情绝不只是简单地附和，然后把问题再次甩给Domino平台的升级，而应该耐心地定位具体造成HTTP访问缓慢的原因，并制定相应的对策。调优是一件很复杂的工程，Domino虽然封装性很强，能够帮程序员自动实现大量底层代码，但这并不意味着开发好NSF之后就大功告成。对一个健壮的系统而言，开发完成仅仅只是一个开始。

    关于HTTP性能调优，有一篇Notes的官方文章“Improve Web Site Performance”，堪称这方面的bible。开篇第一句话就是：

    Improving the performance of your Domino servers is an art. There are no hard and fast rules。

    因为本为艺术，所以法无常法。

    再来说说Domino HTTP功能简单的问题。说Domino HTTP功能简单，恐怕是相对于Apache，或者IHS（IBM HTTP Server）来说的。对此，我想说的是：Domino的HTTP本来就不应该单纯和Apache或者IHS进行比较。因为后者只是单纯的完成HTTP服务器的功能，而Domino的HTTP功能主要目的是将内容转换成动态网页。有人会将WebSphere内嵌的HTTP服务器与IHS做比较吗？不会，因为单纯做这样的比较没有任何意义。

    之所以会有Domino HTTP与Apache等HTTP服务器的比较，我想主要还是源于Domino自身四合一服务器的特性（Web服务器，邮件服务器，应用服务器，目录服务器四合一），导致了IBM自己或者第三方评论机构将Domino与Apahce，WebSphere, IIS, Exchange, Sun one LDAP, IDS等等各式各样的产品进行比较——有时真不知道这是荣幸还是不幸。

    从具体使用来看，应该说，Domino HTTP功能（单纯的HTTP功能）是相当不错的，微软早些时候在评价业界HTTP服务器时，也将Domino作为一款优秀的HTTP服务器加以罗列。但请不要因此就用Domino去替代Apache或者IHS，相反，如果在构建大型HTTP应用的时候，还可以考虑将IHS等Web服务器与Domino相结合。利用IHS对HTTP访问的良好管理和控制（例如静态缓存技术），增强整个Domino系统的性能。这是一个很好的架构，虽然在国内这样部署的不多。

    所以在我看来，以上这种种对其HTTP的性能与功能的置疑并不能成为否定Domino/Notes的理由，还是那句话，Notes/Domino天生是C/S架构，更适合开发部署C/S应用，但这并不妨碍它成为业界认可的一款B/S服务器。为了获得这种认可，IBM在产品方面也确实做出了很大的改进，HTTP服务器的架构以及API方面的改动直到6版本之后才算基本定型，Domino大部分功能尽量做到在C/S和B/S上都能正常使用。

    值得吗？当然值得。

    还是R 4.5时，Notes就已经猜想到互联网引发的这股浏览器风潮迟早会刮进协作领域，逐步改变用户访问习惯。但Notes能猜到开头，却未必料想到有朝一日B/S应用会真的开始取代C/S应用成为主流。90年代初Sun曾经高喊过“网络就是计算机”，喊的时候为时尚早，但现在再看却已经不只是一句豪言壮语。且不说公网，目前在企业内网中基于Web的应用都越来越多。不只是邮件和公文，还包括许许多多其他业务系统：报销，CRM，ERP。。。甚至连字处理（Word），表格处理（Excel）这样的C/S传统优势项目，也开始受到像Writely这样在线字处理工具的冲击。

    而这一切，仅仅还是Web 2.0概念尚未完全铺开时的局面。

    一句话，B/S是一种趋势，虽然未必不可逆转，但是现在只有适应它才能生存下去。

    生存！生存！生存！只有在生存之后，Notes/Domino才可以考虑接下来的发展。。。或者它会在B/S应用方面，继续增强对J2EE的兼容，在Servlet的基础上进一步的支持类似于EJB container这样的架构？（关于EJB container的增加，没有任何的官方说法，但“空穴来风，未必无因。”）

    又或者，Notes/Domino会在C/S应用方面，继续做出孜孜不倦的探索，找出一种新型的客户端，谋求突破......