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倍左右。

常見錯誤：

如上圖所示，假如在blazeDS配置檔案檔案中寫錯路徑或是其它的話，用戶端在編譯的時候就會自動檢查不通過。 上面不難發現是路徑問題。在配置檔案中應改為：mx.messaging.channels.AMFChannel。其實就多了一個e.   不是messageing 而是messaging。