Adobe and Unite RIA and The Cloud

The two major trends transforming software right now are Rich Internet Applications (RIAs) and Cloud Computing / Software as a Service (SaaS or PaaS). These trends are driven by two needs:

  • Full client capabilities, which allow software to perform optimally and increase usability
  • Easy deployment, which allows developers to focus on business needs instead of building infrastructure

The combination of RIA and Cloud is the future of software because it provides full client capabilities and easy deployment. The chart below illustrates this in comparison to the other major software architectures (main-frame, client / server, and web).


In line with these trends Adobe and announced today that they are working together to unite Rich Internet Applications and The Cloud. At the core of this announcement is a developer preview of the Adobe Flash Builder for tool. This tool enables developers to easily build intuitive user interfaces with Flex which connect to the cloud platform and CRM data. These applications can be deployed either in the browser or on the desktop using Adobe AIR. When utilizing Adobe AIR, the applications can still function when users are disconnected. Later, when users reconnect, the changes are synchronized with using the LiveCycle Data Services synchronization engine.

Being able to connect Flex applications to / has been possible (and easy) since I co-created what was originally called the Flex Toolkit for Apex. So while it has been possible to build Rich Cloud Applications for a few years, today’s announcement is significant for a few reasons:

  • Adobe and Salesforce are now officially partnered together around Rich Cloud Applications
  • Much better, officially supported developer tooling
  • Much better offline data synchronization

It’s really exciting to see how the vision of Rich Cloud Applications is becoming reality!

If you’d like to learn more or try out the new tooling check out these resources:

Another great way to learn more is to sign up for a Webinar / Tech Talk that I will be co-presenting.

Let me know what you think about this exciting new partnership and developer tooling.

My MAX 2009 Sessions

MAX 2009 is coming fast! It’s going to be another great event with tons of great speakers and after party fun. Here are my sessions this year:

Also Drunk on Software will be there filming some episodes.

So this is certainly a MAX you don’t want to miss! I hope to see you there!

Also check out the very cool MAX Widget (there are some funny facts about me in there):

Protected Messaging in Flex with BlazeDS and LCDS

UPDATE: BlazeDS 4 and LCDS 3.1 now have built-in support to disallow subscriptions to wildcard subtopics. Just set the following parameter on the messaging destination’s server properties:


You no longer need to use the ProtectedMessagingAdapter from the code examples below in order to protect your messages.

One of the great things about Flex is how easy it is to set up publish and subscribe messaging using BlazeDS, LCDS, or other various server technologies. Basically a Flex application can be either a Consumer of messages from the server, a Producer of messages to the server, or both. The channels that are used for the actual transport can vary dramatically depending on the needs. Here is a great blog that explains the different transports. No matter what transport / channel is used the API in Flex is the same. If you’d like to see how to use those APIs check out this video I recorded.

Many times with pub/sub messaging the messages should only be sent to a subset of the subscribers. There are two ways to achieve this in Flex – either using a subtopic or a selector. Subtopics allow simple dot separated expressions such as “stocks.ADBE” which would allow Flex clients to subscribe to only messages about the ADBE stock. A Flex client could also subscribe to wild card subtopics like “stocks.*” or “*”. The developer usually hard codes the subtopics (if any) that an app will use.

Subtopics seem like a great way to send point-to-point or point-to-group messages. To send a message to a particular client it’s as easy as setting the subtopic of the message to a special complex token – usually a generated UID or the server’s session ID. The subscriber then subscribes to a subtopic with that particular complex token and none of the other clients listening on that messaging destination will receive that message. Or maybe they can…

A malicious developer could easily determine the endpoint being used by an application. After discovering this they could also very easily create a Flex application that subscribes to the “*” subtopic of a messaging destination. Then the server would send them ALL of the messages on all of the subtopics for that destination. Pretty scary stuff. To see an example of this follow these steps:

  1. Open the test application
  2. Open the hacker application
  3. Click the send button in the test application
  4. Watch the message appear in the regularDestination output panel of the hacker application

Both panels use the same messaging API and same subtopic to send and receive messages. However the protectedDestination uses a customized Messaging Adapter that doesn’t allow subscriptions to subtopics containing a wild card (“*”). Here is the Java code for the ProtectedMessagingAdapter:

package com.jamesward;
public class ProtectedMessagingAdapter extends ActionScriptAdapter
  public boolean allowSubscribe(Subtopic subtopic)
    return !(subtopic.containsSubtopicWildcard());

Here is an example of how to use the new adapter in the messaging-config.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<service id="message-service" 
        <adapter-definition id="protectedMessagingAdapter" class="com.jamesward.ProtectedMessagingAdapter"/>
        <channel ref="my-polling-amf"/>
    <destination id="protectedDestination">
        <adapter ref="protectedMessagingAdapter"/>

If you are using subtopics (or selectors) to protect messages from being sent to the wrong people then I highly recommend that you use my ProtectedMessagingAdapter or something else so that malicious hackers can’t snoop on private messages or send impostor messages. In my demo I run both the test app and hacker app on the same server but this can be done in other ways (such as proxy servers or local apps). Also authentication may not protect you because a malicious user might also be an authenticated user. So the only solution is to really protect destinations from subscriptions to wild card subtopics.

I hope this is helpful for those using messaging. Let me know what you think.

RTMP Spec To Be Opened

A little over a year ago Adobe opened the AMF spec. Now Adobe has announced it will be opening the RTMP spec! Wahoo!!! This is big news for Flex developers! For those that don’t know, RTMP is the streaming protocol used for streaming video and audio in Flash Media Server and for streaming data in LiveCycle Data Services. The spec is expected to be published first half of this year.

Take the Tour de Flex

Over the past few months Greg Wilson, Christophe Coenraets, and myself have been hard at work on a secret project. So today we are proud to announce the new Tour de Flex has just gone live! Tour de Flex showcases the capabilities of Flex, BlazeDS, LCDS, Adobe AIR, and Flash Player (now collectively called the Adobe Flash Platform).

Like the old Flex Component Explorer, Tour de Flex can be used to find components. But it goes way beyond just out-of-the-box Flex components. This first release contains 217 components and samples including popular Cloud APIs like and Intuit, numerous community components from people like Doug McCune and Tink, commercial components from companies like ILog, and numerous other goodies. If you find something missing you can submit it!

Also in this release is an Eclipse / Flex Builder plugin which allows you to find components from inside Flex Builder!

We hope the Tour de Flex will provide an easy way for you to find components and see what is great about the Adobe Flash Platform. Give it a try and let us know what you think!