BlazeDS
简介
BlazeDS是一个基于服务器的Java远程调用（remoting）和Web消息传递（messaging）技术，使得后台的Java应用程序和运行在浏览器上的Flex应用程序能够相互通信。
如果你想通过使用RPC Services提供一些企业级功能，如不同域之间数据交换的代理功能、客户端认证、服务器端日志、本地化支持、RPC Services服务集中化管理等功能时，BlazeDS通过使用RemoteObject控件可以轻松实现，而不需要配置他们像SOAP-compliant网络服务。
当客户端RPC控件调用远程服务时，该控件就会把服务端返回的数据保存在一个ActionScript对象中，这样，在程序中就能够很轻松的获取想要的数据，而这些客户端控件包括HTTPService、WebService、RemoteObject控件。
Messaging Services（消息服务）
消息服务就是通过服务器端来回的传送消息以实现客户端的异步交流，一条消息由唯一标识号、BlazeDS头、其他自定义头和消息体组成。
客户端程序中发送消息的部分称为消息生产者（producers)，在Flex程序中可以通过Producer控件定义，而接收消息的部分称为消息消费者（consumer），在Flex中可以通过Consumer控件定义，Consumer控件负责订阅和接收服务器端某一个目的地的消息，而Producer控件负责向该目的地发送消息。
消息服务同时也支持通过JMSAdapter实现的桥接模式来访问外部的JMS服务器，这使得Flex程序能够与外部的Java应用程序实现数据交流。
Service adapters(服务适配器)
BlazeDS可以访问各种不同的数据持久化方案，比如数据库、JMS等其他持久化机制。The message-based framework（基于消息的框架） BlazeDS在客户端和服务器端来回的传送数据，他是一个基于消息的框架，主要运用了两种交换模式，第一种，请求/响应模式，客户端发送请求给服务端，服务端处理好之后返回一个包含结果的响应，RPC服务就是使用的这种模式；第二种，发布/订阅模式，服务端将数据发布给订阅了该消息的客户端列表，消息服务就是使用这种模式来发布数据给各客户端的，同时，消息服务也使用请求/响应模式来解决一些发布消息、数据交换等问题。
Channels and endpoints（通道和端点）
在网络上，客户端是通过通道与服务端传送数据的，通道负责封装消息格式、网络协议、解析方式、目的和应用代码，负责格式化和翻译消息为特定网络下的模式，然后分发给相应的端点。另外，通道使得客户端发送给服务端的消息变得有序性和对应性，这对数据传送的一致性和可预见性起到重要的作用。
在服务器端，通道是与基于Java的端点发生交换的，端点负责解析消息成特定的协议模式，然后把它传送给普通Java形式的“消息代理人”（Message Broker），最终由消息代理人决定该消息发往何处，路由给恰当的目的地，
Channel types（通道类型）
BlazeDS提供以下几种通道：
（1）标准AMF通道；
（2）加密AMF通道；
（3）HTTP通道（AMFX）。
其中AMF和HTTP通道都支持无轮询的请求/响应模式和客户端轮询模式（模拟实时通信），而AMF和HTTP流通道模式提供了真正的数据流实时模式。
AMF（Action Message Format）是ActionScript对象序列化后的二进制流。用于Adobe Flash应用和远端服务的通讯。由于它是基于二进制的数据传输，所以相对于XML SOAP，json，WebService等基于字符串的数据格式，有数据体积小和效率高的特点。
blazeDS是一套面向actionscript的前后台通信框架。
在服务器端，blazeDS以servlet的方式存在于java应用服务器上。它默认提供3中服务，远程调用（在remoting-config.xml中配置）、访问代理（proxy-config.xml）、消息服务（messaging-config.xml），同时框架允许你添加自定义的服务（在services-config.xml中配置）。
在客户端，blazeDS提供了RemoteObject、HttpServcie、WebService，Product和Comsumer等组件来提供访问服务器端数据的能力，其中RemoteObject、Product和Comsumer是以amf协议来交换数据的，而HttpServcie和WebService则采用的是比较通用的访问协议，可以用来访问非blazeDS服务器（即普通的web服务器）。
那么服务端和客户端如何关联起来呢？答案是通过destination和channel、endpoint。
首先要在服务器端定义需要的destination,根据destination所属的service类别不同，应该把destination定义在不同的配置文件里（remoting-config.xml或proxy-config.xml或messaging-config.xml）。同时为destination指定channel（如果不指定，就会使用默认的channel）。
在客户端的代码中只需要为你的组件（比如RemoteObject）指定destination和取得数据后的回调函数就行了，剩下来的就是编译器的事情了。Flex为你隐藏了channel的调用。所以你需要写的代码很少。
服务端的结构图如下：
客户端的结构图如下：
如果做个helloworld的例子，网上很多，blazeDS自带的examples也很典型。这里就不累诉了。相信有一定经验的初学者都能很快上手。需要强调的是，blazseDS客户端工程的特殊之处是它的编译依赖于服务端程序的4个配置文件，就是之前其提过的services-config.xml 、remoting-config.xml、proxy-config.xml、messaging-config.xml（都位于服务端工程的WEB-INF\flex目录下），同时编译参数Context
Root必须设置正确。编译错了，程序再对也出不来结果的，呵呵。
介绍了blazeDS的结构体系，下面来分析下我们能用blazeDS来做什么呢？
这个就要中blazeDS所提供的3种服务来分析了。
1. 远程调用。其实框架在这里起到的作用和struts等服务端的框架差不多，都是任务分配的功能，只不过blazeDS支持客户端直接对象调用，一方面提高了数据传输速度，另一方面省了在客户端写url，但是它需要编译客户端的时候关联服务端配置文件，烦！综合考虑优缺点，这个功能还是值得使用的。
2. 访问代理。能够提供权限控制，和跨域访问的能力。这个任何web服务器都能做到（加httpClient转发么），没什么特殊之处。
3. 消息服务。这个正式blazeDS 牛的地方，它能向普通的浏览器客户端页面推送数据，而不需要建立socket链接。这个应用在很多地方都有用到，比如股票信息即时刷新，在线聊天等等需要实时数据推送的场景。
我的想法是，如果是一个全新的完整的flash应用项目，那么用blazeDS的框架是一个不错的选择。如果是要在原有的javaWeb系统上增加功能的话，还是仅仅用一下blazeDS的消息推送服务就可以了，毕竟用flex直接访问http也很方便。