BlazeDS and LCDS RPC Call Ordering

I'm working on a project that is performing "real-time saving" of data in a Flex UI. In other words, if they do something in the UI, that change is saved to the database automatically, rather than waiting until the user presses a save button.

One concern we had was what happens if multiple requests are sent to the server, and for whatever reason some take longer to complete than others? i.e. you send RequestA then RequestB, and RequestA takes 10 seconds but RequestB takes 1 second. Which would mean the database would end up being wrong, with the data from RequestA being the last version saved. How can we make sure that the final state persisted in the database is actually the current state, and not the last request that happened to complete?

A number of options were thrown on the table, including implementing a client and/or server-side queue, or building logic to verify that the current state in the client matches the persisted state. While mulling this over, one of my colleagues noticed an interesting line in the LCDS documentation:

Channels also impose an order to the flow of messages sent to the server and the order of corresponding responses. Order is important to ensure that interactions between the client and server occur in a consistent, predictable fashion.

It's rather vague, but we read that to say "even though you think your calls to the channel are asynchronous, they actually aren't." Which, even though it is not what I thought was going on at all, would mean that the problem I mentioned earlier actually isn't a problem at all.

Tom Jordahl was kind enough to respond to an email and discuss this. I then ran a number of tests locally to confirm the behavior. It turns out that calls to Messaging Channels are totally asynchronous, but calls by the same client to the same RPC Channel are synchronous. Which means if you send RequestA then RequestB, they will be processed in that order and the results will come back in that order. Regardless of how long either of them take to complete.

You can still run asynchronous RPC calls from the same client, but they would have to call different Channels. So the option is there if you need it.

I wanted to blog this because I've been using remoting for a long time and never knew this. In fact, I always assumed the opposite was true. So, this is a big deal for two reasons: if you need to ensure the order of your RPC calls, you can. And conversely, if you think your RPC calls to the same Channel are running asynchronously, they actually are not! And this applies whether you're using a Java back end with BlazeDS/LCDS, or using ColdFusion with its BlazeDS integration.

Comments Comments (3) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 6231 Views

Swiz 2.0 Beta, Now with AOP!

In case you missed it, the Swiz team has made Swiz 2.0 Beta available. It includes the much-anticipated Aspect-Oriented Programming (AOP) features that have been in the works for a long time. AOP is incredibly powerful, and having done a lot of work with Spring, ColdSpring, and Spring.NET, it is hard to overstate the potential impact of AOP for Flash.

I also want to give a shout out to Maxim Porges, who spearheaded the effort to bring true bytecode generation to Flash with his Loom project. Without his effort this just wouldn't be happening.

For now, you can find full details on the new AOP features in the Swiz blog! As things get more stable, you can expect the Swiz documentation to incorporate this as well.

Comments Comments (4) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 6411 Views

Spark Skins, Components, and Presentation Models

In the Flex 3.x world, I adopted the Presentation Model pattern and applied it just about everywhere. Separating the non-view logic made perfect sense, far better than the code-behind approach, and cleaned up the view components wonderfully.

Then Spark came along in Flex 4, and things have changed. The framework now has built-in support for separating the "view" (skin) from the "controller" (host component). As I've been using skinning more and more, I've come to wonder if or how the presentation model approach applies in the Spark skin world.

To try and answer that question, I created a fairly simple but non-trivial test application that creates the same views and behavior in three ways. I've heard each of these three ways mentioned at various times by various people, so I used them as the most commonly proposed options:

  • Supply a presentation model to both the skin and the host component, and let it act as a bridge between the two. In other words, the skin knows nothing about the host component, and the host component knows nothing about the skin. Create the PM as a self-contained set of methods and properties that can be applied to any relevant skin or host component. In essence, if the skin is the "view" and the component is the "controller", the PM is the "model" in this mini-MVC configuration.
  • Supply a presentation model to only the host component, and have the host component push state into the skin. In this case, the skin knows nothing about the host component, but the host component it tightly coupled to the skin.
  • Drop the presentation model approach completely. All behavior and properties are held in the host component, and the skin binds to host properties and invokes methods on the host. In this setup, the host knows nothing about the skin, but the skin is tightly coupled to the host.

After building all of these, there are pros and cons to each approach. And some definitely seem to have more pros or more cons than others. The one thing I tend to focus on is what kind of change and what kind of reuse each approach allows for. If you view the running test application, you'll see I've noted some thoughts on each in the sidebar. View source is also enabled, so if you want to look through the code or download it, feel free.

I'm very interested to hear other people's thoughts on this as well. So if you have an opinion on this, or any issues with how I've built any of these versions, by all means please comment below!

Comments Comments (18) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 7007 Views

Swiz Console 1.2, and an introduction to AOP in ActionScript

First just a quick note that I have updated the Swiz Console to version 1.2, which maintains parity with Swiz version 1.2. This update adds a tab to show views that have been processed with ViewAdded and ViewRemoved. As always, you can grab the swc or the source at my GitHub repository.

In other news, Chris Scott put up a blog entry on the Swiz site with an overview of aspect-oriented programming in AS3. One might speculate that this is a lead-in to some very cool stuff coming in the Swiz framework, if one were so inclined...;-)

Comments Comments (3) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 4505 Views

Swiz 1.2 Is Out!

Just a very quick entry to say that the Swiz Team has pushed version 1.2.0 out the door! This has a few small tweaks and bug fixes, but also adds the ViewAdded and ViewRemoved metadata tags to support the use of the View Mediator pattern.

We also did a bit of consolidation related to conditional compilation. We still have two versions, but one is now just for the Flex 4.x SDK (including the 4.5 Mobile SDK), and the other just for the Flex 3.x SDK. Get it while it's hot!

Comments Comments (2) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 4094 Views

Previous Entries / More Entries