blazeds学习笔记一整体认识

BlazeDS 是一组服务器端的通讯服务，它能够使得运行在浏览器的 Adobe Flex 应用程序服与服务器端的 Java 应用程序相互通信。

整个体系主要包括通道、端点、消息、服务、目的地、适配器 等， 把这 些搞懂也就差不多了。通道使得组 件能够 和Blazeds 服务端的端点通信，将请求送到目的地 。端点和通道是相互映射的 。

• 基于消息的框架

         Blazeds 使用基于消息的框架在客户端和服务端之 间发送和返回数据。

         Blazeds 在它们之间使用了两个交换模式。第一个模式是请求 — 响应模式，客户端发送请求给服务端处理。服务端返回处理结果给客户端。 RPC Service 就是使用这个模式。
        第二个模式是发布—订阅模式，即服务端发布消息设置，客户端订阅了去接收它 们。 Messaging Service 使用这个模式将数据推给“感兴趣“的客户端。

• Blazeds 特征

• 

 

如图， BlazeDS 提供了三种关键的服务。

        Remoting Service 。提供一种客户端直接调用服务器端 java 方法的方式。

        Message Service 。提供一种基于发布 / 订阅模式的消息服务，可以用于实现实时的数据推送或协作的 flex 应用。

          Proxy Service。 通过 proxy service ，使得 flex 应用可以实现安全的，受限的跨域访问， 也 就是说它让您的 Flex 应用程序访问的服务可以处于不同的 域，而不需要在目标域里配置 crossdomain.xml 权 限文件。

• Blazeds 客户端结构

BlazeDS 客户端使用 BlazeDS 提供的基于消息的框架与服务器通讯。消息框架的客户端部分是 Channels ， Channels 封装了 flex 客户端与 BlazeDS 服务器的连接。

下 图是 BlazeDS 客户端的结构图

 

 

     Flex 通讯组件

        Flex 提供了 RemoteObject ， HTTPService ， WebService ， Producer ， Consumer

        等可以与 BlazeDS 通讯的组件，这些组件都包含在了 Flex SDK 中，是 Flex 组件库的一部分。

    Channels Set

          Channels 封装了 Flex 组件与 BlazeDS 服务之间的连接，是处于 Flex 组件之下的一个通讯层。

          BlazeDS 提供了 AMFChannel 和 HTTPChannel 。 Flex 客户端可以使用不同类型的 Channel 与 服务器通讯。

          Channel 是在 services-config.xml 中配置，下面是一个 AMFChannel 的配置：

               <channels>

                      …

                     <channel-definition id=”samples-amf”  type=”mx.messaging.channels.AMFChannel”>

                           <endpoint url=”http://localhost:8400/myapp/messagebroker/amf”   type=”flex.messaging.endpoints.AMFEndpoint”/>

                       </channel-definition>

               </channels>

     amf 协议 。 Amt 全称是 action message format ，它是一种二进制格式，专用于 as 和服务 器端通讯，比 http 通讯要快很多，支持多种数据类型，如 java ， .net,php 等。

• Blazeds 服务器端结构

          BlazeDS 服务是一个 J2EE 的 web 容器， Flex 客户端通过 channel 发送一个请求，请求在 BlazeDS 服务端会到达一个 endpoint ，从 endpoint 开始，请求会通过一条 Java 对象处理链，包括： MessageBroker, service, destination, adapter ，结构如下：

 

  MessageBroker

     MessageBroker 负责转发消息到 service ，接收到消息时， MessageBroker 查看消息消息的 destination ，并把消息转发给目标 service 。如果 destination 有安全限制保护，在转发之前， MessageBroker 会执行身份认证和授权检查。            M essageBroker 的配置在 BlazeDS 应用的 WEB-INF/flex/services-config.xml 文件中

  Services 和 destinations

     Services 和 destinations 在 BlazeDS 服务中，是消息处理链的下一环节。

     BlazeDS 包括四种一一对应的 services 和 destinations:

          RemotingService 和 RemotingDestination

          HTPProxyService 和 HTTPProxyDestination

           MessageService 和 MessageDestination

     不同的 Flex 组件的请求是由不同的 Services 和 destinations 进行 处理的，对应关系如下：

          HTTPService 和 WebService 与 HTTPProxyService/HTTPProxyDestination

          RemoteObject 和 RemotingService/RemotingDestination

          Producer /Consumerhe 和 MessageService/MessageDestination

      services 和 destinations 可以在 services-config.xml 配置 , 但是最好的做法是分别在下面的文件中进行配置：

          RemotingService 在 remoting-config.xml 中配置

          HTTPProxyService 在 the proxy-config.xml 中配置

          MessageService 在 messaging-config.xml 中配置

  Adapters

当 一个消息到达正确的 destination 时， destination 会把消息发到相应的一个 Adapter 。 Destination 与 Adapter 的对应关系如下：

     RemotingDestination 使用 JavaAdapter

     HTTPProxyDestination 使用 HTTPProxyAdapter 或 SOAPAdapter

     MessageDestination 使用 ActionScriptAdapter 或 JMSAdapter

• 开始 Blazeds

•    下载 Blazeds http://www.alisdn.com/wordpress/?paged=2

•    解压到 tomcat 的 webapps 目录下

•    启动 tomcat

•    访问 http://127.0.0.1:8080/ds-console/

• 开发 Blazeds 应用

加入 blazeds/WEB-INF/lib/ 下的 jar 包

复制 blazeds/WEB-INF/flex 下的文件到项目的 WEB-INF/flex 目录下，包括：

        messaging-config.xml

        proxy-config.xml

        remoting-config.xml

        services-config.xml

在 web.xml 文件中定义 MessageBrokerServlet 和 session listener

选择端点

 

BlazeDS 提供了下列基于servlet 的 通道、端点组合。使用 安全协议 HTTPS 向 AMF 端点发送消息 安全的通道和端点都以“Secure ”开头；比 如，SecureAMFChannel 和SecureAMFEndpoint

 

 

      

	描述
AMFChannel/AMFEndpoint	一对简单的通道/ 端点组合，基于HTTP 协议，以异步请求、响应的模式 通过二进制AMF 格式传输数据。也可以配置一个通道，专门通过这个端点来轮询新消息。你可以为轮 询 配置一个较长的等待间隔，实现类似实时通讯。
HTTPChannel/HTTPEndpoint	提供同样的通道/ 端点行为，但是是通过XML 代替AMF 传输数据，称为AMFX 格式化。它的速度没有AMFEndpoint 快。
StreamingAMFChannel/StreamingAMFEndpoint	基于HTTP 协议实时传递二进制格式数据流。在实时数据服务，例如消息服务的时候使用，因为数据流对性能来说是决定 性的。
StreamingHTTPChannel/StreamingHTTPEndpoint	和streaming AMF 通道/ 端点提供同样的行 为，但是是用XML 代替AMF 实现数据传 输。它没有streaming AMF 快。

 

 

       AMF 和 HTTP 通道都支持无轮询的请求 / 响应模式和客户端轮询模式（模拟实时通信），而 AMF 和 HTTP 流通道模式提供了真正的数据流实时模式

 

选择通道

 

   基于你的应用需求，你可以选择简单AMF 、HTTP 通道以及基于非轮询、搭载式、轮询或者 长轮询模式。当然你也可以选择streaming AMF 、HTTP 通 道。

 

    AMF 和HTTP 通道的最大不同就是前者基于二进制的AMF 格式传输数据，而后者则是XML 格式(AMFX) 。因为AMF 通道比HTTP 通道性能要好，所以只有当你的应用有特殊需求的时候才适合使用HTTP 通 道( 事先已经知道二进制格式不能在你的应用网络中传输或者想让数据在防火墙上更好理解) 。

 

       下面分别讲一下前面提到的几种模式：

 

1)         无轮询 AMF 、 HTTP 通道

 

你可以使用这些通道无轮询的方式来提供 RPC 服务，比如远程服务调用、代理 HTTP 服务调用以及 Web service 请求。这些方案不要求客户端轮询信息或者服务端将消息 “推”给客户端。

 

              <!-- Simple AMF -->

<channel-definition id="samples-amf"

type="mx.messaging.channels.AMFChannel">

 

<endpoint url="http://{server.name}:8400/myapp/messagebroker/amf"

type="flex.messaging.endpoints.AmfEndpoint"/>

 

</channel-definition>

 

<!-- Simple secure AMF -->

<channel-definition id="my-secure-amf"

class="mx.messaging.channels.SecureAMFChannel">

 

<endpoint url="https://{server.name}:9100/dev/messagebroker/

amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>

 

</channel-definition>

 

<!-- Simple HTTP -->

<channel-definition id="my-http"

class="mx.messaging.channels.HTTPChannel">

 

<endpoint url="http://{server.name}:8400/dev/messagebroker/http"

class="flex.messaging.endpoints.HTTPEndpoint"/>

 

</channel-definition>

 

 

<!-- Simple secure HTTP -->

<channel-definition id="my-secure-http" class="mx.messaging.channels.SecureHTTPChannel">

 

<endpoint url=

"https://{server.name}:9100/dev/messagebroker/

httpsecure"

class="flex.messaging.endpoints.SecureHTTPEndpoint"/>

 

 

</channel-definition>

 

 

 

2)         搭载 式 AMF 、 HTTP 通道

 

搭载 式确保独立于客户端发送信息到服务端或者服务端响应消息到客户端的数据传输。 搭载 式提供了轻量级的假轮询：一种比固定或者适当时间间隔轮 询服务端更好的方式， s 特别是 当客户端发送一个非命令消息 到服务器（使用一个生产者或 RemoteObject 对象）时，服务器发送任何未确定的数据到客户 端或数据管理订阅随着客户端的信息响应。

 

也可以在一个需要确保轮询，但是间隔却比较长，例如 5 秒或者 10 秒甚至更多的通道中使用， 在这种情况下，应用程序似乎更加敏感 。这种模式下，客户端的轮询请求独立于任何其他消息发送给服务端

 

 

3)         轮询 AMF 、 HTTP 通道

 

AMF 、 HTTP 通道提供了简单的轮询机制，客户端可以用这个机制定期 发送请求消息到服务端。当长期轮询或者流通道不能使用时，或者作为一个流通道的备用通道时候，轮询 AMF 、 HTTP 通道是适用的。

 

<!-- AMF with polling -->

<channel-definition id="samples-polling-amf"

type="mx.messaging.channels.AMFChannel">

 

<endpoint url="http://{server.name}:8700/dev/messagebroker/amfpolling"

type="flex.messaging.endpoints.AMFEndpoint"/>

 

<properties>

<polling-enabled>true</polling-enabled>

<polling-interval-seconds>8</polling-interval-seconds>

</properties>

 

</channel-definition>

 

<!-- HTTP with polling -->

<channel-definition id="samples-polling-http"

type="mx.messaging.channels.HTTPChannel">

 

<endpoint url="http://{server.name}:8700/dev/messagebroker/httppolling"

type="flex.messaging.endpoints.HTTPEndpoint"/>

 

<properties>

<polling-enabled>true</polling-enabled>

<polling-interval-seconds>8</polling-interval-seconds>

</properties>

 

</channel-definition>

 

              注意：这种模式中你也可以使用 secure 通道。

 

 

4)         长轮询 AMF 、 HTTP 通道

当其他更加有效率的实时机制不合适的时候，你可以使用AMF 和HTTP 通道的长期轮询模式来“推”消息到客 户端。 This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures. 这 一机制的使用标准应用服务器的HTTP 请求处理逻辑，并与典型的J2EE 架构协同工作。

You can establish long polling for any channel that uses a non-streaming AMF or HTTP endpoint by setting the polling-enabled , polling-interval-millis , wait-interval-millis , and client-wait-interval-millis properties in a channel definition; for more information, see Simple channels and endpoints . 您可以为任何通道建立长期轮询来使用相应端点，需要设置一下参数：polling-enabled 、polling-interval-millis 、wait-interval-millis 、client-w ait-interval-mills 。有关wait-interval-millis 的 更多内容请参考Blazeds 文档。

<!-- Long polling AMF -->

<channel-definition id="my-amf-longpoll" class="mx.messaging.channels.AMFChannel">

 

<endpoint

url="http:// servername : 8700 / contextroot /messagebroker/myamflongpoll"

class="flex.messaging.endpoints.AMFEndpoint"/>

 

<properties>

<polling-enabled>true</polling-enabled>

<polling-interval-seconds>0</polling-interval-seconds>

<wait-interval-millis>60000</wait-interval-millis>

<client-wait-interval-millis>3000</client-wait-interval-millis>

<max-waiting-poll-requests>100</max-waiting-poll-requests>

</properties>

 

</channel-definition>