We would like to take a minute to personally update you on the progress of our book. Although we are running behind the originally estimated release date, the end product will be a much better learning experience. From the beginning we have been continually refining the book and have taken the great feedback we’ve received to align the book more closely to your thoughts and insights. If you are receiving this letter and were part of the reviews, THANK YOU! Much of the feedback received, all helpful, really matched with how we (the authors) were feeling and helped us to really home in on what we felt would be important to include. Here are just some of the things that can be expected out of the new and improved Flex on Java.

Developer accessibility
When we started the Flex on Java journey we wanted to write a book that would assist Java developers in refactoring Java applications with the richness of Flex. Unfortunately, the sample application wasn’t a good fit for everything we wanted to teach and was absorbing too much of our time trying to make it work properly for the readers. The sample application was an open source product that was not easy to download, build and go. This issue caused us to rethink our approach and we turned to Matt Raible’s AppFuse framework that is aimed at helping developers build applications quickly and efficiently. AppFuse makes deployment and creation of the sample application a breeze and also opens the door to developers who are new to Java. It allowed us to focus more on the topic of integrating Flex with Java while broadening its audience to those who are not Java or Flex gurus.

Hit the ground running (faster pace)
The free chapter available will become an introduction to the book and chapter 1 will now get readers rolling with development on the first page. Chapter 1 will begin with developing the server-side application with the AppFuse framework and then quickly begin integrating Flex in chapter 2.

Deepening focus on Flex integration with Java
The faster tempo and more narrow focus on the topic of Flex and Java integration allows us to quickly go deeper in that topic. We will discuss how to use BlazeDS to connect to the Java server-side including POJO services, Spring services and Spring security in more detail. We will also include working with real-time JMS applications utilizing the Flex and Java APIs.

More focus on scalable frameworks
Good developers move from technology to technology and look for frameworks that allow them to avoid the common problems when designing an application. Frameworks for doing both dependency injection for creating loosely coupled applications and Model-View-Controller (MVC) will be explored in more detail. Frameworks such as Spring ActionScript, Cairngorm, and Pure MVC (and possibly others) will be demonstrated.

House cleaning
There are other topics like building the application with Ant and setting up continuous integration that are important but not part of the main gist of the book, so we moved those topics into the Appendices of the book. There are other housecleaning items that are being performed to make this the best book possible on integrating Flex with Java.

We hope that you will be delighted with the upcoming changes to the book. Please feel free to provide us with any feedback you may have for us. Thanks again!

Sincerely,
BJ Allmon and Jeremy Anderson
Authors of Flex on Java

If you’ve never heard of GroovyMag, I strongly encourage you to check it out.  It’s a very reasonably priced magazine for Groovy and Grails developers available as a PDF for the low price of $5 per issue.  Considering there are almost no advertisements and each issue is packed with great content from authors such as Chris Judd, and of course now yours truly.

My co-author (BJ Allmon) and I had originally intended to leverage an existing application that we would refactor to use a Rich Client interface so that the experience would more closely resemble the audience we were originally targeting; the Java developer who would be tasked to integrate Flex with their existing application.   So after much thought and some suggestions from some co-workers, we decided on XPlanner would be a good candidate.  XPlanner was a project that hadn’t seen any real development in a couple of years, it’s infrastructure was not chosen with Flex in mind, and it was a sample application that we really wanted to make work.

Unfortunately the more we tried to make XPlanner work with Flex, the more we realized this was a bad idea.  The SOAP implementation had to be tweaked because for some reason when doing inheritance with Axis the ordering of the elements in the SOAP response are out of order, which screws up Flex’s parsing resulting in some elements being returned as null when unmarshalling the objects in ActionScript (http://bugs.adobe.com/jira/secure/attachment/17509/Flex3Bug.txt).  That was fixed fairly painlessly but once we got to the point where we were attempting to integrate with BlazeDS we quickly learned that most of the functionality we needed to populate the screen was not exposed as a service, but rather many of the CRUD operations were implemented in JSP custom tags, so we were forced to have the reader implement those in order to follow along.  It was becoming apparant that this wasn’t going to work out.

After much reflection over the holidays, I had come to a solution.  We would remove XPlanner from the book as a sample application, even though I was dreading the thought of having to build up a sample Java based web application from scratch so late in the game.  I was longing for some sort of framework that would help me get a web application up and running, and quickly, kind of like Grails but for Java and not Groovy.

Then the answer came to me, AppFuse.  For those of you not familiar with AppFuse, it’s basically a skeleton Java web project that provides many services for you out of the box.  You then plug in all of your application specific code and build on top of AppFuse to create your application.  This was the answer I needed.  This also allowed us to now address one of the other comments that we received from our review; our book had assumed some high level of Java and Java web application knowledge effectively alienating the Flex developer who wanted to break into Java web development on the back-end.  It also allowed us to not stray too far from our original goal of an existing application for the basis of a sample application.  Even though we’ll now be building up the Java portion of the sample application in our book instead of using an existing one, by leveraging AppFuse we’re following many best practices for Java web development that make no assumptions about the view technology being leveraged, and developers with existing applications they want to refactor should easily be able to adapt anything in the book to their specific environment.

I must admit that I’m getting very excited about this new direction, I had rediscovered AppFuse which had played a role in me learning Spring and Struts, and helped me to refine my views on what good Java web application architecture consisted of.  Even though we’ll now have to refactor half of our book to accomodate this new sample application, I’m confident that it will not only improve the quality and clarity of the book, but it will also open up the book to a whole new audience that we weren’t targeting before.

Soon after I began spiking the sample code for our application, I discovered that a bug in the way Apache Axis handles SOAP inheritance would force us to not be able to connect to the Web Services without some modifications.  This is not including all the changes we would need to make to integrate the BlazeDS server with XPlanner so we could take advantage of the AMF binary protocol.  So we were forced to either host a modified version of the XPlanner sources ourselves, detail the changes that must be made in our book, or attempt to contact the XPlanner maintainers to get the changes introduced to the main project.  I really didn’t like the idea of forking the project, and felt that providing a patch and making the reader apply that patch before following along with the code examples was less than desirable also.  So I decided to attempt to contact the project maintainer, and after a couple of unsuccessful attempts I finally heard back from the maintainer Jacques.

So to make a long story short, it looks like I may be taking over maintenance for the XPlanner project.  I am currently working with Jacques to figure out what needs to be done in the short term to get the latest release out the door, which is over 2 years in the making.  I’m very excited about the opportunity to breathe some life back into the XPlanner project, and it would appear that the direction that I envisioned for XPlanner falls in line with the direction that Jacques was hopeful to take before other commitments tore him away from it.

How we got here is kind of an interesting story. I’ve always been a big fan of RIAs and had looked at Flex a few years back in one of my “I hate HTML” phases and really fell in love. Unfortunately the price tag was really expensive and could never show a ROI on this really cool framework that provided such a rich user experience. Fast forward a couple of years and Adobe has acquired Macromedia, and decided to open source the Flex Framework as well as create an open source fork of their LiveCycle Data Services and now it is possible to do Flex development without spending a dime. So I decided to pick up a Flex book and re-acquaint myself with RIAs, only to struggle to find a good title that would show me how to integrate Flex into my everyday job as a Java developer.

A few months back I had somehow gotten on Manning’s list of people they call on to do manuscript and proposal reviews, and I had reviewed a proposal on Flex and AIR, and it looked interesting. Come to find out the authors pulled out at the last minute, and they were looking for someone to write a title on Flex. So, for whatever reason, I’m still not quite sure exactly why, I opened my mouth and volunteered. After a couple of exciting conversations with the publisher about what I thought would make a good Flex book, I decided to recruit BJ and put together a proposal.

Keep your eyes peeled for the MEAP to show up on Manning’s site in the near future. In the meantime I plan on blogging about the experience, when I’m not up to my ears in writing this book.

In 2002 Macromedia used the term “Rich Internet Applications” (RIA) to describe the next generation of web applications that have all of the benefits of a traditional desktop application, with the flexibility of being deployed via the Internet.

However, it’s 2008 and RIA has not been able to penetrate the business application sector with any real success. The old days of RIA are history. (Maintenance nightmares, weird or no unit testing, and little friendliness toward other agile developer practices.)

With a RIA framework like Adobe Flex it’s now possible to unit test RIA applications and even write tests first. It’s possible to connect up to a CI server just like server-side code and pick up coverage stats. It’s possible to evolve a simple design incrementally and emergently.

The speakers will model how to make standard agile development practices work in the RIA world: Refactoring, Test First Design, Simple Design, Continuous Design, and Continuous Integration & Automated Builds.

The bottom line is many businesses have invested much time and money into their existing applications and their staff. For this reason, this session will guide the attendees on how to refactor an existing web application with familiar server-side technologies. We’ll show how to integrate Flex into existing applications in order to build a next generation application that will delight users.

Rather than trying to teach the basics of Flex, the speakers will demonstrate how to develop robust applications leveraging the Flex framework in concert with enterprise technologies like Java. These applications can be deployed not only to the web but also to the desktop using the Adobe Integrated Runtime (AIR).

 

Process/Mechanics

 

Refactoring to RIA’s will be a demonstrative (tutorial-like) session geared towards Java developers that would like to refactor existing applications in an agile way. Test First, CI, and other friendly agile practices will be key in making this possible.

The session will consist of live code and practice demonstrations leveraging an already existing application. Requirements for creating a new rich client interface will be explored and code will be refactored in a Red/Green/Refactor manner.

So I’ve decided to start a Google Code project called agile-flex, where a couple of other developers and I will attempt to build some agile tools for the Flex framework, starting with a test runner that will help enable continuous integration for Java, .NET, or even just plain old Actionscript. The runner will likely be based off an article I found from Aaron Spjut here. In a nutshell we will create a test runner in Adobe AIR that will generate XML output similar to JUnit and NUnit for the CI server to be able to interpret. This will also enable the generation of report artifacts using the JUnit Report tasks or even a custom XSLT if desired. I’ll post more details as the project continues.

UPDATE… The Flex-Mojos project now fulfills this need, so I’ve deleted the Google Code Project that we started for this.