前言ActiveMQ支持Ajax,这是应用在实时web应用中的一种异步的Javascript和Xml机制。这意味着你可以利用ActiveMQ的“发布/订阅”的天性,来创建高度实时的web应用。 Ajax允许一个常见的DHTML客户端(使用JavaScript和一个第5版及更高版本的现代浏览器)通过互联网收发信息。ActiveMQ对Ajax的支持建立在与REST的ActiveMQ连接器相同的基础上,该连接器允许任意可联网的设备通过JMS收发消息。 如果想看一下Ajax是怎么用的,跑一下 官方的例子 就行了。 Servlet首先要在Web应用中安装AMQ的AjaxServlet,以此来支持基于Ajax的JMS: ... 这个servlet既可以为需要的js文件提供服务,又可以处理JMS的请求和响应。 Javascript APIActiveMQ的ajax特性是由客户端的 amq.js脚本提供的。从ActiveMQ 5.4开始,该脚本利用三个不同的适配器中的一个来支持与服务器的通信。流行的jQuery、Prototype以及Dojo都是被支持的,并且这三个库的比较新的版本都随ActiveMQ发布了。
<script type="text/javascript" src="js/jquery-1.4.2.min.js"></script> 包含这些脚本的结果就是创建了一个名叫amq的javascript对象,它提供了发送信息以及订阅频道和主题的API。 发送一条消息要从javascript客户端发送一条JMS消息,需要做的仅仅是调用这个方法: amq.sendMessage(myDestination,myMessage); 这里的myDestination是目的地URL字符串地址(例如:"topic://MY.NAME" 或者 "channel://MY.NAME"),myMessage是任意格式化好的XML或者被编码为XML内容的纯文本。 接收消息要接收消息,客户端必须定义一个消息处理函数,并且将其注册到amq对象中。例如: var myHandler = 这里的myId是一个字符串标识符,在之后调用amq.removeHandler(myId)函数的时候会用到。myDestination是目的地URL字符串地址(例如:"topic://MY.NAME" 或者 "channel://MY.NAME")。接收到消息的时候,回调函数myHandler.rcvMessage会把消息传递到你的处理代码块。 该“消息”其实是文本消息的正文,或者对象消息的字符串(toString())表示形式。 注意,默认情况下,通过Stomp发布的消息如果包含了content-length消息头,则它将会被ActiveMQ转换为二进制消息,并且会对web客户端不可见。从ActiveMQ 5.4.0开始,你可以通过将amq-msg-type消息头 设置设为“text”,以使消息可以被web客户端消费。 对选择器的支持默认情况下,一个ajax客户端会接收到其订阅的主题或队列上的所有消息。在ActiveMQ 5.4.1中amq.js支持了JSM选择器,因为很多时候仅接收这些消息中的一个子集非常有用。选择器被作为调用amq.addListener函数的第四个可选参数。 amq.addListener( myId, myDestination, myHandler.rcvMessage, { selector:"identifier='TEST'" } );
这样用的时候,Javascript客户端只会收到包含了被设置为“TEST”的“identifier”消息头的消息。 在多浏览器窗口中使用AMQ Ajax单一浏览器的所有窗口或者tab页在ActiveMQ服务器中共享同一个JSESSIONID。除非服务器可以分辨多窗口的监听器,否则发送给一个窗口的 消息可能被传递到另一个窗口。实际上,这意味着amq.js在任意时刻只能在一个浏览器窗口保持活跃。从ActiveMQ 5.4.2开始,这个问题被解决了,解决方法是允许对amq.init的每一次调用指定一个唯一的clientId。这样做之后,同一个浏览器的多个窗口就可以快乐地共存了。它们分别在代理上有单独的消息订阅者集合,并且不互相影响。 这个例子中,我们使用当前时间(web页面被加载的时间)作为唯一标识。只要两个浏览器窗口不是在同一毫秒打开的,这种方法就是有效的,并且包含在ActiveMQ发行版的例子 chat.html 中使用的就是这种方法。其他保证clientId唯一性的方法也会很容易设计出来。注意clientId只需要在一个session中唯一即可。(同一毫秒在不同浏览器中打开的窗口不会互相影响,因为他们属于不同的session。) org.activemq.Amq.init({ 注意在一个tab页或者窗口中,clientId对所有的消息订阅者是公用的,并且它和作为amq.addListener函数的第一个参数的clientId是完全不同的。
它是如何工作的AjaxServlet 与 MessageListenerServlet在服务器端,amq的ajaxt特性是被继承自MessageListenerServlet的AjaxServlet处理的。这个servlet负责追踪既有的客户端(使用一个HttpSession),并慢慢地构造客户端收发消息需要的AMQ和javax.jms对象(例如:目的地、消息消费者、消息可用监听器,即Destination, MessageConsumer和MessageAVailableListener)。这个servlet应当被映射到服务于Ajax客户端的web应用上下文中的“/amq/*”路径下(这是可以改变的,但客户端javascript的amq.uri域需要做相应的修改。) 客户端发送消息客户端发送一条消息的时候,它被编码为POST请求的内容,使用的是所支持的几个XmlHttpRequest连接适配器之一(jQuery、Prototype或Dojo)中的API。amq对象可能会将若干发送消息的请求合并到一个单独的POST中,当然这样做的前提是能做到不增加额外的延迟(看下面的“轮询”部分)。 当接MessageListenerServlet 收到一个POST请求,消息会被作为application/x-www-form-urlencoded参数解码,并带有类型“type”(在此情况下是“send”,而不是下面所说的“lisen”或“unlisten”)和目的地。 如果一个目的地通道或者主题不存在,它将会被创建。消息将会作为一个文本消息(TextMessage)被发送到目的地。 监听消息当客户端注册了一个监听器,消息订阅请求在一次POST请求中从客户端发送到服务器端,就像发送消息一样,只不过其类型“type”为“listen”。当MessageListenerServlet接收到“listen”消息的时候,它就慢慢地创建一个MessageAvailableConsumer并为其注册一个监听器。 等待轮询消息当一个由MessageListenerServlet 创建的监听器被调用,表明一条消息可用时,由于HTTP“客户端-服务器”模式的限制,不可能直接把这条消息发送到ajax客户端。相反客户端必须对消息 实施一种特殊类型的“轮询”。轮询通常意味着周期性的发送请求去查看时候有消息可用,这样的话就有一个折中的考虑:如果轮询的频率比较高,当系统空闲的时 候就会产生过多的负载;反之如果轮询频率低,探测新消息的延迟就会变高。 为解决负载和延迟的折中问题,AMQ使用一种等待轮询机制。一旦amq.js脚本被加载,客户端就开始从服务器轮询可用消息。一个轮询请求可以作为一个GET请求发送,如果有其他准备从客户端发送到服务器端的消息,也可以作为一个POST请求发送。当MessageListenerServlet接收到一次轮询的时候,它将会:
当amq.js javascript接收到轮询请求的响应时把所有消息传递到注册的处理函数,以此来处理它们。一旦处理完了所有的消息,它立即向服务器发送另一次轮询。 所以amq ajax特性的空闲状态是服务器上的一次轮询请求“空档”,等待消息被发送到客户端。这个“空挡”请求被一个超时设定周期性地刷新,防止任何 TCP/IP、代理或者浏览器的超时关闭连接。所以服务器能够通过唤醒“空档”请求并允许发送响应,来异步地向客户端发送一条消息。 客户端可以通过创建(或使用现有的)第二条连接,异步地向服务器发送一条消息。然而,在处理轮询响应的过程中,正常的客户端消息发送被暂停,因此所有要发 送的消息进入队列,在处理过程结束时连同将要发送的轮询请求(无延迟),作为一个单独的POST进行发送。这确保了客户端和服务器之间只需要两个连接(对 大多数浏览器来说)。 无线程(threadless)等待上面描述的等待轮询是使用Jetty 6的Continuations机制实现的。这允许与请求关联的线程在等待期间被释放,所以容器就不需要为每个客户端维护一个线程了(这可能是一个很大的数字)。如果使用了另一个servlet容器,Continuation机制退回到使用等待,并且线程不被释放。 与“服务器推送”对比首先我们可以很容易地为ActiveMQ增加服务器推送支持。然而由于多种原因,我们更喜欢Ajax方式:
另附原文如下:
IntroductionActiveMQ supports Ajax which is an Asychronous Javascript And Xml mechanism for real time web applications. This means you can create highly real time web applications taking full advantage of the publish/subscribe nature of ActiveMQ Ajax allows a regular DHTML client (with JavaScript and a modern version 5 or later web browser) to send and receive messages over the web. Ajax support in ActiveMQ builds on the same basis as the REST connector for ActiveMQ which allows any web capable device to send or receive messages over JMS. To see Ajax in action, try running the examples The ServletThe AMQ AjaxServlet needs to be installed in your webapplications to support JMS over Ajax: ... The servlet both serves the required js files and handles the JMS requests and responses. Javascript APIThe ajax featues of amq are provided on the client side by the amq.js script. Beginning with ActiveMQ 5.4, this script utilizes one of three different adapters to support ajax communication with the server. Current jQuery, Prototype, and Dojo are supported, and recent versions of all three libraries are shipped with ActiveMQ. <script type="text/javascript" src="js/jquery-1.4.2.min.js"></script> Including these scripts results in the creation of a javascript object called amq, which provides the API to send messages and to subscribe to channels and topics. Sending a messageAll that is required to send a JMS message from the javascript client, is to call the method: amq.sendMessage(myDestination,myMessage); where myDestination is the URL string address of the destination (e.g. "topic://MY.NAME" or "channel://MY.NAME") and myMessage is any well formed XML or plain text encoded as XML content. Receiving messagesTo receive messages, the client must define a message handling function and register it with the amq object. For example: var myHandler =
where myId is a string identifier that can be used for a later call to amq.removeHandler(myId) and myDestination is a URL string address of the destination (e.g. "topic://MY.NAME" or "channel://MY.NAME"). When a message is received,
a call back to the myHandler.rcvMessage function passes the message to your handling code. Be aware that, by default, messages published via Stomp which include a content-length header will be converted by ActiveMQ to binary messages, and will not be visible to your web clients. Beginning with ActiveMQ 5.4.0, you can resolve this problem by always setting the amq-msg-type header to text in messages which will may be consumed by web clients. Selector supportBy default, an ajax client will receive all messages on a topic or queue it is subscribed to. In ActiveMQ 5.4.1 amq.js supports JMS selectorssince it is frequently useful to receive only a subset of these messages. Selectors are supplied to an amq.addListener call by way of an optional 4th parameter. amq.addListener( myId, myDestination, myHandler.rcvMessage, { selector:"identifier='TEST'" } ); When used in this way, the Javascript client will receive only messages containing an identifier header set to the value TEST. Using AMQ Ajax in Multiple Browser WindowsAll windows or tabs in a single browser share the same JSESSIONID on the ActiveMQ server. Unless the server can distinguish listeners from multiple windows, messages which were intended for 1 window will be delivered to another one instead. Effectively, this means that amq.js could be active in only a single browser window at any given time. Beginning in ActiveMQ 5.4.2, this is resolved by allowing each call to amq.initto specify a unique clientId. When this is done, multiple windows in the same browser can happily co-exist. Each can have a separate set of message subscriptions on the broker with no interactions between them. In this example, we use the current time (at the time the web page is loaded) as a unique identifier. This is effective as long as two browser windows are not opened within the same millisecond, and is the approach used by the example chat.html included with ActiveMQ. Other schemes to ensure the uniqueness of clientId can easily be devised. Note that this clientId need only be unique within a single session. (Browser windows opened in the same millisecond in separate browsers will not interact, since they are in different sessions.) org.activemq.Amq.init({ Note that this clientId is common to all message subscriptions in a single tab or window, and is entirely different from the clientId which is supplied as a first argument in amq.addListener calls.
How it worksAjaxServlet and MessageListenerServletThe ajax featues of amq are handled on the server side by the AjaxServlet which extends the MessageListenerServlet. This servlet is responsible for tracking the existing clients (using a HttpSesssion) and lazily creating the AMQ and javax.jms objects required by the client to send and receive messages (eg. Destination, MessageConsumer, MessageAVailableListener). This servlet should be mapped to /amq/* in the web application context serving the Ajax client (this can be changed, but the client javascript amq.uri field needs to be updated to match.) Client Sending messagesWhen a message is sent from the client it is encoded as the content of a POST request, using the API of one of the supported connection adapters (jQuery, Prototype, or Dojo) for XmlHttpRequest. The amq object may combine several sendMessage calls into a single POST if it can do so without adding additional delays (see polling below). When the MessageListenerServlet receives a POST, the messages are decoded as application/x-www-form-urlencoded parameters with their type (in this case send as opposed to listen or unlisten see below) and destination. If a destination channel or topic do not exist, it is created. The message is sent to the destination as a TextMessage. Listening for messagesWhen a client registers a listener, a message subscription request is sent from the client to the server in a POST in the same way as a message, but with a type of listen. When the MessageListenerServlet receives a listen message, it lazily creates a MessageAvailableConsumer and registers a Listener on it. Waiting Poll for messagesWhen a Listener created by the MessageListenerServlet is called to indicate that a message is available, due to the limitations of the HTTP client-server model, it is not possible to send that message directly to the ajax client. Instead the client must perform a special type of Poll for messages. Polling normally means periodically making a request to see if there are messages available and there is a trade off: either the poll frequency is high and excessive load is generated when the system is idle; or the frequency is low and the latency for detecting new messages is high. To avoid the load vs latency tradeoff, AMQ uses a waiting poll mechanism. As soon as the amq.js script is loaded, the client begins polling the server for available messages. A poll request can be sent as a GET request or as a POST if there are other messages ready to be delivered from the client to the server. When the MessageListenerServlet receives a poll it:
When the amq.js javascipt receives the response to the poll, it processes all the messages by passing them to the registered handler functions. Once it has processed all the messages, it immediately sends another poll to the server. Thus the idle state of the amq ajax feature is a poll request "parked" in the server, waiting for messages to be sent to the client. Periodically this "parked" request is refreshed by a timeout that prevents any TCP/IP, proxy or browser timeout closing the connection. The server is thus able to asynchronously send a message to the client by waking up the "parked" request and allowing the response to be sent. The client is able to asynchronously send a message to the server by creating (or using an existing) second connection to the server. However, during the processing of the poll response, normal client message sending is suspended, so that all messages to be sent are queued and sent as a single POST with the poll that will be sent (with no delay) at the end of the processing. This ensures that only two connections are required between client and server (the normal for most browsers). Threadless WaitingThe waiting poll described above is implemented using the Jetty 6 Continuations mechanism. This allows the thread associated with the request to be released during the wait, so that the container does not need to have a thread per client (which may be a large number). If another servlet container is used, the Continuation mechanism falls back to use a wait and the thread is not released. Comparison to PushletsFirstly we could easily add support for pushlets to ActiveMQ. However we prefer the Ajax approach for various reasons
|
|
来自: LibraryPKU > 《J2EE》