2.
篇首语 Editor’s letter
放慢你的脚步
3 月的北京乍暖还寒，但万物复苏的迹象已势不可挡，君不见小草已展露出嫩绿的枝叶，湖
中的鸳鸯自由地戏水，年轻的朋友结伴出游，生机盎然的春天正向我们悄悄走来。
作为软件行业的从业者，你是否每天都行色匆匆，
“两耳不闻窗外事，一心只想写程序”呢？
在这个信息爆炸的时代，快餐文化似乎成为了社会的主旋律。人们快速地奔走在路上，熙熙
攘攘而来熙熙攘攘而去，不肯作稍稍停留，一个“忙”字几乎成了我们每个人的口头禅。忙
得只顾眼前、忙得天昏地暗、忙得颠倒了白昼、忙得失去了生活......
当加班已经成为了习惯，当为了工作而丧失了生活时，朋友，你是否想过这是你想要的么？
费心劳神地去寻找风景，孰不知你就在风景之中？忙忙碌碌地在找寻幸福，岂不知幸福就是
一种感受？
人生犹如一次漫长的旅行，走的累了，不妨放慢一下你的脚步，换一种心情，休息一下，放
松一下。要知道，追求的意义就在于追求的本身；成功的快乐就隐藏在成功的过程中啊！
朋友，请放慢你的脚步吧，每天上下班多走一段路，观察一下沿途的风景，体会一下静谧的
心灵，你会发现生活原来还有这么多的乐趣，不需要我们付出多少努力就能获得的乐趣，一
种来自于内心深处的乐趣。
本期主编：张龙
i

3.
1

4.
目 录
[篇首语]
放慢你的脚步 .................................................................................................................................. I
[人物专访]
IAN ROBINSON和JIM WEBBER谈论基于WEB的整合 ........................................................ 1
[热点新闻]
ECLIPSE VIRGO项目获得批准 .................................................................................................13
APACHE BEEHIVE正式退役，迁移到APACHE ATTIC上 ..................................................15
CHROME 4 现已支持HTML 5 WEB SQL DATABASE API .................................................17
FLEX开发者需要知道的 10 件事 ............................................................................................19
CWE/SANS发布 2010 年 25 个最危险的编程错误............................................................22
GOOGLE将不再支持老式浏览器 .............................................................................................24
SOA设计关乎契约还是服务实现？.........................................................................................26
CHROME中 5 大安全增强.........................................................................................................28
AMAZON EC2 因订购过多而导致内部网络延迟？.............................................................31
全景透视ORACLE对SUN的未来规划......................................................................................34
MONOTOUCH已支持APPLE IPAD..........................................................................................40
[推荐文章]
类加载器特技：OSGI代码生成................................................................................................42
模块化JAVA：声明式模块化.....................................................................................................55
ii

5.
加密因特网....................................................................................................................................64
SOA访谈和书摘：EBEN HEWITT的新书《JAVA SOA COOKBOOK》...........................77
微型ORM——用VB和C#编写的动态类型ORM，只有 160 行.......................................83
[新品推荐]
NEO4J：基于JAVA的NOSQL图形数据库...............................................................................95
GOOGLE发布.NET版YOUTUBE SDK......................................................................................95
RAILS 3 首个BETA版发布.........................................................................................................95
.NET 4 的新特性：图表、SEO及可扩展的输出缓存..........................................................96
IRONJS——面向DLR新的JAVASCRIPT编译器 ...................................................................96
IRONPYTHON与IRONRUBY新RC版发布 .............................................................................96
JAVA EE 6：EJB 3.1 的变化引人注目.....................................................................................97
SPRING.NET 1.3：VS.NET SOLUTION TEMPLATES、MSTEST支持及SPRING
INTEGRATION.NET....................................................................................................................97
[架构师年度展望]
2010 年大规模技术架构的思路 ..............................................................................................98
豆瓣首席架构师洪强宁的年度展望 ..................................................................................... 101
凡客诚品架构总监栾义来的年度展望................................................................................. 103
淘宝架构师岳旭强的年度展望.............................................................................................. 105
一个技术观察者的年度展望 .................................................................................................. 108
[封面植物]
蝴蝶果 ......................................................................................................................................... 111
iii

6. Mi o ot i a Su i 2 1
c S fVs l tdo 0 0
r u
全球发布会
2 1 年4 2
0 0 月1 日，Mi o ot i a Su i 2 1 发布盛典将于北京盛大举行，
c s fVs l tdo 0 0
r u
2 1 年全球开发界这一盛事，将令中国开发同仁有幸全球率先领略Vs a
00 i l
u
Su i 2 1 全新特性。届时，微软全球资深副总裁张亚勤博士等多位微软高层，
tdo 0 0
以及来自微软总部的多位研发团队核心成员，将亲临发布会现场，共同
解密微软新一代开发平台的革新之处，实现更完美的C dn 梦想。
o ig
支持Wid w A ue
n o s z r，为微软云计算架构矗立重要里程碑
支持最新C +
+ 标准，增强I E
D ，切实提高程序员开发效率
实践当前最热门的A i /cu
gl S rm开发方法，令团队竞争力
e
更强，升级的软件测试功能及工具，为软件质量严格把关
搭配Wi7 i el h4
n 与Sl rg t，发挥多核并行运算威力，实现
v i
前端用户界面设计，创建美感与效能并重的新一代软件
北京站 2 1 ..2
0 041
上海站 2 1 ..4
0 041
立即注册
广州站 2 1 ..6
0 041

7.
人物专访 Interview
Ian Robinson和Jim Webber谈论基
于Web的整合
本采访是在伦敦举行的 QCon2009 上记录的，Ian Robinson 和 Jim Webber 探讨了如何将 Web
作为整合平台以及 REST 在理论上和实践中的好处。
Ian Robinson 是 ThoughtWorks 的首席咨询师，他的专业领域是设计与交付
面向服务的分布式系统。
Jim Webber 博士 ThoughtWorks 的全球架构主席，他与客户一起交付可靠的
面向服务的系统。Ian 和 Jim 目前正在合作创作一本关于 Web 友好的企业集成方面的书。
InfoQ：欢迎大家参加伦敦的 QCon2009，本场是对 Ian Robinson 和 Jim Webber 的采访。根
据惯例，我们首先请二位作一个简单的自我介绍，Jim，你先来好吗？
JW：我是 Jim Webber，在 ThoughtWorks 英国分部工作，目前，我正在和我的这位朋友 Ian
一起合写一本超级棒的关于使用 Web 进行整合方面的书。
IR：我叫 Ian Robinson，我也在 ThoughtWorks 工作，是一名开发人员。 我从事分布式互联
系统相关的工作。我也正和 Jim 一起合写一本书。希望我们说的是同一本书！
JW：嘿，你为什么不为大家多介绍一点那本非常棒的书呢？
InfoQ：谈到你们提起的这本书，其书名是“基于 Web 的整合”。它和 REST 是一码事吗？能
否简单介绍一下这个书名的含义吗？给我们来个电梯演说？
JW：当然，REST 是 REST 狂热者的国度里最高祭司的象征，然而，不幸的是，我们还没有被
这一教会所吸纳。我们使用“Web”的原因是它更具包容性，它包含了所有在广义的因特网
上已被使用的技术。其中的一些可能不如 REST 那么让人愉悦、欢喜、那么好的性能、伸缩
性或者合理性，但是这种特定的架构风格却非常有效 。我们更广泛地搜罗了网络中使用的
1

8.
有趣技术。
IR：我认为我们俩都不属于所谓的那种 REST 当权派(restauranteur 本意餐馆老板)，某些人看
到 Jim 站起来情绪激昂也许会作此感想，但是我们的方法更广泛。我们所做的工作是在月复
一月的工作中寻找那些实用的解决问题的方法。
InfoQ：我记得在几年前，当你提到 REST 的时，当时你很看起来的确有些怪异，人们不知道
你在说什么，而在今天这明显变了。至少人们这些天谈论了很多，这些场次很收欢迎，大会
进程排得也很密集。你认为目前人们在项目实施中采用 REST 的状态是怎样的呢？人们真用
它了吗？
IR：是的，我们使用它。我们用的很多；或者我们所使用的基于 Web 的方法中有一些方法
比其它方法更加 RESTful。REST 不一定要用在我们的所有工作中，相反，我们在一些客户项
目中引入了一些轻量级的使用 Web 的方法，并且久而久之，就形成了我们的——某种类型
的 RESTful 栈，在一开始把事物拆分成资源（resource）并对它们进行定位，然后进行连接，
进而通过超媒体来驱动应用程序。的确，我们在许多领域看到了 REST 的采用。
JW：同意。我认为这是命运的大逆转（不知你们是否喜欢这个说法） 从若干年前，
， 那时 REST
几乎在任何严格传统的企业都会被嘲讽，而且即使是现在，客户将 Web 方式当做缺省的情
况也并不乐观。事实上，我现在的客户，如果我们没有通过一些经验性实验而且找到了同样
非常适合解决它们的问题的更为简单的 Web 方法时，它们就会认为大规模高性能系统就应
该部署在传统的企业中间件上。有了那些实验数据，就对你有一些启发——诸如你会发现
原来 web 方法在一个场景中能够用的很好，然后另一个场景，并且它会当你谈论分布式系
统整合式它就能够成为你的缺省选择。
InfoQ：这些就是 RESTful 化或者 REST 采用的不同程度吗（如果你也这么称呼它们的话）？
当你向一个公司引进 REST 或基于 Web 的整合时也用这个方法吗？你的方法是不是从一点点
REST 的东西开始，然后越来越多逐步扩展？
JW：当然，我认为 Lenard Richardson 有一个非常很棒的尺度，一张 RESTfulness 级别的表格，
用分贝或 ROY，或其他我不知道的方式进行区分。Leonard 把这张图标分成四个级别，从 0
级到 3 级，0 级是最基础的转型，3 级就是超媒体了，这也是我心中的理想模型。我并不愿
意和人们分析这个模型，因为人们期望运用的技术是固定在“REST 内部的”那些锲而不舍
的人所做的工作。所以，在我设计和构建系统时，我会思考目标的适应性，而且我经常发现
满足目标的东西往往出现在 Leonard 的那张图标的低端。它们对 web 感兴趣，却不一定对以
超媒体为中心的服务感兴趣。
2

9.
IR：我认为 Leonard 的模型实际上在我们与客户讨论 REST 时非常有用，因为客户会这样开
始“解决任何问题，最简单的方式就是将它分解成一个个小问题。 那我们做什么呢？—
”
—我们仅仅标识出资源并为其定位。因此，咋一听，他并非在谈论 RESTful 的东西，而是在
谈论如何分解问题。继而他会说“如果我们要一次又一次地做相同的事情，那么我们就应该
遵循统一的方式”——这就是他的第二个级别，仅仅使用了统一模型。
再然后，他第三次说的是“如果我们要做一些有意思或特别的事，那么就要以特别的方式来
做”——这里才是与他谈论多媒体的时机。事实上，你可以跟客户，或其他人，只探讨那
些将问题分解成块，相同的事情若要不断重复做则遵循相同的方式来做，然后必要时特殊对
待。我认为这种交谈方式很好，进一步，还可以谈论一些特别的事物，如 REST 或使用 Web，
这样的交流方式很有效。
InfoQ：你是否认为有些在人们看来是对 HTTP 的滥用的事情也是通往这个方向（采用 REST
和 Web）的正确步伐呢？这些事情是你必须要做的，还是可以避免？你是否在某些情况下
只能通过 GET 进行函数调用来改变事物，或者你根本无法辩护你的做法？
JW：在我里面有个愤怒的家伙，他往往藏得不太深，此刻它想跳出来撕碎你的脑袋，并坚
信你的这些想法是多么地可恶。然而，在现实世界中，我们发现有些技术，如转换动词和
URI，它们被使用在某些特定的上下文中，而有时的上下文并不那么的固定，这就比较危险。
当然，在特定的上下文中，那些技术能帮助我快速把解决方案推向市场，我还是乐意使用的。
我承认这是一种粘合的聚类方法，而且我们常常回到过去并纠正错误。但是我认为，找到那
种我喜欢称之“牛犇架构”的架构并设计出世界上最杰出的 RESTful 超媒体也许不是我们立
刻就能做出来的。也许我们可以采用一些别扭的一点的步骤，比如转换（tunneling），从而
让我们今天转起来，然后随着系统的慢慢扩展，随着需求的不段精细，随着它面对更多的系
统，随着它受到更多的关注，我们就可以考虑（把现有的做法）移植到更符合 RESTFul 的模
式，而新的模式是明确地符合那一类系统的。
IR：我们的确要探索大规模的基础设施。现在的事情能够成功的原因是因为 Web 已经在那
儿了，而我们还需要开始接受 Web 的一些限制，一些随着 Web 的发展而带来的更多的限制。
那些限制现在就存在，比如浏览器几乎只接受两种动词，GET 和 POST，还有，我们的解决
方案常常不得不遵循哪些限制，而不论我们是否喜欢这种转换的方式。
JW：这适用于一些媒介——REST 架构被膜拜，好像 Web 是一个完美的乌托邦，在这里所有
事物都理解 HTTP 的统一接口的全部延展，而事实上并非如此。 Web 上仅有少数几个演员，
在
他们还不能理解某些动词，尽管 HTTP 认为他们真应该理解。这就是我们要考虑的限制，比
3

10.
如 Mark Nottingham 很喜欢跟我们讲的缓存成熟度曲线。
那些限制对我们来说的确是个挑战，因为 Web 的行为并不符合 REST 中所描述的它应该表现
的行为，所以我们不得不采取某些实用的剪裁才能使系统运作起来。REST 是有价值，而让
系统转起来更有价值。
InfoQ：事实上，我想 Roy Fielding 一定会非常赞同你的观点——HTTP 和现在的 Web 并不是
REST 的最佳实现——他一直都是这么说的。
JW：很好，不然他的粉丝们会揍扁我的。
IR：不过，它还是很不错的。我们有一套自己方法。
InfoQ：直到现在我才注意到我们一直在讲 REST，却没想有对它作出解释。所以，也许有些
人还不知道我们到底在谈论什么，你能否花一分钟的时间解释一下 REST？
IR：它是“在 Web 上选择自己的路径去探索有趣的业务流程”。我们希望实现某些目标，让
一些不同的事物协作起来，我们通过 HTML 或 XML 为客户和消费者提供服务，对于确定的
一组目标“我想完成这个或那个”，它可以从选择一条通往服务器的路径开始，然后在服务
器返回的表现中找到新的链接，就这样一步一步通往目标。
JW：这种说法的确很妙，我都想照搬它了，然而我还是要修改一下以让它看起来像是我的
想法。可以这么说，服务器丢下一些面包屑给客户端并让他们跟上。它指引客户端沿着服务
端实现的业务流程前进。我们倾向于使用一致的接口和 HTTP 的方式陷入这个沼泽，而所有
的东西及其核心就是，服务端绅士般地牵着你的手带领你通过业务流程。
InfoQ：你提到过有一些缺失，它们成了该基础设施的问题，比如浏览器在 GET 和 POST 方
面的限制，然后是缓存、媒介和其他某些事物会忽视或阻塞某些方法。你认为目前在 Web
范围内还有其他缺失的东西吗？为有效使用它，是否有些东西是我们必须要有的呢？如果
有，那会是什么呢？
JW：尽管 Web 本身是非常成熟的技术，目前最主要的问题依然是经验的缺失。我认为目前
我们仅仅在学习如何驾驭它的某些特征然后进行系统整合。Web 已经成为连接人与人的一
种闪耀的机制，特别是在近几年，人们被带到网络中，通过 pokes 和 tweet 或其他类似的东
西进行交互。
作为分布式系统工程师，我们仍缺乏某些在计算机之间协同完成工作的经验。例如，我们还
没有找到如何在系统之间扩展超媒体的有效方法。就我而言，我认为这是我心中最关键的缺
失。我很高兴周围有很多基础设施的怪癖和来自社区的不同声音，但是我想我们的确需要做
4

11.
一些实验并学会如何让它转起来。
IR：即便在客户端库中，也可以用一种相对通用和标准的方式访问超媒体。我正在想的问题
是，我得到的返回是一个表象，可是我想要的是一个链接查询，它可以让我找到所有的超媒
体，然后此刻我想访问哪个超媒体，我就可以为哪些关联该超媒体的 URL 进行解引用
（dereference）。
InfoQ：哪些场合适合使用 REST 和 Web，而哪些地方又应该避免使用它们呢？
IR：只要你希望你的应用是真正可达的，那么就应该优先选择 REST 和 Web 的方式。对于任
何要访问你的应用或与你的应用协同工作的人来说，它们的门槛相对比较低。然而，如果我
们仅需在企业边界内运转的话，姑且不管这是不是一个好主意，那么我们就可以自由发挥了。
如果我们永远不需要向任何人解释我们在做什么，我们甚至可以从头到尾发明一些新东西，
但是当我们希望跨越任何组织边界的时候，我们就应该寻找一些足够精致的方式工作和协
作，而不是只要能完成工作的最低要求即可。
JW：说得更远一点，当你考虑使用某种技术的时候，应该看看他们所表现出来的代价和优
势。对于 Web，我最喜欢提的问题是：“你愿意牺牲延迟并换来扩展性吗？”。Web 的延迟
不低，但是它提供了非常好的扩展性，特别是网络提供的协同工作。如果你能承受几秒、几
分、或者可能是几小时，几周的延迟，那么 Web 的扩展性就非常棒了。
但是，如果你不能承受高延迟，那么再考虑 Web 的方案可能就是一个错误的选择。这时上
帝会敲敲我的脑袋说，或许一些毫秒级或更少延迟的私有协议是你需要的方案。然而，我常
常发现某些技术总是强调他们需要毫秒级的传输延迟，而往往没有真正根本上理解它们所面
对的业务问题，而业务问题的要求可能是更为合理的几秒，在这种情况下 Web 就可能成为
这合理的解决问题的低成本的方式。
像我们这样的电脑迷们承受着虚荣的极大折磨，因为我们总要求最酷、最快、最低延时、最
优的系统节点，而 Web 却不关心这些。Web 是“单调乏对味的前进能咋样就咋样”。如果不
论何时都需要用延迟换取扩展性，或者说是扩展与高延迟并存，那就应该使用 Web。
IR：我觉得这也是分布式系统开发的一个常见问题。它要求我们对延迟和不一致性多一点耐
心。几个世纪以来，人们一直在致力于协调这些问题。假设我从一个城市策马奔向另一个城
市，这个中间过程中就可能会发生不测。人们已经发明了能够处理这些问题的业务协议，而
且，我认为这些工作推动了我们去关注它们并帮助这些协议语义再次浮出水面，而并非总是
想着依赖于那些低延迟的技术并用它们来做所有的工作。
5

12.
JW：这相当有趣，因为作为分布式平台的 Web，它所强调的一定是分布式。从这么多年的
计算机科学的发展来看，我们得到的教训是抽象是个极好的事物，而且，我们应该把所有艰
难的计算科学的东西交由科学家们去处理，而在活跃快活的业务网站中忘却这些痛苦。实际
上，你再也不会像多年前 Waldo 告诉我们的那样可怜地被计算社区所轻视，相反，如果你
决定使用基于 Web 的分布式系统，Web 不会向你隐瞒分布式，而是给你一些有用的信息去
协调分布式交互，再举个例子来说吧，用信马（messenger‐horse）打个比方，当你的马在高
速公路上被某个警察抓住时，你可以采取合适的行动去挽回。作为过去的事务追求者，我看
到的 Web 是一个庞大的协作平台——两阶段同意的事务会让人发疯。
IR：刚从你不能上帝的眼睛去观察自己的成功的失落中缓过来了吧。
JW：离 Tim 大师远一点……他可以随时看到整个 Web。我不是开玩笑哦，你发一篇博客，他
是知道的，他正看这你呢，他正通过一个网络摄像机监视着你呢。
InfoQ：正好你提到事务，我听到关于 REST 的最多的批评之一就是它缺少很多企业级的特征。
使用 Web 服务时，你能使用一些事务相关的协议，提供原子性事务的 WS‐Coordination 以及
WS‐Business Activity 等等。你认为这是一种缺陷吗？我们使用基于 HTTP 的 REST 时需要一事
务相关的协议吗？
JW：不，下一个问题吧，我不赞同这种说法。我认为我们正在学习 Web 提供的处理事务的
方式，经典的两阶段事务实际上并不适用。任何听过 Gregor Hohpe 谈论最终一致性（eventual
consistency）、读过 Gregor Hohpe 写的关于 Starbucks 为何不使用两阶段提交的文字、任何真
正对这个问题有过即使是转瞬即逝的思考的人都会理解两阶段事务无法用在 Web 上。你是
在用一致性换取扩展性，而 Web 着眼与扩展性，潜在地支持最终一致性的技术。
我不是公然宣传我的书，其实在这本书的第 12 章有相关的讨论。实际上，现在我们已经煎
熬地完成到第 11 章了，我们努力雕刻那些章节以至于可以跟上 Stefan 多产的步伐，他正在
写一本等同的德语版的书。我们实际上很煎熬，如果你们愿意听，我们为了安全、事务、消
息可靠性等方面使用了 WS‐*的技术。 我们在简单古老的 Web 的 HTTP 世界里展示了等价的
模式和策略。我们并不宣称我们的方法是 RESTFul 的，拿事务打比方，我们只说你并不真正
需要它，因为 Web 会给无时无刻不在为你提供这种协作。
作为一种同步的逐步推进式基于文本的协议，Web 不应该立足于全局范围的[事务]，这似乎
有悖常理，然而这是事实，因为在每此关于某个 Web 上资源的交互，我会得到一些元数据，
它告诉我这次交互是否成功。因此，我可能选择继续冒险的路径——如果我愿意的话——
这样我会继续访问后续的资源并往前走，或者因为该元数据传递给我的信息是我正在进行的
6

13.
事情可能失败，我也可能通过一组已链接的资源走后其他流程走向另一条路径，这就是另一
种前进方式。对我来说，这才是处理意外输出的更合理的解决方式，尽量把所有的事情包装
在 Web 的更大的事务中。
“你面对的是一个拿着斧头的侏儒，你会怎么用他？” 我的意思是，即使有 WS‐*协议，
IR：
我也不认为我们在任何情况下都要把它用在有许多服务参与的事务语义之间的协作。虽然我
们跨越 Web 以 RESTFul 的方式把服务的内部实现暴露出来，但是也许你真正要用的却是在粗
粒度的边界背后的内部实现，它们可能依赖于一些更底层的协议。我认为这没有错。如果我
们已经准备好承受锁住许多资源的代价，我们正在寻求一种粗粒度的边界，而事实上在这个
层次上我们不一 定需要它。
JW：那也是有代价的，对吧？这一定需要更灵活的设计才能保证正确，因为在最底层，如
果你正在使用的是一种遗留的关系型数据库，你就要必须考虑这 些事情——是的，我这么
说过而且也一直这么做的——但是你一定要明确地设计出来，而且要小心对待那些容易被
无意中忽略的细节的抽象边界。如果你的失误走漏到 Web 中，你就搞砸了。
IR：一旦你把后门钥匙给了某人，他将来就会从后门进入你的房间。
InfoQ：现在我们已经讨论了事务，那么你觉得在 REST 中加入类似 BPM/BPEL 的东西怎样呢？
你认为我们需要这样的东西吗？
JW：Web 的链接不是已经提供了这样的功能了吗？:) Web 有这样的免费的编排功能。
InfoQ：是吗？我不好确定。这是个真诚的问题，我指的是引擎……姑且不管它是使用哪种语
言编写的，但那些引擎可以处理这样的事情，它们可以将不同的请求搭配到不同系统中，而
响应是异步返回的，它们又将这些响应搭配回原请求并做其他工作。这听起来是个很有价值
的功能，难道 RESTFul 的世界不需要类似的能力吗？
JW：的确很有价值。从得知特定的输入得到什么输出这个角度来看，使用某些规则来实现
也是很好的。而只有把它捆在让人恼火的 BPM 语言一起使用时，才会让我不爽，原因是在
使用时有很多负担。我们看到过很多可以通过点选方式建模的 BPM 产品，而使用他们时我
们往往发狂，这是因为用它们很危险。 使用 Web 时最困难的事情就是让客户端协作起来。
如果我们可以解决该问题，那么 Web 将是更容易驾驭的方案，但是我完全同意我们需要客
户端协作，可我并不认为一定要我们今天所看到相同的产品线和解决方案。而类似于 Prolog
或规则引擎，也许是实际上处理和编排 Web 上的处理的更好的方式。
IR：这是一个客户端或服务端的内部实现的问题，不管他们在交互中扮演的是什么角色。按
你的说法，为了实现一个目标可能需要一步接着一步最后达到目标，这也是无可厚非的。而
7

14.
如果服务端返回给你的是一个表象，它为你提供了一组选择，你可以应用某些智能的方法去
选择你的路径，这也反映了一种带外（out of band ）机制，这样我们也能像你所预期的那
样交互。它提供某种标准的合理的食物的解释方式，如“rel”属性等。
JW：这种带外只能可以是一种微格式（Microformat），而且可能应该是，因为他们轻便而生
动。
IR：是的，但是很多流程都是很简单的，顺序的，或者由事件驱动的。用最简单的方式去实
现它们相对比较简单，而且没有必要非要依赖于规则引擎或某些工作流引擎等工具。
InfoQ：让我们谈一些切实的东西吧，我们已经谈了很多理论方面的好处，所以现在我们谈
谈实际的。对于那些接受了 REST 的人们，他们想搞点 RESTful 的东西，你推荐哪些工具？
从我们已有的不同的技术领域，你在构建 HTTP 上的 RESTful 系统时最喜欢用什么工具？
JW：我承认我最喜欢的都是简单的工具。目前我正在做的是一些非常高性能的系统，用的
是 Java，它挺好。当然，即便是 Java，我们也有很多选择， 我们可以选择 Restlet，也可以
选择 JAX‐RS 服务端实现，二者都是非常完善的框架，提供了很多的工具。在这种情况下，
我们使用 servlet，因为他们已经足够我们以一种轻便的方式完成工作。相反，比方说如果你
在使用.NET 平台，那你就能用 WCF 中的 WebInvoke 和 WebGet 等工具，或者你也可以仅仅
使用 HTTP 句柄（handler）。
IR：或者也可以是 HTTP 监听器，实际上在自托管的 HTTP 中 WCF 使用的就是它。你也可以
使用它，而且，在其之上写程序相当简单。
JW：更狡猾的回答是你自己做主。如果你喜欢使用高度抽象的框架，如 WCF 或这 JAX‐RS，
如果与驾驭像 servlet 这样极度以 HTTP 请求/响应为中心的事物相比，你觉得把这些框架放
在你的应用域中你感到更轻松，那你就这么用。用你认为最舒服的工具就好！
IR：我一直不断探索的一件事情是，如何在应用协议的周边进行交互，我喜欢用测试的方式
来做。测试是很有用的一种文档方式。我想通过应用协议向你描述你可以通过什么方法让我
的服务作出反应。比如，如果你想这个端点提交这个表象，调用这个方法，你就可能获得这
中表象的返回，这种媒体类型，这些状态码 ，这个 HTTP 头。所有这些只是应用协议的一
部分，我们是在与自己建立某些微不足道的合约。比如，你可以在 AtomPub 规范中看到很
多这类的东西。
我喜欢做的事情是把所有的断言都放在一个测试中。我常常在探索，能否不需要每次都开启
一个服务实例，或者不需要通过线上的交互，就能完成测试。因此我常常在寻找一种非常轻
量级的抽象，这样我就可以在不需要启动服务的实例就能为所有的 HTTP 构件创建测试预期。
8

15.
我记得你曾用 Spring 中的模拟上下文（mock context）干过这事。
JW：通过 sevlet 和一些 Spring 的模拟的确是一个很好的方式，你不需要等待 20 个小时等待
Tomcat 完全把服务启动，的确很轻便，很实用。
IR：而我偶尔做的是创建一层很轻薄的封皮（ wrappers ）把请求和响应封装起来。我能使
用它们独立地代理任何我使用的运行时，然后，我基本就可以写一些测试程序去测试它们，
或者模拟那些请求和响应的实例。
InfoQ：你们提到了“契约”这个词。你们怎么看待 REST 相关的契约？因为在 Web 服务的
世界里，契约的确是所有事物的核心。据我所知，Jim 是那些极棒的 WSDL 描述文件的狂热
粉丝之一，它真正非常正式，非常完全地描述了服务所暴露的方法。你们根据什么去和一个
没有正式描述的服务进行交互呢？没有 WSDL 文件，你们是第怎么工作的呢？
JW：你可以有一个非正式的描述，然后就会有一大批 Ian 的绝妙的客户驱动的契约。
IR：我常常认为媒体类型（media type）表达了一些契约信息，从它身上你可以得知将返回
给你的是那种表象。更加有趣的媒体类型实际上也包含了很多那些与协议相关的规则。还有，
我觉得像 AtomPub 这样的，它不仅告诉你，你将得到什么返回，而且他还会告诉你，你能
访问哪些方法以及调用这些方法将得到状态码。这里是有协议的，他们只是被传来传去，而
且我认为我们应该探索媒体类型，它们能清楚地告诉我们：我们能做什么，我们能怎么查询
和浏览这些超媒体表象，以及它是如何将我们同超媒体联系起来推进应用的。
InfoQ：可以说是超媒体格式承担了契约的角色吗？
JW：没错，笼统地说，是这样的。事实上，我们的一个朋友，也是过去的同事，George Malamidis
曾对我说过：
“Web 已有一种契约语言，它叫 HTML。 直 到今天当我说这句话的时候我还
”
是很害怕。George 是这些圈子里面非常深邃的思想者，但是我还是相信他是对的，我只是
害怕一下子站到他的高度。
InfoQ：让我们假设你已经说服了某人，REST 是个好东西，但是现在轮到他们去说服他们的
同事去实际使用它，你有和建议？你在你们公司是如何宣扬 REST 的呢？最好的方法是什
么？
JW：我不会宣传它。我认为它必须作为某个环境中解决访问的方法出现。大概在去年左右，
我曾参与过一个系统，该系统最初的设计是基于 JMS 的。这很好，我也喜欢用 JMS ，它是
一个很好的想法，但是最初的设计是在没有整体考虑该系统将要部署的环境下完成的。JMS
虽然很好，但也有它的复杂性。最后通过用几天的时间完成的一个桩，我们发现实 际上该
9

16.
系统所要求的负载是 HTTP 就足够胜任的。
从我们不断改进软件交付的角度说，HTTP 具有很多的好处：它要快得多；较之 JMS， HTTP
写
程序要简单得多；你可以容易地使用类似于 Poster 或者 Curl 这样的工具进行测试。当时那
的个系统的交付非常好，房间后面的一个人开心地笑了，他也是我们中的一员，HTTP 的确
很棒。而且，我想如果当初我们沿着 JMS 的方向走下去的话，那我们会辛苦很多。事实是，
QA 人员可以用带有 Poster 插件的 Firefox 对该系统进行测试，或者是一些高级的容易理解
的探索性测试，他们以我们没有相像到的非常好的方式破坏我们的系统，因为系统表面对他
们是开放的。这让我很开心！
IR：最后赢得到更多的支持者，对吧？
JW：是的，所以这又是一个有影响的事情。
IR：很多人对于系统如何运行，或者系统如何向外界暴露服务都有自己显见的理解，并且人
们习惯于使用自己所熟悉的方式去查看，比如浏览器，Poster 或类似的东西。这非常奇妙：
事实上，我们也是从我们所喜欢的东西开始，我们更喜欢谈论 Web，Web 相关的事物以及
REST，进而更多地谈论 REST，我认为在一个组织里宣传 REST 有时并不合适。我常常在人们
说“我要 SOA”时就非常崩溃。SOA 是另一个应该被删除的单词之一。我们的谈话应该从我
们要做什么开始，并且用人们所熟悉的方式去讨论它，而现在不熟悉 Web 的人几乎没有了 。
我们可以仅仅从一些 Web 可以做的简单的事情开始，并说“想想，你的应用是不是也能这
样工作呢？”
JW：SOA 的危险之一就是它经常和产品绑在了一起，以至于常常变成“我可以卖给你 SOA”
——“不，你不能”，而且我看到 REST 的名字也使用到某些软件产品之中了。这有时候给
人们的谈话带来疑惑，因为人们想他们可以将 REST 插入到他们的应用之中，他们可以购买
REST 平台，然后就变得 RESTful 了，然后，他们做的所有的事情就认为“包含 REST”了。他
们不会批判地思考它（REST）为什么对业务有帮助。这仅仅是高级 IT 决策者或者提供商们
的结论，而不一定是出于对业务最好的角度，而且几乎不会出于开发团队的角度考虑，而开
发团队才是实现服务的真正主体。
IR：通过插入某种适配器就可以将一个 WS‐*的应用程序从外表上包装成一个 RESTFul 的应用，
还希望它能成为一个丰富有用的 RESTFul 的应用，这几乎是不可能的。
JW：这样的应用是一个危险的 REST 应用，因为其底层实现的设计就没有这样一层表面或以
这种方式加载，因为其底层实现是以消息为中心或 RPC 的方式设计的。
10

17.
IR：这区别大了去了，而且从其本身思考，假设在一个资源之上套上一个更大的资源，而这
个更大的资源是在一个完全不同的泛型中设计的。你就会失去发现业务及流程的有趣点的机
会。谈到资源，它常常展现了事物内在的固有价值。搜索结果的进进出出对于 Google 这样
的公司非常有价值，这就是他们用来挣钱的方式之一，把搜索结果展现成资源是思考和探讨
的一种很好的手段。
InfoQ：观众提问：REES 位于 HTTP 之上，HTTP 是一种非常古老的规范了，我们使用它也已
经有很多年了，有没有可能 REST 会后退到 HTTP 规范所规定的范围之内呢，不论在过去的
20 年内我们是如何使用 HTTP 的，现在我们是以更有趣的方式在使用 HTTP 了，而且，我们
仍然有一些没有完全实现 HTTP 规范的客户端或浏览器。比如，大家都知道， FLEX 和 REST
将
用在一起非常困难，那是相当恐怖！你是如何看待的呢？你是否觉得我们应该需要一个新的
规范，或这更新，这样我们才可以解决哪些我们以前使用 HTTP 时没有碰到过的哪些问题，
也许现在我们需要更多的 HTTP 能力？或者，你是否认为在将来的 1‐2 年内所有的浏览器会
实现当前的 1.1 规范供我们在未来的 20 年愉快地使用呢？
JW：浏览器不支持所有的 HTTP 动词的原因主要是 HTML 不支持，所以我们留下了 GET 和
POST，这是非常有限的。我并担心，原因是对我而言浏览器已死。它是最常使用但却是最
没意思的 Web 代理。我更感兴趣的是计算机间的交互，而不是人和浏览器之间的交互，而
且现在，在人们对它（浏览器）施压时，它已经嘎吱嘎吱苟延残喘了，但是对于人们互相
facebook 或做任何小孩子们做的事情来说，它还是能足够胜任的，所以我并不担心它。真正
让我担心的是 W3C 中的一些工作组正在前进的一些未来方向，它们将更有效地重织网络。
现在的 Web 基础设施，在世界的各个角落都可以访问，它也走到了自己的神奇的临界点
（tipping point）。
我担心如何 W3C 的伙计们会带来一个新东西，比如 HTML5.0 并将它推广开来，那就会出现
一个怪异的悖论——网络中一半是原有的 Web，另一半是新的，他们各自拥有 Web 套接字，
而 且都很困惑，网络中不在只有扩展标记语言，这是我想到的最大的麻烦。目前，我正在
等待浏览器提供商的创新，我没有什么意见，对此我没有什么兴趣，但也觉得尚可。我希望
W3c 能以更加发展的方式来滋润网络，而并不希望看到某人成为 Tim 先生（万维网之父）
第二，不幸的是，我担心 W3C 中可能有人会想这么干。
InfoQ：观众提问：最近我们看到，即使在现在的大会上，在编程上，很久以前我们有了 Lisp，
然后我们有了更多的抽象以及对象或更大的组件，现在我们看到人们又回到了函数式 编程
上了。Web 中也发生着类似的事情，我们曾有简单的 HTTP 规范，然后我们又有了很多抽象，
如 SOAP 和 BPEL，然后我们又回归简单，到了 REST。这是否意味这一种走向简单的趋势呢？
11

18.
又或者这是软件一直以来的方式，风水轮流转？
JW：回答这个问题我还不够资格，呵呵。Ian 经历过多次这样的轮回，所以他应该有合适的
答案。
IR：从怀旧驱动的发展的观点看，每个文字开始时就很好，回到古老的方式并没有什么不好。
你谈到了简单性和趋向简单性的趋势，我觉得对于 REST 推行者来说，在推行的时候， 简单
性并不是他们要强调的优点，而是限制，让限制再次浮出水面并意识到他们。围绕这 Web
有很多应用，而这些应用往往滥用了 Web 的基础设施及其使用方式。好的 REST 推行者会 强
调和展现哪些限制并告诉你，如果你在这些限制之内工作，你就可能实现更可达，高性能。
这是我钟爱的回答。
JW：是的。我们的确为分布式系统做了一层又一层的抽象，但是你知道吗？这些抽象并没
有带来什么好处。世界上一些最大最复杂的分布式系统并没有那么大和那么复杂，然后这 些
蹩脚的协议出现了，它们强调同步，强调文本驱动并且全球范围内推广。这让我们工程师们
很惊诧而且觉得没意义。这是 Web 的悖论：这是世界上最垃圾的东西，但是很广泛。对 于
我来说这已经是尽头了，因为我们是完全支持基于 XML 的协议并且干的都是这类时髦的事
情。
我把我的名字放在一些 OASIS 的项目以及其他事情上——希望上帝会阻止坏事的发生——
公平地说，我们认为我们有最佳的意图，我们认为这些东西会有用，并且在某个特定领 域
内有用，但是 Web 和 HTTP 已经向我们证明了，如果你要扩展和广泛可达，你必须要做一些
简单的事情。这些简单的协议是让每个人能够交互并且让这种交互能成为 21 世纪早期计算
领域的核心的基准线。所以，没错，回到根本！
原文链接：
http://www.infoq.com/cn/interviews/robinson‐webber‐rest‐cn
相关内容：
 加密因特网
 HTTPS连接最初的若干毫秒
 Facebook架构师QCon北京 2010 演讲：扩展Memcached实战
 Erich Gamma确定QCon北京演讲：设计模式 15 年
 提高架构质量的 10 个观点
12

19. “ Adobe Flash
Adobe Flash
2010 4 21 22
Flash Builder 4
Flash
http://www.adobechinadeveloper.com/FlashPlatformSummit/index.htm

20.
热点新闻 News
Eclipse Virgo项目获得批准
作者 Alex Blewitt 译者 张龙
近日Glyn Normington宣布Eclipse Virgo项目通过了项目创建的评审，现在只等代码导入了；
同时VMWare也开始了与Eclipse基金会的合作。
Eclipse Virgo将成为SpringSource dm Server（最近发布了 2.0 版）的下一版本。基本想法是在
适当的代码重构（包括对org.eclipse.virgo包的重命名）后发布 2.1 版，同时可能会有一些变
化。
dm Server和Eclipse Virgo之间主要的区别在于前者基于GPL 3.0，而后者基于EPL 1.0，这么做
会扩大项目的应用范围，Adrian说到：
“
虽然JavaScript最初出现在 1995 年，但直到过去几年，由于Prototype和JQuery这样目
前的dm Server基于OSGi和Spring Dynamic Modules（现在已经标准化为OSGi Blueprint
Service）编程模型为模块化的企业级应用开发提供了极佳的服务器平台。 企业级OSGi
与dm Server已经取得了长足的进步，但实事求是地说，在企业应用开发中采用OSGi
还是需要付出很高的代价的。就像很多新技术一样，一开始的投资需要随着时间的推
移才能得到回报。Hal Hildebrand在其最近的一篇博文中谈到了当前的OSGi价值。
目前的企业 OSGi 和 dm Server 引起了很多人的兴趣，围绕其的创新也一刻没有停止
过。这种兴趣尤其以早期的使用者以及那些需求符合 OSGi Service Platform 动态模块
特性的项目为甚。但对于主流的开发团队来说（只希望尽快构建好企业应用，麻烦越
少越好），目前采用企业 OSGi 的代价可能会超出其短期的收益。在企业 OSGi 成为主
流的企业应用开发方式事实上的标准前需要重点考虑这个问题。
请注意这里我说的是企业应用开发，如果你编写的是基础设施软件并且需要创建
“stackless stack（Kirk Knoerschild、James Governor）”，那么OSGi已经成为事实上的方
法了，得到了dm Server和与之相关的dm kernel子项目的完全支持。
13

21.
Adrian的评论被一些人断章取义了，他们认为模块化对于复杂的系统非常奏效，但对于简单
的Hello World式的应用却没什么必要，然而OSGi可以帮助我们解决复杂性问题，Kirk
Knoerschild在OSGi DevCon London 2010 上的演讲中说到：
“
软件的复杂度呈现出指数级的增长。你知道么：
在上世纪 90 年代，
一共有 1200 亿行代码；在本世纪前十年，一共有 2500 亿行代码；
代码行数每过 7 年就增长一倍；50％的开发时间花在了理解代码上面；90％的软件
费用花在了维护和演化上面。
根据以上这些数据我们来看看未来 7 年将会发生哪些事情。在 2010～2017 年间，我
们所编写的代码量将超过现有的所有代码总量！
除了上面这些因素以外，还有其他一些主要考虑。我们需要一些东西帮助自己理解复
杂系统、管理复杂性、简化维护的代价、处理软件系统的自然演化、当系统变大时能
处理自然架构变迁。长久以来，我们都缺乏一种中心架构，但这种情况不会持续太久，
因为企业将要使用 OSGi 了！
虽然 V irgo 已经不太可能成为 Eclipse Helios train（将于今夏发布）的一部分了（因为时间上
来不及），但新版的 dm Server 即将发布，如果赶不上 3 月份的 EclipseCon 2010，那应该会在
Helios 发布前后。
你认为项目的迁移（以及协议的变化）会扩大该产品的应用范围么？
原文链接：http://www.infoq.com/cn/news/2010/02/eclipse‐virgo‐approved
相关内容：
 Bundle.update：NetBeans与OSGi
 微软将向Eclipse开发者提供大量工具
 IBM developerWorks十周年：精彩内容回顾
 SpringSource宣布将dm Server移交给Eclipse.org、Virgo项目将基于EPL协议
 Eclipse插件Top30，而你会喜欢哪个IDE？
14

22.
热点新闻 News
Apache Beehive正式退役，迁移到Apache Attic上
作者 Gilad Manor 译者 张龙
上个月，Apache Beehive项目的众多提交者投票表决停止该项目，原因是项目太不活跃了。
Apache Beehive的上一个版本是1.0.2，还是在 2006 年十月份发布的。
Beehive项目的代码基最初是由BEA编写的，作为WebLogic Workshop项目的一部分，以此吸
引人们使用WebLogic 7.0 和 8.1。最后，这部分代码基被BEA以开源的方式捐献出来，形成了
现在的Beehive。Beehive通过 3 个核心组件来简化Java EE的开发：
NetUI——这是一个自动化层，覆盖了Apache Struts 1.x以简化对应用流的管理。
Controls framework——该框架会生成大量的样板代码以供使用旧版本 Java EE EJB 与 Web
Services API 的项目所用。
Web Service Metadata——该组件可以通过注解自动生成Web Services API，它实现了JSR‐181，
后来被纳入到Java EE 5 中。
Henri Yandell在本月 10 日发布的声明中给出了其他一些选择以替代上面提到的 3 个组件：
 使用Struts2或Spring Web Flow替代NetUI——Spring Web Flow是Spring基础设施的一部分，
重点解决导航规则和会话（conversation）状态管理等问题，它有力地保证了系统的模块
化和重用性。Struts 2 基于WebWork，能构建可重用的UI模板，如表单控件、UI主题、国
际化、映射到JavaBean上的动态表单参数以及客户端/服务器端验证等等。
 使用Spring Framework替代Controls framework——借助于Spring可以从应用的Web层访问
本地或远程的EJB。
 使用Axis2 JSR‐181实现替代Web Services Metadata——Apache Axis是个Web Services、
SOAP以及WSDL引擎，可以通过注解生成Web Services，同时还支持Web Services的客户
端与服务器端。
15

23.
希望继续使用Beehive项目的用户可以根据上面这些建议进行调整，同时Beehive的项目站点
和代码基将迁移到Apache attic上。
原文链接：http://www.infoq.com/cn/news/2010/02/apache-beehive-attic
相关内容：
 Web Profile会将Web开发者吸引到“Enterprise Java”上么？
 Jave EE 6 特性：依赖注入、Bean验证和EJB增强
 Spring 3.0 发布：基于Java5，添加了新的表达式语言和对REST的支持
 简化持久性实体的传递
 修剪Java EE
16

24.
热点新闻 News
Chrome 4 现已支持HTML 5 Web
SQL Database API
作者 Abel Avram 译者 张龙
近日Google宣布将支持HTML 5 Web SQL Database API，其他浏览器厂商也表示将紧随其后提
供该支持，有的甚至已经开始支持该API了；但同时，HTML 5 规范的制订却遇到了阻碍，因
为所有的参与者都已选择了SQLite作为底层数据库，要想实现标准化还得考虑多个不同的实
现。
作为HTML 5 的一部分，W3C组织正在制订Web SQL Database API草案，该规范主要用于解决
如何通过SQL存储及访问数据的问题。文档中所使用的SQL语言是SQLite 3.6.19。网页可以使
用这个API与嵌入式的客户端数据库进行交互，这对于那些想要在本地存储数据或是离线浏
览的应用来说价值非常大。
Google已经在其最新的浏览器Chrome 4 中通过SQLite提供对Web SQL Database的支持了，这
个举动可以看作是向标准化迈进的一大步，因为Google Gears中已经拥有了一个Database
API，也是基于SQLite。Gears API为所有主流浏览器提供了结构化的数据存储功能，包括IE、
Firefox以及Safari，但现在Google已经停止Gears的开发工作了。
Firefox 3 拥有一个嵌入式SQLite数据库，目前主要用于存储书签和历史记录，但可能不久后
就将支持Web SQL Database API。当前的开发工作正在WebKit（Safari所用的渲染引擎）上进
行以向Web开发者提供Web Database API。现在谁也不知道微软对于IE和HTML 5 Database API
的计划到底是什么。
虽然一些公司已经实现了 Web Database API，另一些也正在实现当中，但根据草案的制订情
况来看，规范还是遇到了一些障碍，因为所有的参与者都已经选择使用 SQLite 了：
规范进入到了一个僵局当中：所有的参与者都不约而同地使用了相同的 SQL 后端（SQLite），
17

25.
但我们需要多个独立的实现来继续标准化之路。除非有其他实现者想要实现该规范，否则对
SQL 语言的描述仍将停留在 SQLite 上，这对于标准来说是不可接受的。你想要实现独立的
SQL 后端么？请联系规范的编辑，他可以为该 SQL 语言编写一个规范，只有这么做才能推进
规范的不断发展。
在这种“僵局”下，谁也不清楚到底是规范将会推进实现抑或是还有其他解决之道。目前，
Google 正加快浏览器开发的节奏，没有哪个浏览器厂商愿意等到标准全部制订完成后才开
始实现自己的 Web SQL Database API 支持。
原文链接：http://www.infoq.com/cn/news/2010/02/Web‐SQL‐Database
相关内容：
 8.8.8.8——用于快速浏览的DNS服务器
 Google正制订一项新协议，旨在替换掉HTTP
 HTML 5 通过sandbox属性提升iFrame的安全性
 YouTube发布HTML 5 视频，但并不支持FireFox 3.6
 ASP.NET的未来：简化开发，HTML 5 及性能提升
18

26.
热点新闻 News
Flex开发者需要知道的 10 件事
作者 张龙
不久前，Michael Portuesi发表了一篇博文，谈到了Flex开发者需要知道的 10 件事。文章介绍
了每个进入Flex领域的开发者都需要掌握的基本知识与技能。
Michael Portuesi 给出的 10 个条目中，有些是开发者需要了解的简单细节信息；有些则揭示
了 Flash/ActionScript/Flex 与其他开发环境之间的差别。
如果你了解 HTML/CSS 并熟悉 JavaScript，但却对 ActionScript 或 Flex 一无所知的话，那么应
该花些时间学习一下面向对象编程，因为 ActionScript 是一门完全的面向对象编程语言，而
Flex 则是一个面向对象的框架。
1. 再简单的东西也是异步的
Flex 是一个异步框架，因此我们绝对不能指望代码调用后就能立刻执行。事实上，我们是无
法预知方法的调用序列的。
2. 搞清楚 Flex 组件的样式与属性
Flex UI 组件（按钮、菜单等等）既有属性（通过 ActionScript 语言指定）也有样式（通过 Flex
框架指定）。搞清楚他们之间的区别是非常重要的，因为组件的某些可视化效果可以通过属
性指定，但另一些却只能通过样式设定。通过属性指定：
button.width = 100;
button.height = 50;
通过样式指定：
<mx:Style>
Button {
color: #cc0000;
textRollOverColor: #ccff00;
19

27.
fontFamily: Trebuchet MS;
}
</mx:Style>
<mx:Button id="setupB" text="Click Me" click="onSetup()" />
3. Flex 中的样式与 HTML 中的不尽相同
可以使用标准的 CSS 样式表来为 Flex 组件添加样式，也可以在 Flex 应用中包含 CSS 样式表。
虽然标准 CSS 使用连字符（例如 text‐font）格式来定义样式名称，但是 Flex 使用驼峰式的命
名格式（例如 textFont）。这是因为连字符不能出现在 XML 的属性中，所以不能用这样的名
字作为 MXML 标签的属性。
当然了，如果把样式定义在外部的 CSS 文件中或者 Style 标签中，也可以使用连字符格式的
样式名。此外，Flex 还定义了很多 HTML 中不存在的 CSS 样式。
4. 尽管看起来不同，但 MXML 和 ActionScript 本质上是一回事
在 Flex 中声明的所有 MXML 标签都会被 Flex 编译器转换为 ActionScript 代码；当然了，也可
以在 MXML 文件中嵌入内联的 ActionScript 代码。既可以使用 MXML 也可以使用 ActionScript
创建新组件。
5. 理解 Flex 的 Code‐behind 模式
虽然 MXML 和 ActionScript 本质上是一样的，但他们各司其职。一般来说，MXML 负责显示
界面，而 ActionScript 用来完成功能。Code‐behind 用于解耦 MXML 和 ActionScript，这样设
计师可以直接修改 MXML 而无需阅读代码，程序员则可以更好地组织和重用功能。
6. 理解 Flex 组件的生命周期
Flex 通过状态机机制定义了一套完美的生命周期模型，用于组件的创建、运行和销毁，还定
义了一些“入口”，开发者可以借此完成定制化的工作。没有透彻理解组件的生命周期可能会
导致错误的编程模型。
7. 理解 Flash 运行时所使用的“跑道”模型
理解 Flash Player 的渲染和代码执行机制非常重要的。在执行了改变界面的指令时，Flash
Player 并不是立刻把你要的内容显示在屏幕上，它根据一定的周期来刷新屏幕，而代码的执
行则是另一回事。这和 Java 正好相反，Java 总是等待程序主动告诉它什么时候重绘屏幕。
8. 理解数据绑定与查看器（Watcher）
20

28.
Flex 提供了一种数据绑定机制。简单地说，就是将一个源属性绑定到一个目标属性上，当源
属性发生变化时，目标属性也会随之变化。不仅仅可以绑定到属性，还可以绑定到函数。甚
至可以为某个属性创建一个 Watcher，当属性变化时会获得事件通知。
9. 数据封装与松耦合非常重要
对于 Flex 和 AIR 项目来说，代码组织与高层结构非常重要。有些人竟然在一个文件中编写了
1000 多行代码，这导致的问题就是牵一发而动全身。
10. 理解 ActionScript 中的弱引用与强引用
不管使用何种语言与开发环境，内存管理始终是一个重要的问题，ActionScript也不例外。如
果不理解运行时环境的内存管理，那么很容易就会出现内存泄露与内存碎片问题。请阅读这
篇博文及文章来深入了解ActionScript的垃圾收集机制。
原文链接：http://www.infoq.com/cn/news/2010/02/Flex‐ten‐things
相关内容：
 使用Flash Builder 4 beta提升开发生产率
 开源的ActionScript调试器——De Monster
 Flash CS5 新功能提前曝光
 HTML5、H.264 及Flash综述
 Adobe终于为Flash的大bug致歉
21

29.
热点新闻 News
CWE/SANS发布 2010 年 25 个最危险的编程错误
作者 张凯峰
CWE/SANS 发布的 2010 年度 25 个最危险的编程错误，是一个传播最为广泛而且会导致严重
软件缺陷的关键编程错误列表。这些错误通常易于发现并被利用。之所以危险，是因为它们
会频繁地被攻击者利用,来完全接管软件、偷取数据，甚至阻碍软件的运行。
这个错误列表是SANS研究中心、MITRE和许多来自美国和欧洲的顶级软件安全专家共同协作
的结果。它参考的经验包括：SANS的20 个攻击导向、MITRE的普遍缺陷列表（ Common
Weakness Enumeration ） MITRE在美国国土安全部网络安全 部门的支持下维护着CWE网站，
。
对这 25 个最危险的编程错误提供了详细的说明，以及对如何减轻和避免错误给出了权威的
指导。CWE站点包括了超过 800 个 的编程错误、设计错误以及架构错误，这些错误可能导
致软件安全上的缺陷而被攻击者利用。
根据 CWE 站点的信息：
这个列表可以作为教育程序员的工具，通过识别和避免非常普遍的错误，在软件发行之前防
止各式各样一直折磨软件行业的软件不安全因素。软件客户可以通过同样的列表来要求更加
安全的软件。研究软件安全的人们可以把研究的重点放在这 25 个范围更小但更重要的软件
安全缺陷子集上。最后，软件经理和 CIO 们可以使用这个列表来衡量软件产品安全化工作的
进度。
2010 年度的这个列表是对 2009 年列表的重要提高，今年的 25 个错误是根 据来自超过 20
家不同的组织的数据进行了优先级划分，而且引入了重点的分类方法，来允许开发者和其他
用户选择自己最关心的 25 个错误中的一部分。另外，新的列表还添加了一套最有效的
“Monster Mitigations”，来帮助开发者减少或者消除所有 25 个错误，以及CWE记录的其他 800
个不安全因素。
下面是排在前五名的编程安全错误：
22

30.
1. 没有保护 Web 页面结构 （XSS，跨站点脚本攻击）
2. SQL 命令中特殊元素的不合理处理（SQL 侵入）
3. 未检查输入大小的缓存拷贝（经典的缓存 溢出）
4. 跨站点请求伪造（CSRF）
5. 错误的访问控制（授权）
原文链接： http://www.infoq.com/cn/news/2010/02/cwe‐sans‐top25
相关内容：
 处理.NET中的内存泄露
 严重内存泄漏困扰WPF
 .NET内存泄漏
 JProbe 8.0：Java代码、内存及覆盖率分析王者回归
 使用BleakHouse发现Rails应用的内存泄漏
23

31.
热点新闻 News
Google将不再支持老式浏览器
作者 Abel Avram 译者 张龙
近日Google宣布将不再支持老式、安全性差的浏览器，如IE 6、Firefox 2.x、Chrome 3 以及Safari
2，从下个月 1 号开始Google Docs和Google Sites editor就将率先履行这一决定。
近日Google Apps的管理员们收到了来自Google的一封邮件，信中说到Google将逐步放弃对几
个老式浏览器的支持。虽然很多人都认为Google这么做是剑指IE 6，但实际上Google指的是
所有的老式浏览器。今后，Google将只支持IE 7+、Firefox 3+、Safari 3+以及Chrome 4+。在用
户使用老式浏览器访问Google Docs或Sites时就会收到浏览器将不再被支持的通知“之后，这
些应用的某些功能可能会在老式浏览器中反映缓慢，或者干脆就无法正常运作”。今年晚些
时候，GMail和Google Calendar也将不再支持老式浏览器，但这并非表示用户仅仅只会收到
一条警告消息而已。根据Google发言人所述，使用老式浏览器的用户只能查看信息而无法对
其进行编辑。
根据Comscore的调查，目前GMail的用户高达一亿四千六百万，仅次于Hotmail和Yahoo位列
第三位。只有不到 1%的用户使用旧版本的Firefox或Chrome，从全球来看，IE 6 用户仍然占
据了 20%，此外IE 6 还占据了 60%的企业浏览器市场。这样，Google的这个举动将会产生很
大的影响，尤其是对一些企业来说更是如此，他们要么放弃IE 6，要么不再使用Google服务。
其他公司也已经对IE 6 采取了行动。37signals（知名的Web软件公司）早在 2008 年就开始逐
步淘汰IE 6 了；Youtube在 2009 年不再支持IE 6。到目前为止，I Dropped IE6站点上已经有 787
个公司宣布不再支持IE 6。
Digg也曾考虑不再支持IE 6，但却发现使用IE 6 访问其站点的大多数用户都是干正事的，因此
他们决定“给用户一个消息：嘿，快点升级吧！”但这么做实在是毫无意义。与之类似，InfoQ
在对访问其站点的用户浏览器进行分析后发现，IE 6 占据了整个Internet Explorer的 41%（而
IE7 和IE8 各占据 27%）。
微软早已推荐用户升级到新版IE浏览器，但却并没有强制公司也这么做。IE团队经理Dean
24

32.
Hachamovitch谈到了微软没有终止IE 6 的原因：
 对于 PC 用户来说，是否升级软件是他们自己的事儿。
 很多 PC 并不属于个人，而是公司的。公司里负责这些机器的人会决定如何处理他们。
他们要根据预算决定购买多少台 PC。对于这些人来说，软件费用并不仅仅是指购买的价
钱，还包括部署、维护的费用，同时还要确保软件能与公司的 IT 基础设施协同工作。
 我们无法放弃对IE 6 的支持，因为要在产品的生命周期内对Windows上的IE提供支持。我
们要履行自己的承诺。
近来已经有几个公司开始尝试说服Web站点停止对IE 6 的支持，同时可能会有更多的小公司
开始跟随Google的脚步，自信地宣布不再支持老式浏览器。
原文链接： http://www.infoq.com/cn/news/2010/02/Google‐Stop‐Support‐Old‐Browsers
相关内容：
 “拒绝IE6”运动
 IE中使用Google Chrome Frame运行HTML 5
 .NET安全漏洞波及Firefox
 IE和火狐将使用DirectX进行呈现
 Silverlight监测工具：Silverlight Spy
25

33.
热点新闻 News
SOA设计关乎契约还是服务实现？
作者 Boris Lublinsky 译者 胡键
大量的出版物都在描述 SOA 实现的设计，但却对接口（契约）设计鲜有关注，这让人不由
得产生一种“实现的设计更重要而且更值得关注”的感觉。对此的一个常见理由是契约会随着
时间改变，预先把过多的时间花在它们的定义上跟敏捷开发方法相抵触。
Steve Jones在他最近的贴子里对这一普遍误解提出了异议，说道：
“
在我看来，这种看法就像那种不愿意写文档的伪敏捷人士，他们根本就是狗屁不通，
而不是因为他们已经开发出了具备自描述能力的质量极高的组件。这基本上就是在
说任何人都要等到系统可运行了之后你才能知道它的功能。这等于让需求改变适应
实现。我现在并不是说需求不能改变，也不是鼓吹瀑布模型，而想说明 SOA 编程中
的时间分配问题：在确定规格说明和设计过程中，大部分时间应该花在服务间的契约
和交互上，至于关注如何设计这些服务满足契约，则可以少花些时间。
为什么契约是 SOA 实现中的最重要部分，Steve 列举了以下原因：
1. 其他组件依赖的是契约而不是设计。因其错误而导致的成本跟提供者的数量成指数关
系。一旦契约正确就位，那么人们就可以并行开发，这可以大大加速交付时间，减少风
险。
2. 测试是围绕契约而不是设计进行的。契约是正式的规格说明，设计必须满足它，而且各
种形式的测试也都应该使用它。
3. 设计可以在契约的边界内悄悄地改变。
契约的重要性这一概念并不是新鲜事物。按照Dimuthu Leelarathne的说法：如果你没有首先
设计服务间的契约，服务间复杂的集成问题就会出现。
实际上，创建好的服务契约并不是件易事，要求很好地理解契约核心业务。虽然已有一些服
务接口设计的公认方法，但是更多的时候它还是艺术而非科学。结果，开发者和软件厂商都
26

34.
典型地把注意力放在了他们受到的培训（和要卖的东西）上——服务实现的设计和编码。在
Steve看来：
“
……IT 的重点……太少地放在了确保外部接口至少在一段时间内保持正确的上面。契约
可以演变，我有意地使用了这个术语，但大多数时候，旧的契约在人们迁移到新版
本的过程中还要被支持。这意味着契约比设计拥有的生命跨度要长得多……契约是大
事，设计则微不足道。
随着我们继续提倡将SOA用于业务/IT对齐，与业务需求对齐的服务契约的作用会越来越明
显。
原文链接：http://www.infoq.com/cn/news/2010/02/servicecontructs
相关内容：
 解耦应用与依赖注入框架
 孰轻孰重：运行时SOA治理还是设计时SOA治理？
 对SOA实施者的实践忠告
 有效的SOA治理一定需要注册与存储吗？
 SOA生态系统
27

35.
热点新闻 News
Chrome中 5 大安全增强
作者 Abel Avram 译者 马国耀
为了让浏览更安全，Google最近为Chrome增加了 5 项安全增强：跨文档消息递送、
Strict‐Transport‐Security、Origin、X‐Frame‐Options以及反射XSS过滤器。其中某些特性在其他
浏览器中已经实现或即将实现。
消息递送
出于安全和隐私的原因，浏览器禁止隶属于不同域的文档之间的交互。HTML5 引入了一个
新方法，称为postMessage()，该方法允许独立的iFrame中的文档之间的交互。该方法签名如
下：
window.postMessage(message, [ports,] targetOrigin)
这样，浏览器就即能获得 iFrames 提供的安全又能实现跨文档的交互。
Strict­Transport­Security
HTTPS是用于连接网站并传输需要被保护的敏感信息的一种安全的方式。但是浏览器并非总
是强制使用HTTPS，比如，如果某网站提供的安全证书有问题，那么浏览器会发出一个警告，
而用户可以继续在半安全的连接上浏览该网站。PayPal已经成功地建议向HTML5 的规范中引
入 Strict‐Transport‐Security （STS）这个HTTP头。当服务端返回了包含STS的HTTP头时，实现
了该特性的浏览器应该：
1. 当任何安全传输错误或警告产生时（包括由网站使用自签名的证书而引起的），UA [User
Agent]结束所有的安全连接。
2. 在解引用之前，UA [User Agent]将指向STS服务器的不安全URI引转换成 安全的URI引用。
28

36.
在 Web 服务器或用户代理认为安全必要时，该特征强制使用 HTTPS。在网络繁忙的场所使
用无线连接之上的不安全的 HTTP 连接为窃听打开了大门，而结果就可能会导致个人访问网
站的私有信息被窃取。STS 可以保护其不被窃取。
目前，Paypal实现了该特征。Chrome 4 也实现了STS，此外还有Firefox的安全插件 NoScript，
它也拥有相同的功能。FireFox自身的STS实现正在进行当中。
Origin
跨站请求伪造（Cross‐site request forgery或CSRF） 攻击的方式是通过在不知不觉中欺骗一个
网站让其向 另一个网站提供私密信息。Origin是HTML 5 中包含的一个HTTP头，就可以通过
让用户代理去指定请求源的方式来解决这个问题。当一个恶意网站将请求重定向到另一个网
站时，浏览器将会在该请求中包含“Origin”头，目标网站将会根据该“Origin”是否可信来决定
是否执行相应的操作。
Google和Mozilla都在他们各自的浏览器中实现该特征。W3C的 规范提供了更多的细节信息。
X­Frame­Options
另一个HTTP头字段X‐Frame‐Options可被用于防范ClickJacking攻击。这类攻击是通过在网页的
输入控件上覆盖一个不可见的框（frame）的手段完成的，当用户点击该控件时，他实际上
是在其之上的不可见的框（frame）中输入。网站可以通过指定 “X‐Frame‐Option: deny” 的
方式防范ClickJacking攻击，支持该特性的浏览器会决绝呈现框（fram）中的内容从而阻止了
ClickJacking攻击。
IE 8 是第一个实现该特性的浏览器，Chrome和Safari继之。
反射XSS过滤器
跨站脚本攻击（Cross‐site scripting或XSS）是又一利用安全弱点进行攻击的手段，也是最难对
付的攻击之一。IE 8和Firefox的NoScript控件中有反射XSS过滤器，该特性是被Google添加到
WebKit并用在Chrome 4 中。该过滤器校验将要运行的网页中的脚本是否也存在于请求该页
的请求信息中，如果是，则极可能意味着该网站正在受到该脚本的攻击。
原文链接：http://www.infoq.com/cn/news/2010/02/Chrome‐Security‐Enhancements
29

37.
相关内容：
 代号Gazelle，微软研发浏览器上的操作系统
 IE8 脚本引擎JScript 5.8 增强
 Google发布基于全新JavaScript引擎的开源浏览器
 使用Gestalt直接在HTML中嵌入Python、Ruby和XAML
 HyperSpace：一个精巧的浏览环境
30

38.
热点新闻 News
Amazon EC2 因订购过多而导致内部网络延迟？
作者 Dionysios G. Synodinos 译者 侯伯薇
近来在Amazon EC2 用户社区中，有各种各样的报道，说他们的实例遭遇到性能很差的情况，
而这是由很高的内部网络延时所导致的。这导致有人推测对Amazon的云的订购可能超过限
度了。
aw2.0 公司的Alan Williamson撰写了一篇报道，主要是关于他在Amazon EC2 上的体验的，他
抱怨说，Amazon是公司唯一使用的云提供商，看起来它在开始时能够适应得很好，但是有
一个临界点：
“
在开始的日子里Amazon的表现非常棒。实例在几分钟内启动，几乎没有遇到任何问
题，即便是他们的小实例（SMALL INSTANCE）也很健壮，足以支持适当使用的MySQL
数据库。在 20 个月内，Amazon云系统一切运转良好，不需要任何的关心和抱怨。
……
然而，在最后的八个月左右，他们“盔甲”内的漏洞开始呈现出来了。第一个弱点前兆
是，新加入的 Amazon SMALL 实例的性能出现了问题。根据我们的监控，在服务器场
中新添加的机器，与原先的那些相比性能有所下降。开始我们认为这是自然出现的怪
现象，只是碰巧发生在“吵闹的邻居”（Noisy Neighbors）旁边。根据随机法则，一次
快速的停机和重新启动经常就会让我们回到“安静的邻居”旁边，那样我们可以达到目
的。
……
然而，在最后的一两个月中，我们发现，甚至是这些“使用高级 CPU 的中等实例”也遭
受了与小实例相同的命运，其中，新的实例不管处于什么位置，看起来似乎都表现得
一样。经过调查，我们还发现了一个新问题，它已经悄悄渗透到到 Amazon 的世界中，
那就是内部网络延迟。
31

39.
类似地，cloudkick也报告了实例的高网络延时：
“
在几周之前，我们发现在 Cloudkick 上的 ping 操作的延时图看起来非常奇怪。
……
我们在 EC2 上的监控节点会对位于 Slicihost 上的四个不同的服务器进行 ping 操作。
结果到处都是平均 ping 延时。
……
结论是什么？Alan Williamson关于EC2 被过多订购的帖子看起来非常合理。支持EC2
的网络看起来遭遇了不定期发生的延时问题。
甚至在AWS论坛上也有来自于EC2 客户的帖子，他们也遭遇了网络问题：
“
今天上午 9：15，我们有个实例开始变得没有任何响应。有时你能够登录上去，有时
登录不了。这种情况还没有自动解决，另一个实例（假定在那个实例上有硬件问题）
出现了同样的问题。我认为可能存在网络的问题。
我可以登录一两次，有时会变得一切正常，然后又变得没有响应了。有谁知道什么原
因？
实例的 ID 是 i‐c4921fad 和 i‐a0e3d7c8。当试图从位于另一个 EC2 区域的计算机连接
我们的计算机的时候，我也发现了同样的网络问题。
Alan报告说，在出现紧急情况的时候，他试图通过快速部署新实例来解决，但是没起作用：
“
在特别的“救火模式”中，我们花费了至少一个小时来启动新的实例，然后停止它们，
直到找到对我们的网络流量确实有反应的节点。
在虚拟化的环境中，特别是在“吵闹的邻居”的情况下，你恰好位于一个节点，它相邻的实例
的计算量都非常大，这看起来不是好事儿，因为有这样的趋势，EC2 会为相同的一组计算机
分配新的实例（PDF）。
你可以找到关于云计算和Amazon EC2更多的信息，就在InfoQ中文站。
原文链接：http://www.infoq.com/cn/news/2010/02/ec2‐oversubscribed
相关内容：
 亚马逊协助.NET开发人员使用其云计算平台
32

40.
 REST在IT/Cloud管理中的角色——API的对比
 AWS Toolkit for Eclipse发布了
 Clojure近况：分布式、数学运算与构建的新动向
 遗留应用在云中漫步并非易事
33

41.
热点新闻 News
全景透视Oracle对Sun的未来规划
作者 Dionysios G. Synodinos 译者 张龙
在经过了将近 9 个月的漫长等待后，Oracle终于获得欧盟的批准成功完成对Sun的收购。近
日Oracle宣布了对Sun技术与平台的未来规划。
Java、JVM及JVM上的各种语言
Oracle 产品开发高级副总裁 Thomas Kurian 说，Oracle 计划集成 Sun HotSpot 与 Oracle JRockit
Java 虚拟机；他又补充到，Oracle 打算”振兴“Java 开发者社区并将 Java 编程模型的触角延伸
到新近涌现的应用开发范式上来。比如说，Oracle 计划增加模块化特性、为 Java SE 增加多
核处理支持、为 Java ME 增加新的特性，如多点触摸等。
InfoQ联系到了Allex Miller以了解Oracle对JVM的规划：
“
我感觉 Oracle 想将 BEA LiquidVM ”JVM on a hypervisor“技术中的精华部分整合到现有
的 HotSpot 代码中；当然了，虚拟化是 JRockit JVM 中最有意思，也是最棒的部分，
非常迎合当前的虚拟化、云、集群等趋势，可以通过这些手段管理计算机资源，相
对于 IBM J9 JVM 来说，这些内容也是极具竞争力的。
我也觉得移除 permgen 并使用 thread‐local 的 GC 非常好。thread‐local 的 GC 指的是对
逃逸分析（escape analysis）和堆栈分配（stack allocation）的优化，而 Hotspot 已经
在这方面做了很多工作。大多数程序所创建的临时对象都用在单独的线程上下文中，
很少被其他线程所用。这样，我们就可以直接在栈上为这些对象开辟内存空间（这么
做更快），无需使用堆，也不必使用常规的 GC 手段进行对象检测与移除了（这么做
会降低 GC 的次数，进而提升效率）。
对 permgen 的改进亟须解决一个问题：像 Groovy 或是 JRuby 这样的语言会在执行期
动态生成大量的小类（small classes）以提供动态特性，而随着 JVM 上动态语言的不
34

42.
断增多，该问题也变得越来越严重。这些类污染了 Java 内存中特定的“permgen”部分
而且难以回收，导致了严重的内存问题。JSR 292 的 invokedynamic 就是为了解决该问
题的：动态语言可以通过该指令在运行期直接链接到调用地址上，因此避免了生成大
量内部类的烦恼。
我认为最好的处理方式并不是消灭掉这些 JVM，而是取其精华，弃其糟粕。这些工程
团队都有一些优秀的人才，他们做出了很多创新性的工作，我希望他们能在这个领域
继续做下去，只有这样 JVM 才能继续充当老大的角色，吸引众多具有开创性的新语
言，如 Scala、Clojure、Groovy 及 JRuby 等。
Oracle对JCP的未来及其在Java 7 中所扮演的角色所谈甚少，来自RedMonk的Stephen O'Grady
指出：
“
我觉得 Oracle 对 JCP 的态度要比 Sun 此前的做法更注重实效，但现在还很难预测未
来的走向。
MySQL
Oracle 首席开源架构师 Edward Screven 说公司将会一如既往地支持 MySQL 数据库的发展，
Oracle 将 MySQL 看作是对其核心数据库技术的有益补充而非竞争对手。Oracle CEO Larry
Ellison 强调说，公司将会做出更大的努力改进 MySQL，力度甚至会超过 MySQL 以前的投入，
但却没有提到 Sun 和开源社区。Oracle 将为 MySQL 建立一个独立的销售团队，同时增强其
与 Oracle 其他软件应用之间的兼容性。
JavaFX与RIA技术
Oracle 在声明中再一次强调将会加大对 JavaFX 的投入力度，同时 DHTML、JavaScript、Java
及 JavaFX 的整合也是未来的一个重中之重。
此前Oracle曾终止了BEA打算绑定Adobe Flash/Flex开发工具的计划，现在的这个声明终于填
补了该沟壑，来自ZDNet的Tony Baer指出：
“
我们不难发现 JavaFX 在 Oracle RIA 计划中所占据的重要地位；它填平了 Oracle 终止
BEA 绑定 Adobe Flash/Flex 开发工具计划所导致的 RIA 鸿沟。实际上，Oracle 对 RIA
的态度着实令人迷惑，因为 ADF 可以支持任何框架的客户端显示，而 JavaFX 现在却
35

43.
变成了 Oracle 自己的东西。
JavaFX的拥护者，同时也是开发者Jim Weaver对Oracle支持JavaFX平台的举措信心十足：
“
今天的声明更令我坚信 JavaFX 将会继续发展下去，会有越来越多的应用选择 JavaFX
作为 RIA 平台的。目前 JavaFX 至少面临三个大的挑战，我相信 Oracle 会全力以赴迎
接这些挑战的。
NetBeans
InfoQ曾报道过此次收购后NetBeans的未来将变得扑朔迷离。
Tony Baer确信相对于JDeveloper来说，NetBeans将变成二等公民了：
“
对于 NetBeans 来说，玩玩还是没问题的，Oracle 中间件领导 Thomas Kurian 将 NetBeans
定义为“轻量级的开发环境”；但如果真的想为 Oracle 平台开发企业级应用，那还得
使用 JDeveloper，JDeveloper 主要面向的是 Oracle 的 ADF 框架，后者则是 Oracle 数据
库、中间件及各种应用的根基。这与 Oracle 对 BEA Eclipse 开发工具所持有的态度是
一样的。事实上，令我们感到惊讶的是 Oracle 并没有草草地将 NetBeans 解决掉并免
费送给别人——比如捐献给 Apache 或是其他开源组织。
Stephen O'Grady也持有同样的观点：Oracle并不打算在Sun的IDE上做太多投资：
“
声明中提到了 NetBeans 以及 OpenOffice.org，我们推测 Oracle 并不打算在这个时候就
干掉他们。是的，他们还会留存于世，不过将要退居二线了，把头把交椅让给
JDeveloper。
GlassFish
Oracle 产品开发高级副总裁 Thomas Kurian 说到，Oracle 将会继续支持 Sun 的 Web 应用服务
器，但这么做仅仅是一种部门解决方案，Oracle 自己的 WebLogic Server 将继续担当企业解
决方案的角色。
Stephen O'Grady觉得Oracle将不会再资助GlassFish了：
“
根据 Oracle 所述，GlassFish 将变成参考实现。除此之外，Oracle 并没有承诺其他任
何东西。早上有人对我说，Oracle 并没有为 GlassFish 安排任何销售团队和市场部门，
和 MySQL 的下场一样。这里有两种解读方式：首先，如评论所说，“Oracle 认为捆绑
36

44.
销售 GF+WLS 将会获得更多的机会，进而满足不同项目的需求”。另一方面，Oracle
认为捆绑销售产品会破坏其 WebServer 产品线，因此会通过组织的变更慢慢地将
GlassFish 扼杀掉。WebLogic 销售的那帮家伙怎么会推出一个更便宜的 WebLogic 替代
品呢？
Cloud
Oracle 首席架构师 Edward Screven 说到，Oracle 并不会支持 Sun 规划许久的 Cloud 服务。Sun
此前宣布将通过 Sparc 刀片服务器、应用于 x64 刀片服务器的 Xeon 与 Opteron 处理器以及
开源的产品 ZFS 和 Crossbow 开发出 Amazon 风格的云，提供计算和存储服务并支持 Sparc 和
x64 机器上的 Linux、Windows 和 Solaris。
Sun 的 Cloud initiative 计划最初是用于网格计算的（Network.com），后来没有吸引多少客户，
结果在 Cloud 的背景下被淘汰掉了。
Stephen O'Grady对Oracle不支持Sun Cloud的结果给出了自己的看法：
“
众多客户都不再需要虚拟或是物理设备了，这有利于提供所谓的最佳架构。尽管
Ellison 非常讨厌 Cloud，但 Cloud 还是有其用武之地的。Ellison 讨厌 Cloud 的原因在
于他认为 Cloud 并不是什么新玩意儿。Cloud 不过是通过网络交付价值的数据库和中
间件而已。公平的说，他的观点还是有一定价值的，尤其在当今这个世界上，厂商不
断地抛出“Cloud”这个词儿，好像它马上就要过时了一样。换句话说，从大众拥抱 Cloud
这个事实以及“Cloud”术语所暗示的那样，无论你认为 Cloud 是新东西还是老古董都无
所谓，至少它简化了设备的销售。我想说的是，Oracle 并没有过多地谈及 Cloud，但
这并不意味着 Cloud 已死，只不过是 Ellison 对 Sun 业务的未来规划而已。
Sun 的很多开源项目都没有达到预先的期望，无论从竞争力还是回报角度来说都是如
此，他们将不得不面临退出历史舞台的命运结局。Oracle 是一个更加注重利润的公司，
这一点要远远超过 Sun，单凭这一点，那些没什么搞头的开源项目也将面临着停业谢
客的结局。
Open Source
由于 Sun 过去曾在开源产品开发与开源社区建设等方面投入了大量的资源，因此人们普遍认
为 Oracle 的此次收购对开源是个巨大的打击。
37

45.
来自RedMonk的Stephen O'Grady对Sun开源社区的前景也持悲观的态度：
“
坦率地说，Oracle 的声明并没有过多地提到开源。单词 open 倒是出现了不少， source
但
却并没有一同出现。从宏观角度来看，我认为这会对开源社区造成消极的影响，因
为此次收购是从一个非常注重开源的公司到对开源并不是那么热衷的公司的转变。
但实际上，我觉得有必要一个一个地谈谈这些开源社区，就拿 Java 来说吧，它肯定
没什么问题。Oracle 的举措定会让 Java 社区欢天喜地。但 MySQL 注定要成为一个孤
独的人了，而 OpenSolaris 的命运则充满了变数。
来自ZDNet的Dana Blankenhorn也认为Oracle的这种做法会对开源社区造成非常消极的影响：
“
现在 Oracle 掌握着任何开源业务底层代码的版权，他的名声注定了利润最大化才是
追求的唯一目标：圈地、拉拢客户这些事情 Oracle 都干的出来。此次收购有一点值
得我们关注：Oracle 不再支持个人或是小公司可以通过社区的形式迎战业界巨头的做
法了，因此那些巨头会轻松将你击垮。
来自RedMonk的Michael Coté觉得Oracle不会再像Sun那样对开源运动进行大量投入了：
“
除非你有预算并确实需要高性能的硬件和中间件，否则 Oracle 是不会（就是为了赚
取利润）关注 LAMP、开源、“lesscode”这些东西的。Ellison 对 Java 的态度还是非常
友好的：Java 并不需要直接为公司创造利润， 它只要能为整为公司的其他业务添砖加
瓦就够了。Oracle 相信其“闭源”的产品（Oracle DB、WebLogic 等）要“好过”那些开源
的对手（MySQL、GlassFish 等），只要开源产品不搞出什么麻烦出来，那就没什么事。
裁员
就Sun去年的裁员一事，Oracle CEO Larry Ellison说到，未来几个月内，公司还将裁员不到 2,000
人，同时还会再招聘 2,000 多人从事工程、销售和其他业务。当然了，他并没有排除未来还
会继续裁员的可能。Ellison又补充到，他希望Sun CEO Jonathan I. Schwartz能够自觉离开公司，
并希望Sun的联合创建者与主席Scott G. McNealy能够留下来，但头衔和职位还没有确定。
Jonathan Schwartz在Twitter中提到其最后一篇博客是“likely his last blog at Sun”。
读者可以观看Webcast来了解Oracle与Sun的产品策略。
还在访问Sun网站的各位读者朋友，是不是已经发现了什么变化呢？
译者的话：在翻译完这篇新闻后，心情久久不能平静，一个伟大的技术公司就这样倒下了，
难道这真的是“纯技术”公司的宿命么？公司的目标都是获取利润， Oracle 则将这一理念发
而
38

46.
挥到了极致：凡是与利润不相干的一律干掉，原文用“ruthlessly profit focused”来形容 Oracle
对利润的渴求。当然了，对利润的追逐本身无可厚非，可能我还是太傻太天真：‐）。再也看
不到 Sun 的首页了，感觉 Oracle 的首页给人一种冷冰冰的感觉。
InfoQ的各位读者，您想对Sun说些什么呢？发表在这里吧，我们想倾听各位的心声。
再一次将 Java 之父 James Gosling 博文中的图片发布在这里，以悼念年仅 28 岁的伟大的 Sun
公司。
原文链接： http://www.infoq.com/cn/news/2010/02/sunset
相关内容：
 Bundle.update：OSGi现状
 NetBeans社区庆祝十周年生日
 Java SE 5 服务周期已终结
 Amazon RDS: 作为云服务的MySQL数据库
 亚马逊开始提供MySQL服务
39

47.
热点新闻 News
MonoTouch已支持Apple iPad
作者Abel Avram 译者 张龙
就在Apple发布iPad平板电脑 24 小时后，MonoTouch团队就发布了MonoTouch 1.9（alpha），
该版本致力于辅助.NET开发者编写iPad应用。
近日Apple发布了万众期待的平板电脑iPad以填平移动设备（比如移动电话）与笔记本之间
的沟壑。iPad看起来像是放大了的iPod Touch，和上网本也有类似之处，但有一个重要的区
别：iPad没有外置鼠标和键盘，输入只能通过多点触摸实现，这意味着单击、双击和右键变
成了敲、捏以及捻这三个动作。
使用Mono创建iPad应用的方式类似于iPhone；MonoTouch包含了iPhone SDK，该SDK也支持
iPad。值得注意的是：虽然从理论上来说，我们可以在Windows或是Linux上开发iPad应用，
但实际上，Mac OS X Leopard或是Snow Leopard系统还是必备的，因为目前iPad Simulator（硬
件模拟器）和Interface Builder（用于构建UI的可视化工具）只能运行在Mac上。除此之外，
Apple要求MonoTouch团队只能在安装了iPhone SDK的电脑上安装MonoTouch。这意味着开发
者只能使用Mac开发环境。完整的要求列举如下：
 运行 Mac OS X 10.5 或 10.6 的 Intel Mac 计算机
 Apple iPhone SDK 3.2
 最新的 Mono
 MonoTouch 1.9 Alpha
 MonoDevelop 2.2.1（该项虽不是强制要求，但对开发却很有帮助）
目前通过 iPhone SDK 所创建的应用还无法同时运行在 iPhone 和 iPad 上，但不久之后就可以
了，同样 MonoTouch 也将增加相应的支持。
iPhone开发的限制（当然也适用于iPad了）包括：有限的泛型支持、由于缺少iPhone OS的支
持所导致的无法进行动态代码生成、不能进行远程访问、无COM绑定、无JIT。MonoTouch
40