Flex Messeging Services


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Flex Messeging Services

  1. 1. Flex Messeging Services Using BlazeDS<br />Adobe Meet Oct 2009<br />
  2. 2. What is BlazeDS?<br />BlazeDS is a server-based Java remoting and web messaging technology that allows you to connect to back-end distributed data and push data in real-time to Adobe Flex and Adobe AIR Rich Internet applications (RIA). <br />
  3. 3. Services of BlazeDS<br />The Remoting Service allows your Flex application to directly invoke methods of Java objects deployed in your application server. <br />The Message Service provides a publish/subscribe infrastructure that allows your Flex application to publish messages and subscribe to a messaging destination, enabling the development of real-time data push and collaborative applications. <br />The Proxy Service allows your Flex application to make cross-domain service requests in a secure and controlled manner. It allows your Flex application to access a service available on a different domain than the domain from where the application was downloaded (without having to deploy a crossdomain.xml policy file on the target domain). <br />
  4. 4. Feature of BlazeDS.<br />
  5. 5. BlazeDS client architecture<br />
  6. 6. BlazeDS server architecture<br />
  7. 7. BlazeDS Message Channels<br />BlazeDS Message Service is a simple publisher-subscriber model. The service configuration could be boiled down to two parts: channels and destinations. In networking terms, destination is the message hub and channel is the transport protocol.<br />
  8. 8. Messaging Flex component<br />Producer:You use the Producer component in a Flex application to enable the application to send messages. You can create Producer components in MXML or ActionScript.<br />Consumer:You can create Consumer components in MXML or ActionScript. To subscribe to a destination, you call the Consumer.subscribe() method.<br />
  9. 9. Simple Polling<br />Polling is the fool-proof messaging protocol that’s guaranteed to work in most scenarios, but it’s also the slowest and least efficient. <br />The default messaging protocol in BlazeDS uses the simple polling technique. <br />The client pings the server on a regular interval. An empty acknowledgment is returned if there’re no messages for the client,<br />
  10. 10. Simple Polling<br />
  11. 11. Long Polling<br />To achieve near-real-time messaging, there’s a option called “long polling”. <br />Instead of acknowledging right away, the server could hold the polling request until there’s a message for the client. <br />This ensure the messages are delivered to the client as soon as they become available,<br />
  12. 12. Long Polling<br />
  13. 13. Configure Long Polling<br />To add a long polling channel to BlazeDS, open WEB-INF/flex/services-config.xml. Under the channels node, add the channel definition as follows, <br />&lt;channel-definition id=&quot;my-long-polling-amf&quot; class=&quot;mx.messaging.channels.AMFChannel&quot;&gt;<br /> &lt;endpoint url=&quot;http://{server.name}:{server.port}/{context.root}/messagebroker/amflongpolling&quot;; class=&quot;flex.messaging.endpoints.AMFEndpoint&quot;/&gt;<br /> &lt;properties&gt;<br /> &lt;polling-enabled&gt;true&lt;/polling-enabled&gt;<br /> &lt;wait-interval-millis&gt;-1&lt;/wait-interval-millis&gt;<br /> &lt;polling-interval-millis&gt;100&lt;/polling-interval-millis&gt;<br /> &lt;max-waiting-poll-requests&gt;50&lt;/max-waiting-poll-requests&gt;<br /> &lt;/properties&gt;<br /> &lt;/channel-definition&gt;<br />
  14. 14. Polling Properties<br />wait-interval-millis dictates how long the server should wait before returning a polling request.<br />polling-interval-millis is the time interval between polling requests. <br />max-waiting-poll-requests caps the number of long polling clients. Since the server is not ackowleging right away during long polling, each client hogs one server thread.<br />
  15. 15. Streaming<br />BlazeDS supports real-time message streaming over AMF and HTTP. Unlike long polling, which closes and reopens the connection upon receiving a message, streaming keep the connection open at all times.<br />&lt;channel-definition id=&quot;my-streaming-amf&quot; class=&quot;mx.messaging.channels.StreamingAMFChannel&quot;&gt;<br /> &lt;endpoint url=&quot;http://{server.name}:{server.port}/{context.root}/messagebroker/amfstreaming&quot;; class=&quot;flex.messaging.endpoints.StreamingAMFEndpoint&quot;/&gt;<br /> &lt;properties&gt;<br /> &lt;idle-timeout-minutes&gt;0&lt;/idle-timeout-minutes&gt;<br /> &lt;max-streaming-clients&gt;10&lt;/max-streaming-clients&gt;<br /> &lt;server-to-client-heartbeat-millis&gt;5000&lt;/server-to-client-heartbeat-millis&gt;<br /> &lt;/properties&gt;<br />&lt;/channel-definition&gt;<br />
  16. 16. Properties<br />max-streaming-clientscontrols the number of concurrent streaming connections on the server. Streaming suffers from the same thread blocking issue as long polling. A cap must be set so the server is not hang by idle threads. <br />idle-time-minutes boots off long idling clients to free up threads. This could help alleviate the threading issue and help prevent misuse. <br />
  17. 17. Which Channel to Use?<br />With the slew of channel types available, which one should you choose? <br />Fortunately, you could leave that decision to the run-time environment. <br />The Flex client could be configured with a set of channels types. <br />It will go through the list one at a time until a successful connection could be made.<br />
  18. 18. Clerification<br />One last thing I need to clear up is the terminology confusion over the AMF channels and HTTP channels. In the context of BlazeDS channels, AMF refers to binary RPC protocol. HTTP refers to XML RPC protocol. They BOTH run on top of HTTP.<br />
  19. 19. Demo<br />
  20. 20. Q & A<br />