Tour de Flex – New LiveCycle Data Services 3.1 Samples

Author: Dave April 4, 2011

I had the distinct pleasure of building some new LCDS 3.1 samples for Tour de Flex recently which just went live. For each sample, I thought it would be helpful to elaborate on each one a little bit more to help give ideas about what the new features can do for your applications.

For the data throttling and reliable messaging samples, there is a Java class that iterates a number and pushes it out to an LCDS destination the samples subscribe to. The reason for this is to simulate constant incoming messages to Flex. The iterated number itself goes on for a few minutes and restarts at 0 so you can see the order the messages come in.

In this post, I’ll assume you’re familiar with LCDS/BlazeDS basics. Most of the samples require you to make changes to your services-config.xml or messaging-config.xml, and some require you to enable Advanced Messaging Support.

• Adaptive Client Message Frequency
  This feature falls under the Advanced Data Throttling features of LCDS which are not available in BlazeDS. Adaptive Client Message Frequency adjusts the message frequency limits based on each client’s message processing rates. So in the TDF sample, the server will determine how many messages to send per second to send to the client and adjust the frequency in steps of 10 messages (10 less, or 10 more messages per second based on the server’s calculation).
• Asynchronous Message Filtering
  This feature is very useful to pre-process incoming messages and post-process outgoing messages on the server-side. In the sample, the message filter simply removes any occurrences of the word “foo”. No foo for you! You can imagine that you could employ message filters in a number of situations, like adding a server-side step in form validation on top of the client-side, or vice versa, making sure messages sent from the server are formatted correctly or are headed to the right end user.
• Basic Authentication
  You can secure any destination using Tomcat’s built-in security constraints. This sample relies on standard J2EE basic authentication from the application server. The “trusted” security-constraint exists in the services-config.xml. When you attempt to access the secured destination, the browser prompts you to log in. The preferred method for authentication with LCDS, however, is to use Custom Authentication.
• Custom Authentication
  By using Custom Authentication, the client passes log in credentials to the server without having to rely on the browser. LCDS provides application container authentication with login command classes to do container-specific authentication and authorization. You can optionally write your own LoginCommand class if needed.
• Client-Level Data Throttling
  With this feature, you set the message-level frequency on the client-side (maxFrequency=1 in the code for the Consumer). In this case, the server will ensure it only sends one message per second to the client application. Data throttling is very useful to ensure that a server doesn’t overwhelm slow clients with messages sent, and that a server itself isn’t bombarded with messages from multiple clients.
• Destination-Level Data Throttling
  The max-client-frequency attribute in the messaging-config.xml indicates that the destination processes a maximum of 5 messages per second from individual Flex clients. The client code attempts to send 20 messages concurrently to the server which causes the “throttled” error on the server to be sent back to the Flex app. There are multiple configurations for max-frequency inbound/outbound, and max-client-frequency inbound/outbound that deal with per client, or the entire pool of clients message handling. See the README.txt file in this sample for further explanation.
• Reliable Messaging
  This one is my personal favorite new feature for LCDS 3.1. This features improves the quality of messaging between clients and destinations. The benefits include no message loss, ordered message delivery, no duplicate message processing, and reconnection to server following unexpected connection loss. To see it work, subscribe to the destination and you’ll see the numbers being iterated. If you’re on WiFi, turn it off (disconnect your internets) and back on within 30 seconds. Otherwise pull your cord – no sophmoric jokes plz 🙂 – and plug it back in before the 30 seconds is up. Once the numbers start iterating again, click the unsubscribe button, that’ll make things easier to see. When you scroll through each TextArea, you should see a substantial gap in iterated numbers on the right side because that TextArea contains messages sent from the unreliable destination. On the left, the TextArea shows messages from the reliable destination, so it will pick up your Flex client and send the iterated numbers in order as soon as you reconnect to the web.
• Flex/Spring Remoting
  This sample shows how you can use an LCDS destination to allow remoting directly to a Spring bean from a Flex client. You configure the flex namespace in the Spring xml config, a message-broker tag in your WebApplicationContext xml file, and specify the Java class and you’re ready to access some Spring goodness.
• Flex/Spring Security
  Both Flex/Spring samples use the web-application-config.xml to configure access to the PlanetService bean or enable Spring security.

Extra thanks to Greg Wilson and Holly Schinsky for the project and their invaluable help throughout! In the near future, I’ll post some more about each sample in more detail. In the meantime, there are tons of new Flex 4, Flex 4.5 (Hero), mobile and LCDS 3.1 samples to check out in Tour de Flex, and more to come!