Andrew Powell

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.