Learning Flex – Lesson 18, Accessing Server Side Objects

where <mx:WebService> uses XML based transfer, <mx:RemoteObject> uses the binary Action Message Format (AMF) to communicate between server and presentation layer. This means it’s faster (see James Ward’s post on this). Another advantage is the capability to pass native objects directly which saves you from translating basic generic Objects to your richer custom classes.

Flex supports communication with ColdFusion, Java (via Livecycle Data Services (LCDS), the open source BlazeDS or other 3rd party apps such as GraniteDS) or PHP (Zend Framework) and .Net (Fluorine FX) . The AMF spec is available here so other implementations may also be available.

This post will deal with configuration basics but you can look at some of my prior posts for some references and help with working with BlazeDS. The other framework sites linked to above will help you with the alternatives.

You need to use a configuration file (generally services-config.xml) to define how to make calls to the server. To use this in a standalone app (ie not deployed on a server) you need to specify it’s location in the additional compiler arguments using the -services switch.

This configuration file will define three main sections as follows:

Technology Adapter

This defines the class that translates the AMF message for the technology you’re using (Java PHP etc). The <adapters> tag contains an <adapter-definition> tag which has an id, class, and optional default (boolean) attributes.


This section defines the location of the remote server and the type of channel to be used (AMFChannel, SecureAMF, etc). A <channel-definition> tag has an id and class attribute and contains an <endpoint> tag which contains a url and class. The endpoint url may make use of special tokens {server.name}, {server.port} and {context.root} which are replaced with the server name, port and web app context root based on the url the swf is served from.

Depending on the type of channel, it may have additional parameters declared within a <properties> tag. A <default-channels> tag may be used to specify a <channel> tag with a ref attribute which is the id of the default channel to use.

Destination Handle

This is what the Flex code will refer to when using a remote object. A <destination> tag has an id attribute and contains a <properties> tag which will have a <source> tag to define either * (meaning all) or a specific class the destination is allowed to deal with on the server. A destination may also specify it’s own channels if it doesn’t use a default.

Defining a Remote Object

A <mx:RemoteObject> tag has an id attribute to reference it by and a destination attribute which is the id of the destination to use from the configuration. If you did not specify a specific class in the destination config, the source attribute should be used to specify the server class to use. You may also define result and fault event handlers. showBusyCursor is a boolean attribute that can be used to graphically indicate you’re talking to the server. It’s purely graphical and does not stop the user from interacting with the application.

As an alternative to the result event handler, you can bind directly to the lastResult of a remote object method call similarly to the way you can for a HttpService eg {ro.getResultList.lastResult} where ro is the id of my remote object and getResultList is a method on the server object. You call a remote object method in the same way you do a web service call.

Mapping ActionScript Objects to Server Objects

It’s possible  to define a mapping between an ActionScript class and it’s equivalent on the server such that when an object arrives from the server, it’s automatically converted into the ActionScript version rather than a generic Object.

To achieve this, a RemoteClass metadata tag is placed before the class definition with an alias to the server side version for example:

[RemoteClass (alias="com.mycompany.MyClass")]
public class MyClass{...

To prevent a property from being sent to the server use the [Transient] metadata tag above the declaration of that property.

As long as the number of properties and their names match, the mapping will occur. If either version of the class changes, Flex will revert to returning a generic object.


Flex Security

If you’re using BlazeDS/Livecycle or some other backend integration services, you might want to take a look at deblaze. It’s a security tool that can be used to figure out exposed remote methods and other info. It gives you some examples about how you could use it and pointers to make things more secure.

One more thing…

One thing I omitted from my previous post is I developed this app when I still had my Flex Builder trial. This is important because when you’re using remote objects in Flex Builder, you specify the server you’re going to connect to as part of your project setup and this gets compiled into the swf that’s created.

Obviously that’s not going to help you if you’re not using Flex Builder (and having your server pre-defined at compile time is a bit of an issue if you’re a “real” developer working with dev, test & prod environments).

I was thinking about digging through the documentation to figure something out but Christophe Coenraets came to the rescue with a post on externalizing your service configuration that has it covered.

Flex, Java & BlazeDS

Coming from a Java background, BlazeDS really interests me. Basically it’s Adobe’s open source version of it’s LiveCycle Data Services (LCDS). Basically they’re a set of JAR files deployed on your server to improve the comunication between a Java backend and a Flex presentation layer by comunicating via AMF (Action Message Format). You can always comunicate out of Flex using http services and consuming XML but that’s not the fastest way to work.

James Ward’s site has some benchmarks for comunicating via AMF with BlazeDS.

Chirstophe Coenraets has lots of great stuff on his blog including plenty of BlazeDS stuff. This post he wrote for Adobe Devnet has everything to get you started using BlazeDS including a download of a pre-configured Tomcat server and examples to work through.

One thing to note – if you can’t get the database update exercise to work, that’s because the example has the update statement created but never executes it.

Adobe doesn’t go out of it’s way to outline the differences between BlazeDS and LCDS but Sujit has a nice clear post here that does a good job explaining it.

With the different channel choices available, I think this post from Damon Cooper’s blog does a good job of exploring the pros and cons of each.