Flex Configuration Demystified: services-config.xml, Destinations, and Channels

For a long time, my IM status really was "LCDS configuration sucks," and I meant it. I found its XML files very intimidating, and I deal with XML-based frameworks on a daily basis! Over the past week, I've come to realize it's not that bad. More than anything else, it was the documentation that got me a bit backwards. I don't know if it has to do with its style or my method of comprehension. It seems to immediately dive in to minute configuration detail without ever giving a high-level overview of what all the stuff it talks about actually is.

So here's the deal:

When you want Flex to talk to ColdFusion, LCDS, or Blaze, there's really only three things you need to know how to set up.

Channels

A "channel's" just which network connection to use to talk to the server. Simply put, it's the URL of the servlet you'd like to talk to, such as "/flex2gateway" for ColdFusion Flash Remoting or "/messagebroker/amf" for Blaze along with the type of channel, such as AMFChannel (wants to use AMF, a binary serialization of ActionScript objects) or HTTPChannel (wants to use AMFX, which is an XML serialization of ActionScript objects).

Destinations

A "destination" is a server-side Java class that you'll talk to with a RemoteObject, Consumer, or Producer. A destination typically has a "source" configured, which is the name of the class to which to speak. It's bit funky for ColdFusion, though, in that the source is typically stated in MXML (if you look at ColdFusion's services-config.xml, you'll see that the source is "*").

Adapters

Adapters provide bridges between the messaging infrastructure and server-side code. For the most part, I've used to built-in adapters, but I have built custom Java adapters for the purposes of intercepting and manipulating realtime messages before they're sent out to their channels. A great example is the CFEventGatewayAdapter, which allows incoming Flex realtime messages to interact with ColdFusion Event Gateways.

So why the ugly XML?

The XML files that blow minds (services-config.xml, remoting-config.xml, etc.) aren't actually necessary. They're handy, in that they provide a topic-specific syntax for describing available services to Flex applications, but there's nothing preventing you from using server-side bootstrappers and client-side ActionScript code to configure it all. The code would just become a mess in a big hurry!

Here's a handy, birds-eye view of these files, leaving a few files and a bunch of subtopics (security) out and focusing on the core:

1. services-config.xml

   This file's the master: if you look inside, it actually includes the others, such as remoting-config.xml. It'll typically define default channels for destinations to use, logging, session semantics such as timeout, and other aspects of Flex remoting / messaging that apply to all services.

2. remoting-config.xml

This one just an include> that provides a place to configure remoting (RPC-style, RemoteObject) destinations. It may define adapters specific to these destinations.

3. messaging-config.xml

Like remoting-config.xml, this is just another include that provides a place for configuring messaging (realtime) destinations. It may define adapters specific to these destinations.

Conclusion Hope this helps clarify a bit of what all those terms are, and why all of those XML files exist! I've found the BlazeDS documentation to be of the most help for further information, although it's a terribly dry read.