张岭 (Zhang Ling’s Blog)

这几天在帮助Connections的客户配置edge reverse proxy，下面是目前使用到的全部配置列表（安装了Blogs，dogear和Activities）：

ServerInit C:\Progra~1\IBM\edge\cp\lib\plugins\mod_rewrite\mod_rw.dll:modrw_init Transmogrifier

Transmogrifier C:\Progra~1\IBM\edge\cp\lib\plugins\mod_rewrite\mod_rw.dll:modrw_open:modrw_write:modrw_close:modrw_error

SSLEnable On

SendRevProxyName yes

Enable PUT
Enable DELETE

Map /blogs/* /connections/blogs/*
Map /dogear/* /connections/dogear/*
Map /activities/* /connections/activities/*

JunctionRewrite on

Proxy /connections/* http://wasserver/* :80
Proxy /connections/* https://wasserver/*:443

ReversePass http://wasserver/* http://myserver.com/connections/*
ReversePass https://wasserver/* https://myserver.com/connections/*

JunctionReplaceUrlPrefix http://wasserver/* http://myserver.com/connections/*
JunctionReplaceUrlPrefix https://wasserver/* https://myserver.com/connections/*

MaxContentLengthBuffer 5M

KeyRing C:\Progra~1\IBM\key.kdb

KeyRingStash C:\Progra~1\IBM\key.sth

最后两项的key database文件需要利用ikeyman导入WebSphere for IBM HTTP Server （IHS） plugins的证书以建立edge server和IHS之间的SSL连接。

此文专为搜索引擎供稿。

过去的三个星期，是Lotus Connections 1.0.2和2.0并行开发的三周，一边解bug，一边考虑实现新功能，ClearCase里面两条stream来回切换，不亦乐乎。1.0.2到这个周末算正式结束，进入最终release。1.0.2 Blogs除了修复了从1.0里遗留的30多个bug外，在性能方面也做了诸多调整；另外根据客户反映，恢复了MetaWeblog API的支持（与ATOM API共存）。Connections整体功能方面则支持Tivoli Access Manager，强制的ATOM basic authentication over HTTPS （写入部分，读取依然保持HTTP）；增加了AIX平台和MS SQL Server数据库的支持等一系列的改进。

目前正紧锣密鼓开发的Connections 2.0将基于Java 5构建，此前1.0.x基于JDK 1.4，虽然包含了部分1.5的代码，但使用了retroweaver保证这些1.5的代码运行在1.4的VM之上。2.0版的Blogs会在1.0.x基础上增加新的功能，UI方面也会有相当程度的改进与提高，这些工作目前都在紧张的进行中，不久就能看到阶段性成果。

reverse proxy(逆向代理)一般位于Web应用程序的前端，对用户屏蔽了后台的应用服务器。除了请求转发，动态负载平衡和缓存也是reverse proxy的主要功能。在配置逆向代理的时候，一个普遍存在的问题是URL转换。

比方说有一台应用服务器，它的访问地址是http://appserver:9080/app，该地址并不直接暴露和用户，而是由reverse proxy配置成一个对外可见的URL，如http://revproxy/home/app，它是用户最终在浏览器输入的地址。当reverse proxy收到这个请求后，把它转换成应用服务器地址后，将该请求（连同HTTP request header中的参数）转发给后台的应用服务器；应用服务器返回的内容再经reverse proxy，最后回到用户浏览器。

一个常见的问题是如果应用服务器返回的HTML页面包含了在该应用服务器上有效的绝对或者相对路径时，reverse proxy该如何处理？如果是绝对路径的话，那么用户在点击页面上这个链接的时候就会跳过reverse proxy直接连到应用服务器上；如果是相对路径，如”/app” 的话，那么如果reverse proxy自己的URL前面又填加了新的目录名，如上面提到的“/home”，那么这个URL到用户那里就会成为”http://revproxy/app”，同样也是错误的。

reverse proxy的一个重要功能是地址转换，在WebSphere Edge Components（早先的 Edge Server）里可以通过配置一些地址转换规则来解决这个问题。它的工作原理大致是这样：在reverse proxy收到从应用服务器返回的HTML内容后，对其进行内容扫描，如果发现如”href”, “src” 等之类包含URL链接的标签时，根据预先设定的规则把它们替换成对外可用的地址。这样原来页面中的绝对、相对地址经转换后成为最终用户可以访问的地址。需要注意的是，reverse proxy对HTML的扫描是有一定限制的，如果这个绝对或者相对的URL是嵌入的JavaScript里，通过在浏览器端解释动态生成，或者存在于其他一些非链接性质的标签中，reverse proxy是没有办法对这些URL进行转换的。这样漏网的URL将直接暴露给用户。

解决页面中无法被翻译的绝对地址，似乎必须要修改应用程序；而对于无法被翻译的相对地址，可以在reverse proxy通过URL映射来解决。URL映射的原理是当reverse proxy接收到来自用户的HTTP 请求后，如果该URL满足预先定义的模式，则进行替换。比如在WebSphere Edge Components 中可以设定如下的地址转换规则：

Map /app/* /home/app/*。

如此一来，URL地址的转换问题基本得到解决。现在，还剩下两个问题需要考虑：

1. 当后台的应用服务器通过HTTP 301/302进行地址重定向的时候，reverse proxy必须也对该地址进行翻译。在edge中，可以使用下面的命令实现：

ReversePass http://appserver:9080/app/* http://revproxy/home/app/*

2. Cookie的作用域

当用户在应用服务器上登录后，往往会得到一个或多个cookie。在J2EE环境下，服务器端的session变量会产生一个名为”JSESSIONID“的cookie变量送给浏览器，同时指定该变量的作用域，如”path=/”或者”path=/app”。如果是前者那样的根目录，则没有问题，但如果是后者的话，如果reverse proxy原封不动的将该cookie值转发给用户浏览器的话，那么当用户再次发出如”/home/app”，这样的URL请求时，此cookie是不会放在HTTP请求头部中的，因为这个请求的作用域是“/home”，而不是”/app”。cookie作用域失效往往表现为用户的”伪登录“，即在后台服务器上已经登录但通过reverse proxy的话还是出现无法正常登录的情况。

在edge components里，可以使用下面的配置方案解决cookie作用域修改问题：

JunctionRewriteSetCookiePath /app/* /home/app/*

不过由于WebSphere Edge Components 6.1里的一个bug，该功能存在故障，需要获取指定的补丁更新方可使用。

另外，在应用服务器这端，如果可以指定cookie的path永远为根目录，会减少很多麻烦（在Lotus Connections 1.0/1.0.1里，cookie的path为根目录”path=/”以实现多个功能模块的单点登录SSO）。我在Tomcat下测试时发现，Tomcat生成JSESSIONID时，缺省的path就是当前webapp的context root，而不是根目录。如要强行指定Tomcat生成的cookie的path，需要在其”server.xml”配置文件中的”Connector“段中加入‘ emptySessionPath=”true” ’。

有关reverse proxy，如edge components中还有很多复杂的问题这里尚未涉及，如SSL连接、证书等网络安全相关配置。希望此文可以给reverse proxy，尤其是IBM WebSphere Edge Components的用户一点帮助。

PS:有关edge 6.1的配置，目前最完整的官方文档在此。

这本昨天发布的红皮书在我最近的阅读列表中。Container环境下的classloading是无数诡异问题的根源。以Lotus Connections 1.0.1来说，我们用了icu4j来提供一个时区列表，icu4j本身自带了这些列表的翻译，比JRE自带的要全。但在测试的时候发现WAS 6.1.0.3下的时区列表繁体中文的显示有问题，混入了大量简体中文字符。其原因在于WAS自带了一份icu4j并且早于webapp下的lib被container加载，而这份icu4j自带的时区翻译存在问题。

对于长期从事WAS应用开发的IT工作者，这是本必读书。

下午在对Blogs新收到的语言包进行压缩、编码转换并用CHKPII工具检测后（PII是IBM专用词汇，即Program Integration Information的缩写，意指需要和程序一起build的语言资源，不包括帮助文件等），放到local build里跑了一圈，验证一下Group 1里面9种语言的显示界面。在切换到繁体中文的时候，看到了“部落格”。

这是台湾对“blog”的翻译，挺生动，让我联想到了“四四格”。

从上面的截图看，Blogs多语言的支持除了语言包外，还有不少细节需要处理，如上面那个“18 5月”的格式化问题。

IBM宣布了对Watchfire的收购，并购之后的Watchfire将并入Rational旗下。

Source code security (vulnerabilities) analysis是这两年静态分析领域的热点，3年前Rational Application Developer 6里开始提供了Code Review，不过在security检测领域没有提供很强的支持， 倒是一些独立的软件开发商，如fortify在这个市场里玩的红红火火。微软也不干寂寞，玩起了FxCop (.NET assembly code analysis)

Watchfire的并入势必带来Rational Code Review模块的重构（从RAD 6到RAD 7已经进行过一次升级），IBM内部若干个静态分析引擎面临一次新的洗牌。

Lotus Connections 1.0中的Blog实现了两层的缓存机制试图更好的解决性能问题。第一层是Application Server对某些访问频繁数据的缓存；另外一层是在HTTP reverse proxy上，对特定URL资源的本地缓存。缓存对改善性能，尤其是对实时性要求相对较低的Atom feed来说，性能改善的效果更明显。

考虑对数据实时性，Connections Blog缺省关闭了application server的缓存，这样用户在发贴或者回帖后刷新页面立刻可以看到更新，否则从数据写入到reload会有一段时间间隔，容易造成用户困惑。

这里想谈的是HTTP cache。

Blog的典型配置是用DB2数据库，WebSphere appserver，前端是network dispatcher和edge。edge实际是一个HTTP reverse proxy，实现URL转发和内容缓存的功能。 为了实现对Atom feed访问的缓存，Blog会在每个feed的http response的头上面缺省加上max-age=600，response首先到达edge，edge收到后知道需要将该feed缓存600秒。当下次用户通过浏览器、各类feed reader或者是抓虾这样的server端访问的时候，edge首先看feed的10分钟缓存期是否到期，如果还在10分钟内，edge之间把它的cache返回给用户而不再访问appserver；如果已经超过10分钟，edge会向appserver发一个HTTP conditional get的命令，看application server端是不是有新的feed内容。Application server收到feed的请求后，如果有新的feed内容，则向edge返回新feed内容，response code置成200；如果没有更新，则不返回任何内容；response code置成304。无论是否有更新，edge在重新收到appserver的返回后，将重新缓存该feed 10分钟。依次类推。

当在没有edge的情况下， 可以用浏览器来模拟。当在10分钟间隔内，如果在地址栏之间回车的话，浏览器甚至不会与服务器建连（可通过LiveHTTPHeader或者ieHTTPHeaders之类的browser插件观察）。目前Firefox和IE对max-age都可以很好的支持。

在实际情况下，大部分feed源本身并没有类似edge这样的模块，而是直接把appserver暴露给client。从实现上看，很多feed reader对last modified时间戳的管理都很弱，会导致每次都迫使appserver重新加载数据。另外，在server端有些feed server也没有实现对if modified since的管理，无论什么请求都重新进行数据访问，这样都增加了额外的负载。

这是Connections Blog的tech lead Rob在调试feed cache的时候发给我的一篇文章，写的很详细。另外来自IE team的这份A Caching Issue in IE7 Beta 2也很有帮助。

从Feed出发，此类提高性能的缓存方法可以常态的运用在如REST等基于HTTP，以URL来映射资源的应用上，来帮助克服传统Web Server/Web browser多年前已经完美解决了的、而重新在Web 2.0环境下产生的数据生产者和消费者之间产生的老矛盾。

IBM developerWorks正式开放了空间注册，提供blog，forum和wiki的服务。在填写完spaces注册申请后需要经过dW的审核 – 我刚刚回复了一封email解释我申请的原因和打算如何使用dW服务。

PS: Introducing developerWorks spaces 

过去的两天，我只写了两行代码。

这两行代码分别解决了Lotus Connections Blog中的两个bug，平均一行代码耗时10小时。

其中一个Blog编辑器中的bug，是通过几十次的blog发贴，用Venkman的Firefox JavaScript Debugger抓到的，该错误源自Firefox和Dojo自身的缺陷。因为一天中发测试贴太多，现在在自己博客发贴也有点心理障碍了。

另外一个是Blog的Theme切换问题，为此还动用了Filemon这样的工具，监测javaw.exe对文件系统的修改，在追踪到数据库文件被修改后，进而跟踪DB表变化，加上Eclipse debugger，最后才确信需要把else后面那个”}”提前一行。

在involve到Lotus Connections的开发后，最大的一个变化居然是自己发贴、看social bookmark的兴趣降低了- 搞伤了，就像我现在看到早餐的炒蛋和薯角一样，刚闻到味儿，就半饱了。

Apache Abdera是实现对Atom格式解析，发布（APP, Atom Publishing Protocol）的Java类库，IBM最早参与并提供了代码。Abdera之前，ROME是另外一个重要的Atom实现（身在java.net，贴的是Apache license）。这篇文章里谈到了Abdera和ROME的渊源，我在上面、还有这里看到了一些熟悉的名字。

Lotus Connections 1.0里的Blog，同时使用了Abdera和ROME类库。

最近Apache的新闻很多，比如Harmany和JCK，杨普这篇文章是了解这次公开信事件的最佳入门教材。

Lotus Conections 1.0中Blog使用了Dojo的rich editor，这个editor的基本功能比较完善，各方面大致与其他流行的editor如WordPress中使用的TinyMCE持平。由于大部分Dojo的Widget对于i18n和a11y (accessibility)支持较差，IBM对其进行了增强。目前Blog里使用的版本就提供了较好的a11y支持，比如在editor中按tab键会跳出编辑状态，把焦点转移到下一个控件上。现在这个功能可以同时在IE和Firefox里实现 (调试HTML的tabIndex是个很熬人的工作）。

另外，我帮目前Blog的editor添加了离开编辑模式的提示功能 – 当用户写帖子的时候如果点了其他link或者准备关掉浏览器，这个时候弹出窗口警告内容已经过编辑，是否需要离开编辑模式。

用户登录后写文章，如果中间间隔较长的话，会出现提交数据会话过期的情况，数据往往会丢失。根据测试team映的反应，我写了一个heartbeat脚本，在浏览器端定期ping远程的server。在WebSphere下，如果提交的link可以促使Application server访问session对象的话，当前session将会续约，这样可以保持长时间的可工作状态 (缺省为30分钟)。

今天在Mozilla add-on上下载Coop的时候，看到了ScribeFire，装上后就用它写了这个帖子，还挺好使。

Powered by ScribeFire.

这5个东西组成了Lotus Connections：Blog, Dogear, Profile, Community和Activity。

Blog（我目前参与开发的模块）是基于Apache Roller的博客系统，IBM在Roller之上进行了修改和扩展（比如认证系统可以与LDAP，如Lotus Connections Profile连接）。Lotus Connections Blog的前身是IBM的内部系统BlogCentral，几年前在内部上线，并经过了多次修改，新版本的Blog在UI等方面做了大量更改，使用了包括Dojo在内一些Ajax组件；

Dogear的前身是由IBM Cambridge的Lotus研究部门开发的一个社会书签系统，进而演化成目前的Connections中的一个组件。通过用户添加书签、打tagging和浏览器插件，支持快捷的书签生成与共享；

Profile的前身是IBM的BluePages，它是IBM内部的企业员工名录，使用过的人都知道它的强大功能，包括公司组织结构图、个人信息、技能、参与的社区、服务过的客户、发表的论文专利、个人简历都可以搜索，甚至可以在网页上和名录的员工通过Sametime在线聊天；

Community的前身也是一个IBM内部系统， 同样经过了多年的进化。每个community由来自公司各个部门的员工参与，有专门的“版主”，负责社区活动组织、通知、协作等等。Community是在需要时找人、找资源的有效途径；

Activity是一种轻量级的、基于Web的协作系统。多个人可以参与同一个activity，共享数据、活动进度、协调跟踪事件等等，集成了Calendar和Todo软件的某些特点。

上面5个模块都是基于Java，运行在WebSphere Application Sever之上，是IBM踏入企业social computing的尝试。当然，如果愿意的话，可以给它打上Web 2.0, Enterprise 2.0, Collaboration 2.0的标签，在我们这个business 2.0的时代。

春节长假比上班还忙，回家在成都呆了一个礼拜，赶回上海后马不停蹄的去为香港经济做贡献，回到家刚刚知道今年图灵奖的结果。

在网上看到Allen的照片和获奖介绍后，回想起04年曾经在Yorktown的Watson研究中心的餐厅里看到过”IBM退休老兵报告团”回到公司为年轻人传、帮、带，主席台上里除了慈祥的老奶奶Allen外，还有DRAM的发明人Bob Dennard。

根据对社会的贡献而言，Tim Berners-Lee在10年后获得图灵奖应属情理之内。