Understanding the ColdFusion Flex Relationship

I've just been involved in a long thread with an individual who wanted to better understand the relationship between ColdFusion and Flex. Apparently, this is still a source of much confusion as I was asked similar questions at a user group earlier this week. So, I went back through the entire thread and distilled the relevant portions into the following, I hope this helps.

First of all, Flex is a server product that allows developers to generate Flash client-side SWF files on-the-fly by writing plain text source code files with tags in them. There are, therefore, similarities between ColdFusion and Flex:

* Like ColdFusion, Flex is a Java application deployed on top of J2EE servers. (A .NET version of Flex is planned for some future date).

* Like ColdFusion, applications are created as plain text files, and are placed on a server where there are compiled and processed on demand.

* Like ColdFusion .cfm files, Flex .mxml files are primarily tag based (although the language used is MXML instead of CFML).

As I said, there are similarities, and thus the confusion. But, there is also a major difference between ColdFusion and Flex. ColdFusion is an application development platform, it provides language elements and features for everything from programmatic flow control to database integration to Internet protocol support to UI generation to SOAP and XML processing and a whole lot more too. Flex, on the other hand, does not do any of this. Flex has one primary objective, and is laser focused on achieving it. Flex is all about the presentation layer, it is a presentation server and only concentrates on generating presentation front-ends and user interfaces.

This distinction is important. If you need database access from within a Flex application (and most will) then you will need a back-end to provide that access. If you need to generate e-mail messages you will need a back-end that knows SMTP. And if you need to access Internet protocols, implement business logic processing, handle user authentication and authorization, and more, you will need a back-end to do all that work.

This is not limitation of Flex, this implementation is deliberate and by design. As a Flex developer you are free to use the standard back-ends that work for you, including the back-ends you have already invested in. Flex simply provides you with a whole new way to create front-end applications, leveraging whatever investment you have already made (or will make) in back-end systems and technologies.

How does Flex talk to these back-ends? SOAP, straight HTTP calls, invoking Java objects, there are several options available to you. And what back-ends are supported? Basically, anything that can respond to SOAP calls, HTTP requests, and Java object execution. In other words, just about anything. And that includes ColdFusion. All versions of ColdFusion, any editions on any platform, can be used as back-ends for Flex applications. (Although ColdFusion MX is far better suited to be a Flex back-end than are prior versions, due to the Java underpinnings and the integrated SOAP support).

So, now that the differences between ColdFusion and Flex are clear, as is the understanding that these servers do not overlap and are in fact complimentary, what exactly is the technical relationship between them? There are two answers to this question, and they are quite different:

1) As already stated, Flex can leverage ColdFusion as a back-end, ideally via SOAP calls to ColdFusion Components. Any ColdFusion code exposed as a Web Service can be used by Flex, and very easily too. Flex understands ColdFusion data types, include queries, so, for example, a Flex DataGrid can be populated by a CFC method that returns a query without needing to massage the returned data at all. In this form of integration Flex and ColdFusion need not be installed on the same J2EE server, in fact, they need not even be installed on the same physical box. Flex can talk to any ColdFusion server anywhere (subject to security restrictions and settings). When a user requests a Flex page (a .mxml URL, not a .cfm URL) a Flash application is returned (by Flex, not by ColdFusion) and executes within the Flash player. That application then makes calls to ColdFusion for data and processing (probably using SOAP or Flash Remoting). From ColdFusion's perspective the flow and integration is no different from that of traditional Flash SWFs created using the Flash IDE.

2) It is also possible for ColdFusion pages (.cfm files) to render client-side SWFs dynamically (in much the same way as ColdFusion usually renders client-side HTML). How? Via JSP tags. CFML code can invoke JSP tags (which must first be imported into ColdFusion using the tag), this is a core ColdFusion feature independent of Flex. What makes it relevant to this discussions is that Flex comes with a JSP tag interface, allowing Flex tags to be used from within ColdFusion (and JSP) pages directly. In this form of integration Flex and ColdFusion must be deployed and running on the same server (the same J2EE server instance, that is), and so this does require ColdFusion Enterprise installed on top of a J2EE server (and not the standalone installation configuration). Using this interface users would not request .mxml URLs directly, they would request .cfm files as they usually would. The ColdFusion generated output would contain Flex generated SWF (which in turn could make calls back to ColdFusion if needed).

There are advantages to each integration option, and the decision as to which to use will (and should) likely be driven by application needs more than anything else.

But having said that, both options are viable, and both allow the creation of well designed n-tier applications, with Flex at the presentation tier, and ColdFusion at the business and logic tier.