What is it?

RedLiteGreenLite is a small, simple app that allows a group of people to communicate the status of something. The status can be either red or green and the subject can be whatever. That may sound a bit general, but that’s the point. It can be used for whatever purpose your crazy mind can come up with. I’ll get you started:

1. At work, we have a single shower and a lot of shweaty guys after soccer. So we know when the shower’s available, someone can turn the status red when he enters the shower and turn it green when he exits. This way nobody has to keep stopping by the shower to see if it’s available. When it’s green, it’s available. When it’s red, it’s not.
2. At a call center, representatives are split into groups. When one group is on break, no other group is allowed to go on break. Again, when the status is red, a group is on break and other groups must continue attending the phones. When the lite is green, the next group is free to take a break.

The process is pretty simple: join a group. Other people join the same group. When others in the group change the status, you’ll be notified. When you change the status, others in the group will be notified. The status of the group will be persisted across sessions. In other words, if everyone logs out and then logs back in a week later, the status will remain as it was the last time it was set.

There’s no need to explicitly create a group. When you attempt to join a group, the group will automatically be created if it does not already exist.

The app is free. As in free free.

What technologies are used?

RedLiteGreenLite has a client portion and a server portion.

The client is the app users download and install on their computers. It’s built in Flex and published for AIR. It uses the RobotLegs MVCS framework and makes use of AMF remoting and messaging.

The server portion is built in Java using BlazeDS and is hosted on Google Apps Engine.

Ooh, that’s simply juicy. Tell me more.

Don’t mind if I do. First of all, BlazeDS is an open source implementation of AMF-based remoting and messaging. Natively it’s not compatible with Google Apps Engine, but I wanted to use GAE because it’s extremely scalable, it’s free (let’s be honest–I’m cheap like that–this is the main reason), and I wanted the challenge.

To get BlazeDS working on GAE, I recommend following Martin Zoldano’s blog post. Not only does he outline the steps you’ll need to take but he provides a critical patch to flex-messaging-core.jar as well. While you can find this patch re-distributed elsewhere, I recommend posting a comment requesting that he email you the patched jar. That’s how he seems to want to distribute his patch and I respect that. He’s really helpful and quick to respond so it shouldn’t be much trouble.

Once BlazeDS was set up and configured, I started to plan the architecture. First of all, I needed one client in the group to be able to send a message to the rest of the clients in the group. This could be achieved through the messaging service BlazeDS provides. However, messaging doesn’t store state; it just redistributes messages to clients. I needed the group’s status to be persisted to storage so (1) when a new client joins a group it can retrieve the group’s current status and (2) the group’s status can be retained even when no clients are connected.

By default, BlazeDS’s messaging configuration uses ActionScriptAdapter to receive and distribute messages between clients. It doesn’t persist messages. To do so, I extend ActionScriptAdapter and persist the status to Google Storage before sending the message out to the other clients. When clients connect to BlazeDS, they use remoting (not messaging) to retrieve the most recently persisted status for the group. After the initial status is retrieved, the client talks to other clients using the messaging service. You can see how this is set up in messaging-config.xml and PersistentASAdapter.java in the server code.

While GAE has been really nice to get the app up and running, it does have its downsides. To send messages between clients, BlazeDS can use a few different techniques:

• Simple polling. The client, at a standard interval, simply asks the server if there is any new information. The server responds to the request immediately regardless of whether there is new information.
• Long polling. The client sends a request to the server. The server holds onto the request until it has something useful to tell the client at which time it sends back the response.
• Streaming. The client opens an HTTP connection and the connection remains open. The server shoots messages down the connection whenever it has something to say. It’s an “infinate response”.

While each approach has its pros and cons, simple polling leaves a lot to be desired as it creates a lot of HTTP traffic. Unfortunately, from my testing and research, GAE doesn’t seem to support either of the other two methods. But hey, it’s free. If any of you have a java environment and would like to host RedLiteGreenLite so we can step up our game, let me know.

Last but not least, RedLiteGreenLite is open source. I’d love for you to fork the project and do something cool with it.

Now go have fun! Install the client using the badge at the top of the post or fork the project using the link below.

While that’s impressive, when it comes to implementation in a medium-to-high complexity system there are questions that still need to be answered.   In this article, I’d like to address where to translate custom AMF classes.

The Why

When server-side code accesses data from a database, it generally converts the data in the recordset into data objects (sometimes called beans, business objects, or one of many other names.)  These are basic objects that often, though not always, represent the shema of the database.  In other words, if there’s a table named customer in the database, there will likely be a class named customer as well.  One customer object instance represents one customer record in the database.  With frameworks like Rails, Cake, and Django, this is almost always true.

If a Flex application is requesting all customers, the process of retrieving the data is fairly simple: Flex makes a call to the service, the service retrieves all customer records from the database, the service converts each customer record into an customer object, and finally the service returns the array of customer objects back to the Flex application.

In order for the previous example to function correctly, an ActionScript customer class must exist on the Flex client as well as an identical Java customer class on the server.  Considering the most common case, these two classes will have properties that match the fields in the customer table.  In other words, both of these classes as well as the customer table will have properties such as firstName, lastName, phoneNumber, address, zipcode, etc.  With that in mind, what happens when a developer begins to refactor the application and chooses to rename the phoneNumber database field to homePhone?  The phoneNumber property in both the ActionScript customer class and the Java customer class will need to be renamed to homePhone.  This means there is high coupling among the database, the backend application, and the frontend application.  In other words, each part needs to know about the other two parts.  This breaks good programming principles because it results in more difficult maintenance.

This high coupling magnifies itself further if we wish to have the Flex application’s needs drive the design of the data objects.  Lets say we as Flex developers are creating a Flex application and know we want a salesperson’s first name, last name, sales code, and whether the salesperson is a system admin.  Now let’s say the database has already been designed and for whatever reason the salesperson’s firstName and lastName are in one table, the sales code is in a different table, and the system admin rights are in another.  Without some sort of conversion adapter, we will be shipping objects created from three different classes (Class A related to Table A, Class B related to Table B, and Class C related to Table C) from the server to the Flex frontend.  The following diagram illustrates the data flow.

Why does this high coupling present a problem?  Here are a few issues to think about:

(1) If the backend developer chooses to refactor the database table by combining Table A and Table B, the Java classes AND the ActionScript classes must also be refactored.  If we’re talking about production code, that means refactoring ActionScript code and redeploying the SWF.  In the case of an AIR app, the AIR application on each client computer must be upgraded.

(2) The Flex frontend probably does not, and to promote low coupling, should not, care about how the database was designed.  This is more an issue of principle, but if the frontend developer is mentally detached from the database schema, the frontend application’s modeling, logic, and architecture will in general likely also be decoupled from the database schema.

(3) Having three different ActionScript classes to get our salesperson information doesn’t necessarily make sense.  Maybe there was a reason to have the information in three different database tables, but the reasoning may not apply when it comes to the Flex frontend.  Having three different classes means more overhead and maintenance.

(4) Even simple differences such as coding style must be maintained across the database, backend code, and frontend code.  If the database fields were creating using underscores such as first_name, last_name, home_phone, etc., this style must be also be used in the backend code and the frontend code.  Considering most Flex developers use camelCase name styling (firstName, lastName, homePhone,) this coupling presents an inconsistency in style.

The What

So, how do we deal with these issues?  Generally the best solution is to create an adapter or layer that converts objects the backend uses to objects the frontend needs.  The backend and frontend agree on the classes that will be sent across the wire and those classes essentially become a contract–an agreement between the frontend and backend on what will be sent and received.  These classes should be designed without regard to database schema or the classes the backend uses within its own domain.  In our example, Flex needs objects of Class X which includes a salesperson’s first name, last name, sales code, and whether the salesperson is a system admin.  The backend is already using Class A, Class B, and Class C that contain these various properties.  The adapter would take objects of Class A, Class B, and Class C and combine the needed properties into an object of Class X.  Class X is essentially the contract–both the backend and frontend have agreed that Class X is what will be sent and received.

Not only does an adapter allow for the creation of objects that are slim-and-trim and customized for Flex’s needs, but of even greater importance is it provides a point of decoupling.  If the field in a database table gets renamed, the related property in the frontend class does not need to be renamed.  Instead, only the adapter needs modified so the new backend property name is mapped to the old frontend property name.  This adapter also provides for a place to convert programming style (first_name on the backend would be mapped to firstName on the frontend.)

The Where

Now that you (hopefully) understand what adapters are and why they’re helpful, the remaining question is where the adapter should be implemented.  Two possible locations are the most logical: (1) on the backend immediately before sending objects to the frontend or (2) on the frontend immediately after receiving objects from the backend.  The data flow process for each of these adapter locations is illustrated in the following diagrams.

Here are the benefits of each location as I see them:

On the backend immediately before sending objects to the frontend:

• Database schema changes do not have any affect on frontend code (except for changes fundamental to application logic.)  This means when the database schema changes, the Flex/Flash/AIR application does not need to be recompiled and redeployed.  If the adapter were on the frontend, the adapter would need to be updated, resulting in the need to be recompiled and redeployed.
• In a team environment, a backend developer can modify the database schema and commit changes to the backend classes and accompanying adapter almost simultaneously. Frontend development remains virtually uninterrupted.  If the adapter was on the frontend, the backend developer would make the change to the database schema and commit the changes to the backend classes.  The backend developer would then need to notify the frontend developer of the change.  The frontend developer would then modify the adapter and commit its change.   Throughout the duration between the backend developer’s commit and the frontend developer’s commit, the Flex application would not function correctly. Because the frontend is generally more concerned with the presentation of data rather than heavy analysis, data mining, integration with ecommerce, and other data-centric tasks, frontend developers will likely require less refactoring of data models than backend developers.  By having the adapter on the backend, less communication between developers will be required when refactoring.
• Keeping adapter code out of the frontend results in a smaller SWF/AIR file size.
• Conversion tasks carried out by the adapter require processing.  By keeping processing on the server, processing time is more predictable and manageable than if the processing were performed on the client.

On the frontend immediately after receiving objects from the backend:

• The backend does not need to know how frontend data is modeled.  In other words, if a frontend developer would like to rename a property in the data model’s class or combine two classes, the backend does not need to be notified.  If the adapter were instead on the backend, the application would be broken during the duration between when the frontend developer commits the data model’s class change and the backend developer commits the backend class and adapter change.  However, like I mentioned previously, it’s been my experience that the frontend requires less data model refactoring than the backend.

As you may have concluded from the analysis, it’s fairly clear the best location for the adapter is on the backend just before sending objects to the frontend.  While having an adapter or at least some level of abstraction in the first place is certainly the most important concept, having an adapter in the right location can also help.

Do you disagree or have a perspective not addressed in my analysis?  Do you have questions regarding the why, what, and where of custom class adapters?  I invite you to join in on the conversation by responding below.

AMF is a protocol that allows ActionScript (the language of Flash/Flex) to call services exposed by the back-end. Additionally, if you choose, AMF allows you to translate a programmer-defined object between ActionScript and your back-end language of choice. In other words, if you have a customer class in ActionScript and you want to pass an instantiated customer object to the back-end, you simply call the exposed back-end service and pass the customer object as a parameter. The AMF layer transparently translates the ActionScript customer object into, let’s say, a customer object in Java. This functionality isn’t required. Instead of using a class you have defined, you could instead just send an integer to the backend as a parameter and, after processing, send a string back to the front-end.

Before checking out my example, I recommend checking out the Wikipedia Action Message Format article to get a basic description of AMF and links to implementations for various back-end languages. I also recommend reading AMFPHP class mapping explained by Chuck Hoffman to get a good understanding of the object translation I just described. Finally, head on over to amfphp.org (the creators of AMFPHP) to get a glimpse of available documentation, files, etc. I might add that if any of the folks over at amfphp.org don’t like me distributing AMFPHP code, let me know and I’ll modify the files I’ve posted for download. The zip file below currently contains everything you’ll need to get a simple example up and running. Now to the example…

Simple AMFPHP Example Zip File

For the example, I made a Kite Finder. Basically, you enter in a kite pilot’s name and Flex populates a person object with the pilot name entered. Flex then calls a PHP service function using AMFPHP which translates the ActionScript person object to a PHP person object on the backend. In a real environment, you would then use information from the person object to hit a database to find the pilot’s kite. In our example, we just build a kite object using dummy data. Our PHP function then returns the kite object, which AMFPHP ships back to the Flex front-end, translating it to an ActionScript kite object. In reality, the person and kite classes might be a little overboard for such a simple example. I could’ve just passed two string parameters (the pilot’s first and last name) to the PHP function and an associative array (kite info) back to the front-end, but I wanted to demonstrate AMFPHP’s object translation.

Setting up the example is fairly easy:

1. Upload the amfphp directory to the root directory of your website.
2. Open the SimpleAMFPHP project in FlexBuilder and modify the “gateway” variable in FindKiteCommand to point to your new gateway address.

That’s all! You should be able to deploy the project from within FlexBuilder and see it in action. This should work even if you’re using inexpensive web hosting. If you have questions on where code is, what’s happening, how to do something, or anything else, please…join the intimate conversation!