用一个词来形容，那就是：敏捷。我们的目标就是要为创建面向Web的应用引入敏捷。我们正准备围绕三个方面进行创新。创新围绕着创建面向Web应用，从存在的RESTful服务、feeds和内容中装配和拼接新的应用，以使你从Web或者企业开发中解放出来，第三个方面就是执行这些应用。

让我对每一方面稍微多说一点，因为它们都很酷。我认为围绕着创建有两个主要的概念。第一个概念是动态脚本（dynamic scripting）。如何使你的项目变得敏捷？其实并没有必要在面向对象的结构环境中编写代码，而可以使用脚本。

在Project Zero中我们认识到了这一点，所以便引入了2种脚本语言。

在深入探讨脚本之前，我先说下Java。Java社区为我们提供了很好的服务，就像在IBM特别是WebSphere中那样。 Java充满了活力，也许能够继续辉煌十年。我们已经对Java的发展做了促进。现在Java已经成为了系统编程语言。它应该被用于实现Project Zero中精妙的部分，但我们希望你关于敏捷的第一次经验大部分来自动态脚本。

所以我们在Project Zero中提供了两种动态脚本用于选择。一个是为熟悉Java的人准备的——脚本语言Groovy。我在博客上曾开玩笑说Groovy是Java的尼古丁贴剂（nicotine patch）。当你开始使用Groovy贴剂，我们就有一定的把握让你戒掉Java，转而接受动态脚本。因此，如果你想不再使用Java，但又想能访问你之前使用Java写的类或者方法，你可以用Groovy做到这一点。但是，我们将让你使用Groovy提供的更简洁的动态语法，就像Ruby和 Python一样。

另外，基于PHP的人气和内容。我们认为使用Project Zero，通过基于一个公共Java平台支撑的动态脚本语言Groovy和PHP，你的项目将会敏捷起来并且能按需编码。

那么，动态脚本是其一……。另一方面的概念是：Project Zero是基于SOA架构构建的，并且这个架构是一个RESTful的架构。围绕着概念REST，我们已经做了约束和简化。在Project Zero中，你基本上只需要使用HTTP。当你在Zero中表示一个服务的时候，就代表你在用RESTful的方式或者REST派生方式表示服务。我们可以用RSS feed或者ATOM feed的方式表示服务；但Web是我们使用Zero构建的主要平台，而REST正是我们在Project Zero中构建的服务交互风格。

对此，我们同时考虑了现行的一些流行框架，并已经为此建立了一套约定。约定替代配置，因此如果你想要表示服务，并没有必要编码。Project Zero中有一套标准，如果你在构建服务的时候遵循它们，就会发生奇迹。将动态脚本和REST结合起来，现在你已经真正地理解了它！这是两个真正重要的因素。

另一部分是装配。对松耦合的系统来说，SOA的优点之一就是你可以从这些新近发布的服务中创建一套新的应用程序。在 Project Zero中我们会毫无疑问促进这个优点。正如我提到的，我们的服务模型是围绕着一个面向Web模型构建的，因此它的构建基于REST、feeds。那么现在要做的就是通过脚本、PHP或者Groovy编写程序，或者通过一套我们拥有的可视化编辑器设计，让你围绕刚刚创建或发布的基于Web面向Web的服务创建新的应用。或者可能重用其它来源的服务，比如来自Web或者你所在的企业。这就是关于装配的基本想法。现在我们用一些有趣的功能来拓宽这些想法。

如果你已经在Web中使用了其它技术来可视化地创建动态Web应用，那我们是支持这些可视化技术的。Zero中提供了管道（Pipe）类型的接口。我们的一些装配可视化工具并没有什么太大的区别，但我们现在要做的区分是建立在一个很简单的方法之上——围绕流程的一些基本概念。不管我是否构造和装配数据流（data-flow）——在数据流中我可以得到两个feeds、汇集这些feeds、归类这些feeds。这样，我不仅通过创建数据流来构建一个应用或者构造一个新的装配集，而且顺着流程嵌入了活动，也就是活动流。因此，对于合并feed、发送邮件或者SMS信息这样的服务，我可以使用可视化编辑的方式或者纯编码的方式将其混合匹配起来。我可以编写Groovy或者PHP脚步来获取feed，合并它、汇集它等等。能够根据先前创建的服务迅速地组装出新的应用，这非常强大，而且是对Project Zero敏捷特性的又一贡献。

第三部分是关于执行。正如我刚才所说的，Java世界充满了活力。我们围绕Project Zero所做的就是将执行动态脚步语言（也就是Groovy和PHP）的环境集中于Java上。在运行时我们可以做许多有趣的事情，来优化这些动态脚步语言的执行。能工作在这个领域之中，我真的感到很兴奋，特别是在为Websphere应用服务器在执行脚本可能性工作的这些年里。

什么是脚本？一份脚本有着非常精确的起点和终点。执行它，而后就会结束。很多运行在应用服务器之上的传统应用程序是为了长期运行而构建的。那长期运行会有什么样的问题呢？我们并不完美，所以在这些程序中会有一些细小的缺陷，而且随着时间的推移开始溃烂：内存泄露、线程吊起等等。这往往使应用程序运行时间越长越难驾驭。

Project zero的应用程序和执行环境倾向于采用运行随即结束（run-and-done）的特性。开始一个脚本，运行结束然后停止（Kill）这个脚本，如此开始一个新的脚本，运行它并停掉它。即使应用编写的不完美，其中的缺陷也是可以忽视的。如果应用中存在内存泄露，至少它不会对结果或者系统有明显的影响。我称这种缺陷为海森堡虫（HeisenBug）。我喜欢说Zero运行环境是对海森堡虫免疫的，因为有些我们通常在运行的服务器中看到的缺陷是可以绕过去的，例如通过运行和完成脚本模型。我们可以得到很多有趣的好处。

关于执行环境的另一部分，即Zero是一个面向Web的平台。我们知道如何来缩放网络应用，我们已经在Websphere中做了好一段时间。Web自然地缩放；REST是极好的缩放协议。我之前提到过句子的比喻，url是围绕内容的nounds、操作和动词。基于此很容易建立缓存规则，并且非常准确。在其中有许多缓存技术，而且有一些我们正明确地构建于Zero中，以协助你构建高性能可伸缩的应用。分区（Partitioning）、负载管理（workload management）、高可用性（high availability），在面向Web的背景下，我们知道如何做到这一点。我们在Project Zero运行时中构建了这些。Project Zero可以运行在普通的JVM上，不过我们也会对其（特别是IBM的虚拟机）进行增强，以更好地运行敏捷的脚本化应用。

当谈到典型的Zero式RESTful应用时，我通常会用句子来比喻。当你思考一个基于Zero的应用时，想一想英语中的句子。在句子中有名词、动词和形容词。我可以这样造一个句子。名词可能是“照片”，动词是“观察或者读取”这个照片，“获取照片”，并且形容词是照片的类型 ——JPEG格式的照片。这个句子是：“读取JPGE格式的照片”。在Zero中我可以表示这一点。名词是RESTful实体。那你如何来表示一个 RESTful实体？用URL：/something/photo。动词是“获取”，而在REST的术语中正好有四个主要的动作：get、post、 put和delete。这样句子就是“get photo”。数据类型是什么？可以是JPEG。想想构建这样的服务就像组织句子一样简单。通过这种机制快速的表示语句、表示服务和暴露内容是非常强大的，能使你的时间实现价值。

数据从何而来？脚本的内容从何而来？我认为一种情况（特别是对于企业情况）是，数据来自外在环境。当你想基于那些数据开始构建应用时，打比方说我有一个商业系统；我不建议在Zero中构建商业系统，而可以使用Zero的一种情况是构建一套应用程序。我们称其为情景应用（situational app）。你可能在年初并没有计划做这些应用，而是刚刚提出需求。在过去，你可能使用Lotus Notes和基于Lotus协作产品的工作平台，或者Microsoft Visual basic，或者诸如此类的东西来构建这些应用。我们有一些典型的老企业应用，它们产生着数据，现在你想通过新的视图查看数据，想用新的方式组合数据。可能会有多个来源的数据，一些企业数据，一些数据来自互联网，你想把那些数据集合起来给出新的透视图。你要做到这一点很快。

我没有必要规定你使用限制类型的应用程序，但当你尝试快速地完成某事而且数据来自外界时，可以说Project Zero是最有用的。

IBM，特别是软件集团（software group）中的我们，是SOA的幕后推动者。SOA是一种架构风格，我们认为其行之有效，具有成本效益，以及所有的这些特点。我们已经很清楚SOA是一种架构风格，还没有事实上的SOA实现。通过我们的产品，我们一直在提倡和推动基于WS*等一组产业标准的SOA实例。WA*提供了一套功能，是工业级强度的关键。而SOA非常适合于我们产品组合中的标准类型。但问题是：这是不是能一刀切？这是唯一的SOA实例化方式吗？绝对不是！

REST让我兴奋的是——如果按照80/20法则——会有一系列的活动不需要严格遵照WS*的规定。REST让我兴奋的是我们认为它可以提供入门级的SOA。

REST的好处是它就像我们日常呼吸的空气一样。它是围绕Web而产生，而Web就在我们的周围。这就转化成了各种有趣的事情：技能、基础设施，这些东西就在那里。能够以你已经有的经历为背景，来谈论SOA模型是非常有说服力的。我们可以使你非常快速地实现SOA，毫无疑问随着你的进步，你将会需要WS*，但是REST能给你一个起点。现在，我们如何来解读80/20规则，是80％的人在做20％的事情吗？

各种各样关键的东西都可以通过REST表示。这让我们感到兴奋，而这也是与SOA有联系的地方。REST是围绕着松耦合概念构建的一种架构风格。如果你看到Ajax应用借助互联网上的HTTP通过JavaScript调用服务；这是构建松耦合系统的极好的例子，因而当我将基于 Ajax的架构作为SOA的例子谈论时，感到非常兴奋。不管你是否在企业当中，你都会承认这些事实，而且通过REST你可以开始了解SOA的精妙之处。

这使我有点紧张，因为REST之美在于它只做它擅长的工作。它多年来一直是这么做的。让我们更有条理地探讨一下，我之前提到了用句子来比喻如何思考REST的主要服务方面。我不想看到REST被复杂化，因为它的美妙之处在于它的简单。明确地划分SOA的风格，像RESTful SOA、企业级SOA，我认为是很重要的。

我们正在试图围绕企业级SOA完成的事情其本身就是很复杂的。例如试图整合支持同步和异步协议并有着不同架构的系统。这是现实中必须要处理的事情。我认为WS*的方式以及一些主题相关的标准是非常有效率的方式；但这些都是复杂的问题。我不想看到围绕REST的简单问题被引伸到某种程度试图解决其中的一些复杂问题，因为这样REST将不再是吸引我们的REST了。

政教分离是伟大的举措，因为我们有WS*、纯Web和REST。但一旦我们试图开始正规化REST，像“REST对应的 WSDL是什么？这并不存在。”让我们尝试保持句子结构，因为我们有WSDL，而且它对它所做的事情是有好处的。当需要严格定义的时候，我们有这样的能力。我见过客户非常好地使用这两种方式。他们开始通过WSDL定义服务，并通过这些切入点（entry point）以及REST暴露入口服务（entry service）。我认为两者都要生存的空间。两者的并存让我很高兴。我不想让一个事物变成另一个。

绝对不是，如果我给人这样的印象，那决不是我的本意。事实上REST是RESTful SOA的一种方式。另外，我要说REST在某种意义上并不特殊，它是Project Zero与生俱来的权利。我觉得Project Zero擅长于REST，但当我们看IBM软件集团和Webshpere中的整个产品组合，REST将是这些产品中不可或缺的一部分。以我们的流程服务器（process server）或者ESB为例，其中会提供REST入口，将会暴露产品的活动和功能：管理功能、通过REST接口监控产品。重申一下，REST就像空气一样，一切都在我们身边，我们将在产品中纳入这些。我们支持远离WS*？不。我们通过这些产品完全拥抱Web？是的。正如我之前，它们并不互相排斥。

我完全认为这是一个新兴的趋势，正如我以前对Project Zero所说的那样，我觉得它在你的产品组合中有一种敏捷的能力，能让你充分利用这一点。

围绕着Web和云计算的精彩之处是能够用一个非常普遍的、可缩放的和统一的方式暴露内容。我们在鼓励企业暴露它们的内容，不管它是在防火墙之后还是之前，因为这是在解放数据。一旦数据得到解放，你便可以以此构建有趣的应用。不管是Flickr、Amazon、Google还是其它大企业，都在内部地暴露它们的传统公司数据，现在使数据（不管关系明显是否）联系起来的机会来了。

奇妙的是，通过解放数据，通过将数据放在人们手中，通过释放数据，也许我们将学到我们之前不知道的东西。我觉得这着实令人兴奋，我们已经一次次地看到过这种情形。

我们对它将如何发展有非常明确的认识。我们在数据之上有相应的视图。通过解放数据和创建敏捷环境，你可以创建新型的应用程序，可能会得到数据的新型透视图。我认为云的概念和通过Web普遍暴露的API将释放新的机遇、新的前景和新的商机；我认为这是真正让人兴奋的地方。

我们现在正处于一种状态：在Web中REST就像空气一样普遍存在。我们希望它能够在我们的产品中得到普及。我们所能看到的就是贯穿于我们产品线的发布卖点。我将在谈及WebSphere产品线时，特别地介绍其中的REST能力，就像我们产品的固有部分那样。

那我们的一个经典产品来说：WebSphere MQ，我们获奖的消息产品。在最新发布的MQ上，我们有能力通过REST来暴露MQ的功能。首先，现在你不需要通过MQ客户端来驱动MQ中的工作了。如果想在队列中发布一条信息，你所需的就是一个能通过REST发布消息的Web环境，无论是Javascript应用、PHP还是Zero应用。现在你可以通过REST与MQ进行交互。如果你想做类似于检查队列中内容的事情；对此有专门的REST接口提供。

REST就像空气一样：人人都有浏览器，人人都有基于Javascript的环境。现在通过REST，通过在那里明摆着的无所不在的SOA接口，你可以开始与我们的中间件直接交互。

可以来浏览下我们的产品组合：WebSphere应用服务器，我们有了一些所谓的Web2.0功能包，它将根据REST、 Aton和Ajax comet提供功能——从服务器动态更新返回到Ajax客户端，并允许你在JEE应用之上混合RESTful风格的接口。我可以继续列举我们的产品组合，从WebSphere ESB到Datapower应用，都根据这些技术加入功能来支持RSETful接入口（on-ramp）：比如，我想向ESB中放入一条消息，不管是 WebSphere基于Java的ESB还是基于应用的ESB，都有RESTful接口提供支持。

这些并不会作为附加功能提供，而是作为的完成功能的一种方式，成为环绕在WebSphere商标周围的核心技术的一部分。

我经常被问及这个问题。对此，我喜欢的思考方式是……在IBM中我们已经成立孵化器项目好多年了，而且我们还会进行相当长的时间。传统上，我们在防火墙之后进行我们的孵化器项目。我们将这个时期用于创新；然后我们可能选择一些客户对他们公布这些创新。有时候我们感到很惊讶；也许它并没有那么有新意，或者只是我们心中的创新。我们应该着重于改革创新的缺陷。就像将达尔文进化论引入软件开发一样，创意也要适者生存。我们想将我们的创意展示给感兴趣的社区，不管它是不是IBM的客户。只要他们对我们的课题感兴趣，这都没关系。从他们那里获取信息，建立紧密的反馈途径，已使我们创新的东西不仅让我们自身感兴趣，而且潜在的客户也感兴趣。

Rational与我们谈论的Zero使用了相同的方法；我们为Rational划分了一个叫做Jazz的项目，它处于和 Zero相同的情况。其理念是“在可视墙后面孵化，并公开结果”。我将其比喻成这些日子里雨后春笋般冒出来的一些餐馆，你进入餐馆并有权在餐馆中部观看厨师烹饪。对我来说，这与Project Zero有几分相像。我们不是在闭门造车，我们实际上是在开放式烹饪，食物就在你可以看到的面前。

在Project Zero中你可以看到源码，你可以与构建源码的人们通过论坛和博客与他们交流。你可以跟踪我们的里程碑。你可以影响项目、参与投票、发送意见、下载并体验代码。

我还没有说到任何关于许可的问题，因为我想在这里保持政教分离。对我而言，能够开发可视化并公之于众是某种开发风格。这是我们开发这个构思的方式。我们想保持公开。为了免费而政教分离，我认为是我们正在试图去做的事情。

Project Zero是免费的吗？它的授权许可有什么特征？它并不是无条件免费的。它可以免费体验，并在一定程度上免费使用，但是从某种意义上我们是要卖软件的。我们努力尽早得到人们的反馈。不管是传统的客户还是非传统的客户，我们对其反馈表示感谢。

现在我们可以谈论下一个问题了：Project Zero采用哪种许可？对成长中的小规模经营者，和为预期投资做前期调研的人们，在许可方面我们自然会非常的灵活自由。当在产品中运行了我们的代码时，就需要和我们的销售团队商讨许可的问题。

其主要目标是我们如何使Project Zero保持可见、开放、位于防火墙之前而不是其后。将我们的思想释放，建立用户社区，让达尔文进化论发挥作用。

我们的产品和品牌有着很多的忠实用户，我们不希望他们仅仅在最后对此感到诧异，我们想提前放出项目。希望能尽快发布创新的解决方案给客户，而且我们认为这是奇妙世界中开源和商业软件开发之间的有趣组合。那它是黑还是白呢（译注：黑白分指前面提到的开源软件和商业软件）？我认为它是有趣的灰色，我们正在对此进行试验。到目前为止，试验进行顺利，我们已经有大约50000名独立访问者和大约135000次下载。

正如我所说的，对于IBM和WebSphere的所有人来说这是一个真正激动人心的时刻。Project Zero真正地触及了一些令人感兴趣的东西和新的概念，其都说明了我们如何来构建产品（使用Project Zero，它们都位于防火墙的可见端），通过使用像Groovy这样的动态脚步语言初次尝试使Web脚本化，依据RESTful架构构建，并真正地用于系统核心的构建，围绕着通过mash-up装配应用有着令人感兴趣的技术，真正地运行在基于动态脚本语言的执行环境上。

动态脚本、REST和Project Zero真乃天作之合，感觉棒极了。大体上，它恰好适合我们对Websphere的探究，也非常适合作为进入SOA的入口匝道，使行业围绕着Web方向前进发展 。对这个行业和IBM来说这都是天作之合。这真是令人兴奋的时刻，点击projectzero.org，并感谢你们的支持！