Adobe Flex应用在RPC上的更多选择：AMF、BlazeDS和GraniteDS

作者 Jon Rose 译者 沙晓兰 发布于 2007年12月20日

领域

语言 & 开发,

架构 & 设计,

运维 & 基础架构,

企业架构

主题

许可证 ,

开放源代码 ,

富客户端/桌面 ,

消息传送 ,

架构 ,

RIA ,

Java ,

Ruby

标签

Adobe ,

Apollo ,

Adobe集成运行时/AIR ,

Flex ,

Flash

上周，Adobe宣布对Adobe Flex平台作了大改动，大量的生命周期数据服务（LiveCycle Data Services）在BlazeDS项目中被开源，开源内容还包括AMF的规格说明和代码。对于那些正在考虑采用Flex平台的人来说，这次改动应该清除了最终的成本和许可障碍。

Adobe Flex应用程序部署并运行在Flash Player中，其后台逻辑通过RPC访问，以一种类似于客户/服务器的构架方式。Flex中有很多不同的RPC选项，包括Web Services、HTTP和AMF/Data Services。AMF是一个二进制协议，比传统的RPC方法具有更多的优点。Adobe的James Ward在他的Blog文章“BlazeBench: Why you want AMF and BlazeDS”中着重提到了它在性能和带宽上的优点。

Adobe的Ted Patrick在他的文章“The ABC’s of AMF”中详细描述了AMF的基本概念，并概括列出了下列几个优点：

1. 文件大小 —— AMF对象非常小且使用zlib压缩。

2. 快速序列化/反序列化 —— AMF在player中使用本地C代码转化，因而运行非常之快。AMF格式本身就被设计为在低内存和慢CPU条件下依然能够快速序列化和反序列化。由于AMF数据直接被解析为对象，没有审核解释或解析AMF的延迟，对象的创建可一次完成。

3. 本地类型和自定义类的支持 —— 除了displayObjects，你可以序列化Flash Player中的任何对象。在反序列的时候如果自定义类在Flash Player中，你也可以将先前序列化的对象映射回自定义类实例。

在Adobe宣布AMF和BlazeDS开源之前，开发人员确实也有一些开源工具可选择来使用AMF协议，这些工具由一些团体采用反向工程而得。这些开源项目包括RubyAMF、AMFPHP、SabreAMF、OpenAMF和Granite Data Services（GraniteDS）。拥有一个公开发布的AMF规格说明应该只会帮助改善这些实现。Ruby和PHP项目仍将首选在应用程序中使用这些技术以利用AMF，就如BlazeDS是Java应用程序在远程访问和消息传递方面是首选。

到目前为止，对于Java开发人员来说，GraniteDS是应用AMF协议的首选开源工具。当BlazeDS在周二宣布的时候，GraniteDS的创建者Franck Wolff显得有点手足无措，并对GraniteDS的未来持有怀疑。他通过GraniteDS邮件列表向大家发表了他对于BlazeDS的看法：

大家好：

恩……这是一个好消息（尽管我对此感觉还是有点怪）！

对GDS来说，唯一可能的将来是为BlazeDS遗漏的性能提供一些代码（我主要考虑的是透明外化（transparent externalization）、延迟加载（lazy-loading）的支持、代码生成）……

目前，我想我会停止任何GDS进一步的开发……欢迎大家做自由评论。

此致
Franck

在深思之后，Wolff 确实看到了GraniteDS的未来发展方向。在一个开源项目运作的样例中，他认为有很多新特性可以贡献给BlazeDS项目，或者可以继续独发展GrainteDS项目。

大家好（这是我的一些新的想法）：

1. 一点点历史回顾： GDS创立的起因是由于FDS太过昂贵，而且更重要的是，它并不与众所周知的持久性API（EJB3/Hibernate）集成，也不提供任何延迟加载机制。这也是为什么从最初我就创建了这个透明外化（transparent externalization）的特性（特别是HibernateExternalizer）来进行序列化并保持所有持久的相关bean的域（比如id，version等）私有。后来，为了避免令人厌烦的手工编写可外部化（Externalizable ）AS3 bean的工作，gas3（GDS 代码生成器）应运而生。
2. BlazeDS和GDS的比较：令人感到惊奇的是，从严格的远程访问的观点来看，BlazeDS恰恰是GDS一直以来想要实现的方向：使用RemoteObjects的经典的AMF3远程访问，一个新的基于Comet的信道用于在生产者和消费者之间通过HTTP（非RTMP）交换AMF3对象。另一方面，从持久性的观点来看，BlazeDS不包含任何数据管理的特性，所以GDS可以补充很多非常重要的但BlazeDS缺少的特性：EJB3 持久性和延迟加载的支持。
3. 一点点策略：BlazeDS（LGPL3，含源码）的第一个发布版本预告期为2008年初（没有精确的日期……），对于我们来说最好的策略是尽快发布GDS1.0（在一月底之前），然后共同等待BlazeDS公开他们的源码。再然后，我们或者可以拷贝/粘贴一些BlazeDS的好的代码到GDS（同一个license！）中， 或者将外化＋延迟加载机制＋gas3添加到BlazeDS的特性中去（如果Adobe同意的话），或是甚至将GDS作为BlazeDS的一个插件发布（不知道有没有这个可能性）。非常欢迎发表任何看法！

Cheers,
Franck.

GraniteDS对集成了Java的Flex应用程序确实有一些很优秀的特性和优点。另外，BlazeDS也不仅仅是一个AMF规格说明的实现，它提供了一些GraniteDS没有的特性，如push、消息传递。抛开实现不说，很明显，Adobe向Flex平台开源的迈进，对于Flex开发人员是百益无害。

查看英文原文：More on RPC in Adobe Flex Applications with AMF, BlazeDS, and/or GraniteDS

译者 沙晓兰 目前从事Web应用的开发，有Java和JavaScript开发经验，关注J2EE、Struts 2等技术以及富客户端开发动态。

• 更早的 >