张岭 (Zhang Ling's Blog)

过去的三个星期，是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环境下产生的数据生产者和消费者之间产生的老矛盾。