什么是Project Zero？
用一个词来形容，那就是：敏捷。我们的目标就是要为创建面向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的虚拟机）进行增强，以更好地运行敏捷的脚本化应用。
什么类型的应用不适合使用Project Zero，并且你何时需要整合其它资源来进行实践？
当谈到典型的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是最有用的。
