The Art of Software Development

In my first posting concerning BlazeDS, I described the effort it took for me to convert from remoting with GraniteDS to remoting with BlazeDS. I have been expanding my knowledge of BlazeDS by studying messaging and plan to write a posting that extends the examples given in the turnkey distribution to include an honest-to-goodness JMS example. But first I would like to share what I have learned since my initial BlazeDS posting.

The BlazeDS product suite is extremely well documented. Adobe has written a BlazeDS Developers Guide that is over 170 pages long and it is chocked full of good information (they also include a turnkey download distribution that demonstrates the various forms of remoting and messaging). Now like all good developers I’m sure you all read the documentation from beginning to end before you ever dive into code. Right. I like to get the big picture first then start working with the product so that I can wrap my brain around the concepts a bit easier. I will then go back in fill in the details by reading the documentation again. So as a practical introduction to BlazeDS, I converted an existing application from GraniteDS to BlazeDS.

My first posting included a Java class file that can be used as a factory to access your Spring application context. I thought I had stumbled upon the Holy Grail! In truth, that code is available in several locations. If one happens to make it a section called The Factory Mechanism in the livedocs or Chapter 8 of the BlazeDS Developers Guide (page 87) there is a very clear description of how to write a custom factory that allows you to integrate BlazeDS with any component creation technology. This same chapter includes a listing of the very Java class source that I posted. I also discovered that on the Flex Exchange Beta website there is a download titled Spring and Flex Integration by none other than jvroom that includes the exact same source code. We’ll hush my puppies! So it looks like this factory class has been in the public domain since July 2006. How is that for filling in a few details.

The second item I was a bit confused about initially was the use of adapters in BlazeDS. I admit in the context of remoting the need for an adapter to convert to and from ActionScript to Java is a no-brainer. I can’t imagine what other type of adapting would be required with a Java backend. As I have been studying messaging, the adapter classes make much more sense. When I looked at the source code for the ActionScriptAdapter and the JMSAdapter the light bulb came on inside my head. Whereas the ActionScriptAdapter simply echoes messages back to subscribers, the JMSAdapter is used to plug into a JMS queue on a J2EE application server. Very nice in concept, now I need to see it in action!

Anyway, I guess the take away for me is that the BlazeDS software is very sophisticated and very powerful. That’s why it needs a manual that’s over 170 pages long. The more I work with it and the more I study, the greater the cool factor in my mind. Thank you Adobe for open sourcing the remoting and messaging components of Flex Data Services! I would never have been privy to the great code that your staff wrote because I believe hell would have had to freeze over before my company would purchase FDS. Thanks again and stay tuned for an example of JMS messaging.