Granite数据服务：Flex DS的开源替代品

　　Granite数据服务(Granite Data Services，GDS)是Adobe生命周期数据服务（LiveCycle Data Services）和最近开源的BlazeDS（Blaze Data Services）的一个开源替代品。上周，GDS产品发布了1.0版本，它采用LGPL许可方式。InfoQ.com与GDS项目的创建者Franck Wolff进行了沟通，以了解更多关于该开源项目的信息。

　　Wolff为InfoQ.com的读者提供了GDS的概述：GDS是Adobe生命周期数据服务（LiveCycle Data Services）的一个替代品，特别强调与JEE技术的整合，包括众所周知的Java EE持久化系统（比如Ejb3/Hibernate，完全支持懒加载[lazy-loading]）。GDS可以让你使用标准的Flex 2及其以上版本的RemoteObjects，它们提供了来自AMF3序列化的全部优点。
　　
　　此外，GDS也为许多技术提供支持：

　　与流行Web框架服务的互操作性

　　调用服务器端的Ejb3会话Bean（无论是否使用JBoss Seam扩展）

　　带有Acegi安全的Spring Beans
　　
　　Google Guice服务（加上Warp持久化）

　　支持POJP服务

　　支持数据推（Data Push）是GDS 1.0的一个新功能。此外，GDS还提供了一个ActionScript3代码生成器（Gas3），它大大加速了Flex应用的开发。GDS和Flex Builder IDE、或者免费的Flex SDK一起，可以为开发人员提供一个完整而强大的Flex应用开发、部署框架。

　　关于项目现状：

　　GDS过去比较重要的部分（Ejb3、Spring、Pojo和Gas3）已经被广泛采用，而且生产就绪，这就是我们为什么能直接从0.4跳到1.0版本。目前引进到GDS 1.0中的新功能（Seam、Guice服务、数据推（Data Push））应该会在beta版软件中考虑到。

　　GDS正由Adequate Systems的两个开发人员（William Draï和我自己）积极开发。此外，由于GDS一年前就公开推出（见GDS文档），所以还有许多来自开源社区的其他人也在为GDS的开发做出贡献。GDS确定会成为将来基于Flex的解决方案架构的服务器端核心。

　　关于GDS线路图和RIA架构，Wolff表示：

　　目前，我们正努力开发一个确保唯一性（每个实体在Flash VM中只存在一个实例）的客户端实体仓库。这个仓库的一个重要功能是当懒关联在Flex端被请求的时候，它们要透明地初始化。某种程度而言，这个功能受到了Cairngorm的启示。

　　线路图中另一个重要的发展是改进GDS和JBoss Seam的集成。我认为随着RIA新的发展，从架构的角度来看，我们所面临的风险是又回到了15年前客户端/服务器模式（client/server paradigm）占主导地位的状态。这一趋势能带来与无状态服务器相互作用的有状态客户端（例如简单的数据库前端程序）。尽管这个架构对小型Flex应用可能是可行的，但我觉得对大型应用来说，这并不是最好的选择。我想在GDS中继续致力于有状态服务器组件的设想，比如说，就像由Seam对话和任务的设想所定义的一样。

　　最终的目标是在Flex端建立一个完整的数据管理系统，带有自动表单创建（实体编辑面板）和验证（它在客户端复制Hibernate验证注释）。
Wolff与读者继续分享了GDS中数据推（Data Push）的更多细节：

　　GDS中的数据推（命名为Gravity）被实现为一种带有通过HTTP发送的AMF3消息、类Comet技术的服务（没有RTMP、没有特定的因特网 端口），并免费基于Bayeux协议。这种实现对Tomcat 6.0.14及其以上版本、JBoss 4.2.2及其以上版本、Jetty Continuations 6.1.15及其以上版本是可用的。就像Flex文档中描述的一样，Gravity还提供了对JMS适配器的支持。

　　在客户端代码中，我们不能使用标准的mx.messaging.Consumer和mx.messaging.Producer，因为Consumer类已经从Flex 3 SDK中移除了。所以，我们要实现我们自己的、带有相同属性和方法的ActionScript类Consumer/Producer，不过有一个区别：属性“subtopic”已改名为“topic”（是为了确保Flex 2和Flex 3之间的兼容性）。我们还创建了一个特殊的信道（org.granite.gravity.channels.GravityChannel），必须为了数据推目的地（data push destinations）而在services-config.xml文件中使用它。简而言之，这个信道封装了两个flash.net.URLStream实例（指令和通道），并支持长轮询（long-polling）传输。

　　如果你目前正在使用mx.messaging包中的类，你只需要做几个修改即可：

　　将所有的“mx.messaging.Consumer”imports重命名为“org.granite.gravity.Consumer”（Producer类也一样）。
　　将所有的“subtopic”重命名为“topic”。
　　修改services-config.xml中的信道定义。

　　Wolff还解释说明了一下Gas3的特点：

　　Gas3的构思是：

　　通过写Ejb3实体Bean设计数据库模型。
　　让Gas3生成复制了实体Bean属性的ActionsScript3 Beans（即Flex客户端模型Beans），而且有Hibernate工具生成数据库模式（表和索引的创建）。
　　用会话Bean、Spring、Guice或Pojo服务写业务逻辑。
　　写Flex应用（mxml）。

　　另外，你可以写自己的Gas3代码生成模板，还能完全自定义生成的ActionScript3类。

　　记者让Wolff比较一下GDS和BlazeDS：BlazeDS主要是LCDS的一个子集，它不直接提供任何数据管理功能（参见这张图片）。GDS的设计是为了提供与EJB3持久化层的完全整合，并带来一个非常重要而独特的特征（LCDS似乎并不提供）：当使用像Hibernate一样的对象/关系持久化工具时，如果你不使用任何懒抓取策略，你可能会面临加载整个数据库的风险。GDS既支持代理（单值关联关系），也为集合支持懒抓取。

　　此功能基于另一种独特的序列化特点：外部化（Externalizers）。使用标准的Flex AMF3序列化（BlazeDS或LCDS），只有非临时、非静态的公有属性才能被序列化。你不能序列化和持有ActionScript3 Bean中的私有属性，它们应该保留为私有（例如版本号等）。使用BlazeDS或LCDS实现这个目标的唯一方法是把你的实体Bean写成外部化（Externalizable）（但是你必须同时在Java端和AS3端实现稳定的readExternal/writeExternal方法，参见这里）。这是非常繁琐的工作，而且许多源码有潜在的、难以发现的错误（如果你没有实体Bean的源码，它甚至是不可能实现的）。使用GDS外部化，你不用把你的Java Bean写成外部化，你还能让Gas3来生成你的AS3 Bean（强类型的，带有保持私有的私有属性和懒加载支持）。

　　BlazeDS文档说BlazeDS有一个“开放适配器架构”，能让你“轻松地集成JMS、EJBs、ColdFusion组件，以及其它数据源”。从这个角度来看，由于GDS也基于一个“开放适配器架构”，所以GraniteDS和BlazeDS并没有很大的不同。开发人员已经编写了Spring、Seam、Guice服务适配器等。GDS还允许你自定义很多其它的东西，包括控制序列化过程的每个部分、支持特殊类型。

　　令人惊讶的是，BlazeDS和GDS的数据推实现都基于相同的类Comet架构类型。2007年夏季，GDS在其网站上宣布了这一实现选择，比任何BlazeDS的宣布都要早很多。因此，除了GDS对Jetty有特别的支持（据我所知，BlazeDS只支持Tomcat）外，数据推的实现可能是非常相似的（BlazeDS的源码还不可获得）。

　　Wolff提供了一个例子，说明在何处使用GDS会比使用BlazeDS有意义：如果你是一个使用像Hibernate一样的Java EE持久化技术的软件供应商，你一定会感到支持懒抓取策略的框架的重要性。GDS最重要的特点之一（也是GDS被创建的主要原因之一）就是可能会在客户端使用与Hibernate脫管对象（detached object）一模一样的ActionScript3拷贝，就如同你在一个规范的Java EE应用的Web层一样。使用BlazeDS的话，这似乎是根本不可能的，这意味着你不能用BlazeDS替代GDS。此外，你还可以使用Gas3的代码生成功能，它们能实时保存。

　　记者向Wolff询问了GDS与BlazeDS项目合并的可能性：

　　我还没有和Adobe讨论过这个问题。我猜测Adobe还是想保持BlazeDS和LCDS之间清晰的功能分离（在BlazeDS中没有数据管理）。另一方面，GDS试图给出一个提供缺少功能的替代实现，它基于众所周知的、广泛采用的Java EE技术。目前我唯一可以说的就是，如果Adobe想在BlazeDS中添加GDS的一些或全部特定功能，我一定认为合并是一个合适的选择。但是在这种情况下，对我们来说（我猜还有很多GDS用户），问题是要得到一些保证，保证未来的BlazeDS开发能满足我们的需求。

　　采访结束时，Wolff对开源社区表示了感谢：我想再次感谢那些来自开源社区的人们对GDS做出的伟大贡献。
http://misuland.com/HTML/1204078477366.html