模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
Google推出Web开发利器：AppEngine
作者 Geoffrey Wiseman 译者 胡键 发布于 2008年4月14日 上午3时59分
2008年4月7号，Google在Campfire One上介绍了一种简化创建、运行和构建伸缩性Web应用的工具——Google App Engine。简而言之，Google App Engine允许你本地使用Google基础设施构建Web应用，待其完工之后再将其部署到Google基础设施之上。
这次发布的是没有包含全部特性的预览版，提供了一个配额系统，它限制了在预览期间应用免费可用的存储、CPU和带宽。一旦预览期结束，配额仍将免费，但是开发者需要按需购买额外资源。额外资源的价格尚未公布（甚至可能尚未确定）。
预览版的配额包括：3个应用/开发者、500MB存储/应用、2000封邮件/天（连续24小时）、10 GB入站带宽、10 GB出站带宽、200M CPU兆周、650k HTTP请求、2.5M Datastore API调用和160k URL Fetch API调用。
技术：开发环境和API
尽管Google说‘未来将支持更多的语言’，但是目前技术栈是基于Python的，它是Google认同的语言之一。出于安全和伸缩性的目的，Google提供了一个运行在安全沙箱中的Python运行时环境，它提供对底层操作系统有限制的访问。该环境包括标准库，并可通过模块进行扩展，编写模块的语言目前不支持C语言。
该环境包括Python标准库。当然，调用那些违反沙箱限制的库方法（如打开socket或写文件）将不会成功。为了方便起见，几个核心特性不被支持的标准库中的模块被禁用了。那些引入它们的代码会出错。
应用代码只能用Python书写。不支持使用C来编写扩展。
其他安全限制包括：出站通信（outbound communication）只能通过所提供的邮件和URL fetch API进行，通过HTTP和HTTPS作为传输的入站通信（inbound communication）使用标准端口，禁止文件系统写操作和禁止子进程或代码在请求/响应循环外执行（例如后台操作和批操作）。
此外，Google提供了访问一个Datastore、Google用户帐号、URL fetch和邮件服务的API。App Engine还包括一个简化的Web应用框架和Django 0.96.1，尽管App Engine Datastore不是关系型的，而且也不能使用全部的Django API。
Datastore API背后由Google的BigTable支持，但是它与一个简单的对象持久化API（或一个对象关系映射框架，即使Google强调这个Datastore不是关系型的）有很多相同之处：
你们中的大多数，在使用这个Datastore时可能会有点不习惯：如我所说，它不是SQL。这是个巨大的区别。然而，我们想了一下之后，认为这个Datastore可能会引起你们的兴趣，因为它让一些事情变简单了。比如说，我们的Datastore没有模式，这意味着它可以支持任意的新属性或列，你可以用代码创建，无需把所有事情预先设计好并创建一个模式。这就回到了我们尽可能简化Web应用编写的目标：只需开始编码就好了。你的数据模型可以随你应用的演变而演变。
即使Datastore违背了SQL，我们仍然支持你想要的传统关系数据库的许多强大功能。对于任何你提供的单个属性或属性集合，Datastore都提供了高效查询。它还支持对查询结果的排序，包括按多属性进行排序。它对写操作支持事务，通过事务分组来控制。对于提取或创建大量实体，它也支持批操作。它给你机会让你来控制你实体的主键，以获得更好的查询效率和更短的URL。
并且，即使Datastore不是SQL，我们也为你提供了类SQL查询以简化查询的表达，叫做GQL。GQL受到了jQuery和FBQL的启发：底层的存储不是SQL，但是几乎你想要的所有查询仍然可以完成。
你可能已经注意到我们的Datastore缺少一个大特性，那就就是连接（join）。这是因为连接通常是分布式系统效率问题的根源，当你有不止一台机器时：很难在跨多个机器和多个硬盘的分布式系统上进行连接操作。
尽管Datastore API支持事务，但是它们有严格的限制，而且和实体组关联：
每个实体都属于一个实体组，在一个事务内可以操作一个或多个实体。实体组关系告诉App Engine在分布式网络的同一部分保存几个实体。一个事务为一个实体组设置Datastore操作，所有这些操作按组实施，如果事务失败就全部撤销。
当应用创建一个实体时，它可以分配另一个实体作为新实体的父。给一个新实体分配父时，将使它进入父实体所在的实体组。
没有父的实体是根实体。一个实体的父实体也可以有父。从一个实体到根的父实体链就是这个实体的路径，路径的成员是实体的祖先。实体的父只能在创建时定义，之后就不能修改。
祖先是同一根实体的所有实体都在相同的实体组中，组中的所有实体存储在同一Datastore节点中。单个事务可以修改单个组中的多个实体，或通过将组中现有实体变成为新实体的父来把一个新实体加到组中。
因为App Engine迫使你以一种特殊的方式（如Datastore on BigTable，而不是数据库）来处理你的开发，Google声称你的应用将更易于伸缩，而且这种伸缩性几乎是透明的：
当一个Web应用变得流行起来时，突如其来的流量可以压垮各种规模的应用，从创业公司到大公司都发现需要一年几次的重新架构他们的数据库和整个应用。通过自动复制和负载均衡，利用Bigtable和Google的可伸缩基础设施中的其他组件，Google App Engine使得应用可以从一个用户伸缩到百万级用户。
User API允许通过Google帐号进行用户验证和登录，以及访问帐号的绰号和邮件。其他更多的用户信息可以从应用保存在Datastore中的用户信息直接获取。
URL fetch API能通过提取HTTP和HTTPs URL（支持GET、POST、HEAD、PUT和DELETE，因此这似乎可以支持REST功能）检索远程服务器的信息。
Mail API允许App Engine应用异步发送邮件，如果邮件服务器不可用时允许重试。
App Engine SDK包含模拟App Engine Python运行时环境的服务器，以及：
- 模拟模块引入限制，只允许处理程序引入被许可的模块，它们来自标准库、包含在App Engine Python环境中的第三方库，以及应用目录中的模块
- 模拟应用缓冲行为
- 使用本地文件模拟App Engine Datastore
- 模拟包含有登录和注销页面的Google帐号，登录参数可以是任何邮件地址。
- 通过提取你计算机的URL模拟URL fetch服务
- 使用你选择的SMTP服务器或Sendmail配置模拟邮件服务
乍一看，绝大多数的应用配置似乎可用YAML来写。
动机和竞争
Google的公告称他们的动机是，简化Web应用的构建、部署和伸缩性：
嗯，我们构建Web应用是因为我们想要更多的Web应用被创建出来。我们注意到，目前创建一个Web应用真的很难：即使部署一个最简单的Web应用也有巨大的前端挑战。你需要做很多事情。当然，首先你必须为你的应用编写代码。
但是接着，你还需书写你的Apache Web服务器配置和启动脚本，安装你的数据库，创建所有表和设置口令，安装监视器来了解你的流量和日志，决定你如何推出代码的新版本等等。
那只是我们注意到的技术方面的挑战。然后，一旦你完成了所有那些系统管理员的工作，你就有了另一个挑战：你必须着手去找你能使用的机器来运行你的应用，不论是物理的还是虚拟的提供商。现在，就要花钱了：即使是最简单的应用，一周用几次，你都必须支付一大笔预支费用来让它在一个传统主机托管提供商处运行。
那么，这就是财务或物理方面的挑战。然后，一旦你搞定了整件事情并且运行了，而且找到地方并为此付费来测试它，你又面临了另一个挑战：随着你应用的成长，你必须去维护它。你的机器崩溃了，你的配置有错误，你的硬盘坏了，你的流量开始增长，你必须重新分享你的数据库，安装更多更多的机器。随着应用的成长，任何事情都象是一场激战。
所有这些激战正是我们试图通过App Engine避免的。它们是我们正试图解决的问题。
其他人已经揣测出了言外之意。很多人指出了Google与Amazon和微软在未来云计算和Web服务方面的竞争，常常将App Engine与Amazon的Web服务EC2、S3、SQS和SimpleDB相提并论：
-
自从Amazon Web服务有这么好的开局之后，我们都知道这只不过是时间问题（我们可以有把握地假定下一个将会是微软）。尽管拿AWS与GAE作对比是显而易见的，但是它们真的不是同一类工具。Amazon已发布的一组独立服务可以被用来创建一个通用的计算平台。尽管这些服务可以一起工作，但是它们没有作为整体打包在一起。
另一方面，App Engine是一个驱动Web应用的引擎。它将AWS提供的许多特性进行了整体打包：存储类似S3、自动伸缩性和处理能力类似EC2，Datastore类似SimpleDB。App Engine还提供了AWS没有的特性，如Python运行时，Google特定的API，以及可能是最吸引人的免费服务部分。
-
VentureBeat：“Google App Engine准备与Amazon竞争”
其他人暗示微软也正携一些工具向这个方向挺进，比如Ray Ozzie's Mesh strategy和SQL Server Data Services，但是可能已经太晚了：
- Network world 说，“Google再次领先微软”
- ZDNet问：“Google App Engine：微软将何时围捕竞争者？”
看看事情的另一角度，某些人暗示这会使Google在收购方面棋高一着，这是一种风险基础设施（venture infrastructure）形式：
- Business Week认为Google和Amazon间的竞争没有提及这一点：鼓励创业公司在Google的基础设施上开发他们的应用，这使Google“不仅可以很好地了解人们想要的应用和需要克服的问题，而且能敏锐地发现Google想收购的有前途的新创业公司”。
- ZDNet补充：它可以节约Google在收购方面的金钱：“想象一下，如果收购一家已经使用Google技术的公司会省下多少时间和努力？”
- GigaOM说：“这种亏本销售的服务将那些创业公司带进了Google的大门，这使得这家公司可以访问最新的想法并可从天才企业家池中做出选择”
-
在“Google如何吃掉Amazon的午餐”中，Kevin Kelleher称这为投资：
在这次采访中，我大声地推测Amazon所做事情很像公司风险投资的（如Intel投资部）做法——投资和他们以后要合作（或者要收购）的创业公司。只是不用硬通货，而是基础设施。我得说，非常精明。
高管的反应是：Amazon根本没这么做，而且永远不会用Web服务那么做。我心里想了一下，但是没说：嗯，如果你们不这样做，有人会这么做的。
现在，有些人正在说Google正在这么做。随着有价值的Google员工整理他们的桌子并启动一家新的创业公司，推出GAE是Google将他们重新召回的最好策略。这也是从Amazon身下抽走地毯的绝佳方法，战略上明智而且盈利上也明智。
反馈、分析和资源
- 遍布网上和博客的其他分析：
- Jaiku，a Google新近收购的公司，宣布它将移植到App Engine。
- TechCrunch
- news.com
- Farhan Mashraqi说：这大大推进了Python语言，和blist所做的一样。
- fuzzmeister在Digg上的评论暗示这会有重大影响，“这会演变成对Web站点托管和运行方式有根本性改变的事情”
- Wayne Pan认为‘免费’角度是最大的新闻，App Engine要真正吸引人需要支持其他语言和外部服务模型。
- Nate Koechley指出Guido Van Rossum是GAE团队成员之一。
- FaceReviews指出Robert Scoble在公告发布之后与Pownce进行了交谈，他们觉得没有什么特别的。
- Adnans记录了一些API相关的笔记。
- Technosailor说他没看出有什么新意，既没有创新，也不令人感到震撼。他是个怀疑论者。
- 以下论坛已经就App Engine开始了一些讨论：
- 预了解更多关于Google App Engine的信息：
- 访问Google Code上的Google App Engine站点。
- 观看YouTube上的视频。
- 参与官方论坛的讨论。
- 访问官方博客
- 研究application gallery或Jaiku上的一些App Engine应用。
- 阅读google代码知识库上的FAQ。
- 阅读一些关于App Engine的文章，包括
查看英文原文：Google 'simplifies web development' with AppEngine
相关厂商内容
一个实现，提供代码
发表人
yong nie
发表于
2008年4月14日 下午7时26分
Re: 一个实现，提供代码
发表人
Allen Long
发表于
2008年4月15日 下午11时1分
词典应用
发表人
aruhan qian
发表于
2008年6月10日 下午9时25分
利用Google Appengine 开发的在线代理
发表人
Shilai Lin
发表于
2009年1月30日 上午2时10分
-
佩服yong nie的学习能力，动作如此之快.
-
quick-proxy.appspot.com/
这是基于Google AppEngine平台开发的一款在线代理网站(Web Proxy)。由于使用Google的服务器，实测速度很快。访问Wiki，Feedburner什么的都完全没问题，速度一流。
(ps：被GFW拦截的网站基本上都可以访问)
使用方法有两种：
1.打开quick-proxy.appspot.com/，在url框输入地址。
2.直接把地址加在quick-proxy.appspot.com/后面，如http://quick-proxy....
4 条回复
关注此讨论 回复