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 的构思是: 1. 通过写 Ejb3 实体 Bean 设计数据库模型。
2. 让 Gas3 生成复制了实体 Bean 属性的 ActionsScript3 Beans(即 Flex 客户端模型 Beans),而且有 Hibernate 工具生成数据库模式(表和索引的创建)。
3. 用会话 Bean、Spring、Guice 或 Pojo 服务写业务逻辑。
4. 写 Flex 应用(mxml)。另外,你可以写自己的 Gas3 代码生成模板,还能完全自定义生成的 ActionScript3 类。
InfoQ 让 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 的代码生成功能,它们能实时保存。
InfoQ 向 Wolff 询问了 GDS 与 BlazeDS 项目合并的可能性:
我还没有和 Adobe 讨论过这个问题。我猜测 Adobe 还是想保持 BlazeDS 和 LCDS 之间清晰的功能分离(在 BlazeDS 中没有数据管理)。另一方面,GDS 试图给出一个提供缺少功能的替代实现,它基于众所周知的、广泛采用的 Java EE 技术。目前我唯一可以说的就是,如果 Adobe 想在 BlazeDS 中添加 GDS 的一些或全部特定功能,我一定认为合并是一个合适的选择。但是在这种情况下,对我们来说(我猜还有很多 GDS 用户),问题是要得到一些保证,保证未来的 BlazeDS 开发能满足我们的需求。
采访结束时,Wolff 对开源社区表示了感谢:
我想再次感谢那些来自开源社区的人们对 GDS 做出的伟大贡献。
在网站 http://www.graniteds.org/ 上了解更多关于 GDS 的信息。
查看英文原文: Granite Data Services: Open Source Flex DS Alternative
评论