BlazeDS知识积累

BlazeDS是一个基于消息的框架。主要运用了两种模式：请求响应模式、发布/订阅模式。

BlazeDS提供以下几种通道：

　　（1）标准AMF通道；

　　（2）加密AMF通道；

　　（3）HTTP通道（AMFX）。

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

AMF协议时基于Http协议的。

 

httpService的工作方式主要是通过请求URL获取xml格式数据。

WebService返回soap格式的调用结果。也是通过请求URL来进行的。SOAP也是基于XML格式规范。

BlazeDS是adobe专门为RemoteObject而开发的第三方软件。采用的是AMF(Action Message Format)二进制数据格式进行传输。

 

RemoteObject传输的是对象。 而httpService和WebService是基于Xml传输。

 

BlazeDS的远程访问技术使用调用-响应模型。使Flex和Adobe Flash应用访问服务器端Java对象如同访问本地对象一样。它可以整合存在于服务器的java安全策略，并提供在ActionScript和Java数据类型之间透明的数据转换与传输服务。

 

MessageBroker 
         MessageBroker是为了将消息路由给服务端，是Blazeds在服务端的核心。在端点经过初步的处理请求并且将提炼出来的消息传递给MessageBroker。MessageBroker查看消息的目的地，然后将他传递过去。如果目的地有安全现在，他就在传递之前运行检查证明。

 

HttpService组件虽然可以不通过BlazeDS而直接访问位于服务器端的URL, 但是这样就无法获得BlazeDS提供的跨域访问、集中式的安全控制和日志等服务。

 

 

消息服务：

       消息(Messaging)服务允许多个客户端通过它发布、订阅消息或进行点对点的消息通信。

使用消息服务可以构建准实时通信或者多点数据同步的系统。

       Flex应用程序使用客户端消息API发送消息到定义在BlazeDS服务器中destination,并从它接收消息。消息在Channel中传输,在Endpoint中处理。BlazeDS亦可以将消息推送到连接至它的客户端， 此时BlazeDS使用destination广播消息，所有订阅此destination的Flex应用程序都可以收到消息。

       BlazeDS的消息服务还可以借助一个JMSAdapter支持嵌入或外部的JMS服务，使用JMS服务的主题(topic)和队列(queue).

 

 

BlazeDS的大致运行流程：

       在客户端，由Flex RPC或Message组件发起会话请求，由Channel将参数或命令使用指定的网络协议(HTTP或HTTPS)与服务器端进行会话；在服务器端，由一个Servlet统一接收所有Channel的请求，然后根据Channel请求的URL将请求分发给相应的Endpoint,最终将请求转换成适配器(Adaptere)的源----即客户端组件能识别的命令，这些客户端组件可能是java Object、 web页面、 web service或JMS组件等。通过定义Adapter，可以支持更多的客户组件。

 

 

Operation 代表了远程服务中的单个方法。

AsyncRequest: 它允许对远程Destination进行多个请求，并在服务器处理完请求后回调请求者。它是一个Producer,即消息的生产者，即可以通过Channel将消息传输到服务器端。

 

Consumer的两种接收消息方法：主动接收和被动通知。如果使用实时或轮询Channel,那么一旦有新消息，Consumer会接收到acknowledge事件通知，否则需要调用Consumer.receive来接收消息。

 

 

MessageBrokerServlet以servlet的形式注册到JavaEEWeb服务器中，它统一接收前端Channel发送的HTTP请求，然后根据请求的URL将消息分发给相对应的Endpoint,在Endpoint对消息处理完毕后将结果写入HTTP响应流。 

 

 

EndPoint就是消息传输的接收器。
Endpoint并不真正处理消息，它将处理过程委托给service,endpoint在接收到消息时会根据消息的destination获得合适的service,然后调用service,serviceMessage方法处理消息。
Destination和Adapter都是service的子组件，service通过消息的destination找到设定的Adapter,并且调用dapter.invoke方法来激活destination代表的客户组件。

 

 

我们知道HTTP连接一般都是短连接，即socket连接，在完成一次请求/相应后马上断开，这种模式虽然提高了服务器的吞吐能力，但是客户端无法及时接收到服务器的消息。PollingChannel则提供了定时轮询服务器的能力。

 

 

重大发现：

<destination id="chat-room-service">

                     <properties>

                               <source>flex.samples.runtimeconfig.ChatRoomService</source>

                               <scope>application</scope>

                     </properties>

            </destination>

这里要重点强调scope的含义，加上application表示该类的作用域在整个应用中。在服务启动的时候只初始化一次。  如果不写scope属性的话，则每个客户端对应一个目的地类。

 

 

BlazeDS的序列化机制：

1.     元标记RemoteClass和Transient

RemoteClass 是修饰类的编译期的元标记。以[RemoteClass(alias=””)]的形式定义在ActionScript类前。用于显示映射其修饰的类和远程类。

   Transient则是运行期元标记，修饰类的成员变量，用于表明成员变量时瞬态变量，不参与序列化。

序列化只序列共有的，对于非公开变量或属性、只读属性（只有get访问函数）和静态变量或属性不参与序列化。

 

 

 

别人理解：

BlazeDS 是一个基于服务器的 Java 远程控制 (remoting) 和 Web 消息传递 (messaging) 技术，它能够使得后端的 Java 应用程序和运行在浏览器上的 Adobe Flex 应用程序相互通信。使用Blazeds可以很方便的连接java后台，同时他也提供HttpService、webservice方式，不过在Blazeds中可以通过配置文件中对其进行设置的，这样提高了应用的灵活性。其中最重要的还是RemotingObject技术，他可以直接远程远程调用java后台提供的公共接口，使其效率大大提升，一般是采用HTTPService方式的10倍左右。

MessageBroker 

        MessageBroker 我们称他为信息经纪人，它职责就是把messages 发给到services 就是我们的程序服务，它是BlazeDs在服务器上的核心。endpoint 处理完一个request，也即是把messages 从request抽取出来，然后传给MessageBroker ，然后MessageBroker 就检测这个消息的destination ，接着把它传给它想到的服务目的地。假若我们的服务有安全保护，MessageBroker 要先运行authentication ，authentication 是在信息传递前先做check。你要在你BlazeDS  WEB应用WEB-INF/web.xml 文件中配置你的MessageBroker。

   Endpoints

       BlazeDS 基于servlet的Endpoints（端点）是在J2EE servlet container中的，这就意味着 servlet 为 endpoints操纵着 the I/O and HTTP sessions ，实际上Endpoints被MessageBrokerServlet控制，除了MessageBrokerServlet，我们的 J2EE server还在web.xml文件中注册一个 HTTP session 监听者，以使BlazeDS 有监听的属性，和支持。BlazeDS Flex 客户端用channels （通道）和endpoints通信，在服务器上，channels 和endpoints有一对一的对应关系，也许因为他们两个用的数据格式要一样。比如一个channels 用 AMF消息格式，如AMFChannel格式，必须有一个也用这种格式的endpoints与它配对。同样一个用了AMFX  格式的channels  也要求有一个同样格式的endpoint。你要在你BlazeDS  WEB应用WEB-INF/flex directory的 services-config.xml 文件中配置你的endpoints。

channels

       channels 是客户端的对象，它把FLEX组件和 BlazeDS  server端的勾通封装起来。channels和与之在blaze Server上对应的endpoint通信。你可以在services-config.xml 文件中配置channel的各个属性和对应的endpoint。

如下channel 定义代码：

 <channels>

   ...

  <channel-definition id="samples-amf"

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

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

</channel-definition>

</channels>

你就创建了一个AMFChannel与服务器端的AMFEndpoint的通信channel。

其中endpoint URL 是endpoint暴露给外边可以访问的地址。channel用它和endpoint交互。这个url必须是唯一的，在所有服务器上暴露的endpoints中，这个url值指向MessageBrokerServlet。

怎样给flex component分配channel

   flex components 用ChannelSet设定channel，它里面可以包括多个channel,去和server 交互。你可以选择自动和手动分配channel 给flex 组件。假如你在编译你的MXML文件时，把你的compiler 配置上 -services 选项让它指向services-config.xml 文件，那么你的组件（如RemoteObject, HTTPService等）就自动分配一个配置好的channel实例， 这个channel是根据你在services-config.xml 文件中定义好的包括destination。第二种情况如果你不想在你的compiler 中设置什么-services

选项，你可以在 MXML or ActionScript中手动创建你的channel,然后把它分配给你的flex components。如果你也不想自己配置channel，Application-level 默认channels这时就会被用到。

  如下代码自己手动定义channel

  in mxml:

   <RemoteObject id="ro" destination="Dest">

<mx:ChannelSet>

<mx:channels>

<mx:AMFChannel id="myAmf"     uri="http://myserver:2000/myapp/messagebroker/amf"/>

</mx:channels>

</mx:ChannelSet>

</RemoteObject>

in  ActionScript:

   private function run():void {

   ro = new RemoteObject();

var cs:ChannelSet = new ChannelSet();

  cs.addChannel(new AMFChannel("myAmf", "http://servname:2000  /eqa/messagebroker/amf"));

ro.destination = "Dest";

ro.channelSet = cs;

}

注意当你在客户端分配设置了channel 并指定了channel type 和 endpoint URL，但并没有

指定handles 请求的endpoint class。所以这时你还要在services-config.xml中定义你用的这个channel，指明它的url 用到的endpoint class。

把channel和endpoint分配给destination

       我们用channel和endpoint目的就是把我们的从client传过来的东西送到目的地destination。说到给destination分channel我们可以分以下几中情况。

       1，在所有services中的大多数destinations用同样的channels。我们可能定义应用级别（application-level）默认channels在services-config.xml文件中。如

<services-config ...>

...

<default-channels>

<channel ref="my-http"/>

<channel ref="my-amf"/>

</default-channels>

...

</services-config >

这样所有没定义channel的destinations就会用上面定义的默认channel,当然destinations和services都可以重载默认 channel，通过指明自己的channel。

      2.在一个service中的大多数destinations用同样的channels。我们可以定义服务级别（service-level ）默认channels在services-config.xml文件中。如

  <service ...>

     ...

  <default-channels>

  <channel ref="my-http"/>

  <channel ref="my-amf"/>

 </default-channels>

...

</service>

这样以来，在一个service中没有指定channel的destination就会用到本服务内的默认channels.

      3.一个destination 定义自己的channel.代码如下：

      <destination id="sampleVerbose">

       <channels>

       <channel ref="my-secure-amf"/>

       </channels> ...

      </destination>

BlazeDs 基于消息的framework

      blazeds 是利用基于消息的框架完成数据在客户端和服务器之间来回传递的。实际上blazeds用二种最重要的数据交换模式。第一种就是请求响应模式。PRC就是用的这种模式，这个我前几天自己摸个CRUD例子出来。推销一下：http://download.youkuaiyun.com/source/1527797（这个例子要求你自己要写个Uint bean,另外要把你的Flex编译器设置-services 选项并指向services-config.xml文件）。

      第二种模式就是发布订阅模式。在这模式下，服务器把published的信息发送给一系列订阅了这些信息的customer。举例说Messaging Service就是用这种方式把data发给对data感兴趣的client,当然Messaging Service也用 request-response pattern去与client玩。