Andrew Powell

A few months ago, I started a project to make a framework for ColdFusion to enable its functionality as an Enterprise Service Bus (ESB).  I kept running into roadblocks in my mind as how to structure things, but I realized something.  Everything I was trying to do to make ColdFusion an ESB was simply hindering tasks that were already easy to do.  ColdFusion, out of the box, can function as an ESB.  

It wasn't always this way, but over the years, with the addition of things like JMS gateways, .NET integration, HTTP, and FTP integration; it's easy to create workflows that receive data from an input, processes it, and sends it to another destination.  ColdFusion 9 enables this even more so with the addition of Sharepoint integration. 

Why worry about installing something like Mule?  ColdFusion already does everything you need it to do out of the box.  ESBs are the next generation in integration.  ColdFusion just makes it easier and faster than traditional Java or .NET based solutions. 

The early bird pricing for Flash Camp Atlanta ends in less than 24 hours!  Tickets are on pace to sell out soon, so if you don't want to pay more later, go sign up now.  The early bird pricing is dirt cheap, only $40 for the main session and $15 for the introductory session ( an intro to Flash, Flex, and AIR ). 

Here are the slides from my presentation this week at 360Flex.  I should have the updated samples into the SVN repository later this week.

http://static.infoaccelerator.net/files/FlexServerLib.pdf

Spring has been, is, and will continue to be the easiest way to deploy enterprise class services with your Java applications.  There is a common pattern to the way Spring lets you expose your beans as services.  What this means is that the methodology for exporting a bean as a Hessian service, a Burlap service, a WebService, or now, an AMF Service (via BlazeDS) is consistent.  This consistency is what BlazeDS needed to be accepted into the Spring world.

Until the release of the Spring / BlazeDS integration by Spring Source, Spring has always been a bit of an interloper when it comes to BlazeDS.  Sure, Jeff Vroom's SpringFactory has served many of us well for a long time, but it was always something extra that had to be added on to the BlazeDS configuration.   To make it work, the services-config.xml file had to be modified and you had to specify special properties within the remoting destinations of remoting-config.xml.  It was a lot of steps to make something that makes things simple work with BlazeDS. 

Using the Spring/BlazeDS integration, it is no longer necessary to touch anything in the services-config.xml (unless you're changing the channels) or the remoting-config.xml files.  It just works out of the box by exporting your spring beans just as you would for any other remote services.  This consistent methodology will make it easier for teams to choose to use BlazeDS, and in turn, Flex for projects.   It means that teams will get the benefit of AMF with, possibly, no refactoring of the service layer.  All one would need to do is generate the AS classes to match the resulting datatypes (XDoclet can help a ton here) and you're done with the middle tier.  This allows for more development time to be focused on the Flex layer instead of being mired in getting the middle tier setup.  

By becoming more like other remoting methodologies in Spring, it appears that AMF and BlazeDS are ready to become prime-time players.

This question has come up to me a number of times lately.   People are concerned that the Spring BlazeDS Integration will mean an end for FlexServerLib.  This couldn't be further from the truth.  There are two main reasons why this is not the end of FlexServerLib:

1. FlexServerLib Extends BlazeDS - The goal of FlexServerLib is to extend BlazeDS. Extending it does not just mean tight integration with Spring.  Yes, we do use Spring for a lot of what's going on under the hood, but that's more of a testament to the power of Spring than an indictment of FlexServerLib.  There are some things that Spring's project just won't do, like a MailDestination for Messaging.  Granted, we may port our solution to both stand alone BlazeDS and the Spring-integrated solution, but it is independent.  We are focused on extending BlazeDS, not just exposing destinations via Spring Beans (although that is nice).
2. Not Everyone Is Using Spring - As much of a shock as this can be, not everyone in the Java world is using Spring.  Some of our functionality that Spring will do easier, is not available to those using...say....EJB.  Well, we provide an easy way to expose EJBs as Flex RO destinations.  There is still a market for extending BlazeDS.