jonr originally posted this on Jon Rose's Blog.

This post is a follow-up to my post last week were I noted some of my initial reactions to the Cairngorm Framework.

When I look at the overview diagram of Cairngorm, I just keep hearing Eddie Vedder exasperatedly saying, “… It just doesn’t feel like we have evolved at all – in 20 years…” I will admit he might not have been talking about software (but I still love Pearl Jam – so whatever). Audio Here

After writing some code with Cairngorm I am feeling less critical. I think the structure provided by Cairngorm makes sense to some extent – at least more sense than the overview picture provided. I would still love to see a much flatter picture and resulting implementation. Either way, I figured I would throw out a few suggestions that I believe would improve the framework and the potential perception of future Java developer converts to Flex sure to check it out.

We all love patterns, and the value in them comes from the shared understanding of a given pattern. My largest hang-up with the framework is the naming of some of the components, and I am less than convinced that they all follow the patterns they are named after.

I don’t believe the “Front Controller” is true to the pattern (nor should it be). There are much better ways in Flex to accomplish the benefits articulated in the Front Controller pattern. In the Cairngorm code it is just a simple dispatch mechanism. To me, the only real value of MVC is addressing separation of concerns (SoC). This pattern needs to go by the wayside, along with the thin-client architectures we are striving to replace.

To the extent we do need some dispatch mechanism to address the SoC and a level of true decoupling, I actually think that Cairngorm falls a bit short. In the store example application, the ValidateCreditCardCommand uses the executeNextCommand function to chain commands by hard coding the next event. Certainly, this is where we could gain value from a central dispatch infrastructure. Also, the controller doesn’t really do anything except map an event to a command within the class file (there is little-to-no benefit in this).

So, in terms of trying to providing a constructive suggestion, I think Cairngorm should rename the “Front Controller” to “dispatcher,” and provide a more robust mechanism for mapping, and the chaining of multiple commands to a given event. In Flex, we really just need M & V or M-V-D (dispatch).

In addition, the Service Locator pattern could also stand to be renamed. Although, it is of far less consequence than other issues. I have had a bit of a hang-up here in explaining Cairngorm to other Java developers evaluating Flex, as it doesn’t really do any lookups per the pattern. It really just encapsulates the client side configuration for accessing remote services. So, once again the name could be considered misleading, and the Cairngorm framework should consider renaming the Service Locator.

jonr originally posted this on Jon Rose's Blog.

I have been looking at the Cairngorm Flex Application Framework. Cairngorm is a MVC framework implemented in ActionScript 3.0 to support development in Flex.

As a Java developer, I have quite a bit of exposure to the MVC pattern, and I definitely want to have a healthy Separation of Concerns (SoC) within the Flex applications I am building. However, I am a bit surprised that I have not found much push back online from the Flex community on introducing the high level of abstraction that comes with the Cairngorm framework.

I absolutely believe in having some consistent structure for separating view logic from model logic (and so-on), but it just seems that Cairngorm could be a whole lot flatter. My first pass at writing code with the framework takes me back a few years to when my peers and I where implementing the Session Facade pattern in web applications that where deployed in a single container, and were never going to have more than 10-20 total users. In hindsight, this was obviously totally unnecessary and an inappropriate use of the design pattern. It seems like Cairngorm could be taking us down a similar road here.

Regardless, I have decided to use Cairngorm in my first Flex application (it seems to be the Flex MVC framework with Adobe’s endorsement), as I hate spending a lot of time writing my own plumbing, especially when I am still getting up-to-speed on a language (i.e. Flex). However, my usage of the framework comes with a number of concerns upfront. I thought I would outline my initial reactions and concerns, and see if they still hold up after using Flex and Cairngorm for a while.

The first resource I used to gain an understanding of Cairngorm was their overview diagram of the ‘Cairngorm 2.0 Microarchitecture,’ found at: http://www.cairngormdocs.org/cairngormDiagram/cairngorm2_rpc.swf.

My immediate reaction after viewing the diagram was, ‘Wow! The whole Core J2EE Patterns book duplicated. Really?’ It would appear that the Cairngorm developers owe Deepak Alur, Dan Malks, and John Crupi a big thanks for their contribution of the Core J2EE Patterns. As someone who has used, and at times abused these patterns, I am not completely sold that this is an appropriate place to utilize them (at least not to this extent).

My first question is, why do I need this level of abstraction when there is a natural SoC in the client-server like programming model of Flex? Think back a few years to early web development in Java. With Java I can issue SQL statements directly from a JSP (and many developers did/still do). Most everyone agrees this is bad, thus the Java community responded with countless MVC frameworks to enforce more discipline and give direction to misguided folks who would do things like issuing a SQL statement directly from a JSP.

Flex does NOT offer any API’s for database access, as it is just a client-side presentation framework. If you want to access an SQL database you have to go through a business services layer (e.g. SOAP, Data Services, etc…) that encapsulates the logic for accessing the appropriate data. Thus, you have a natural SoC in Flex that does not exist in pure Java deployments.

My next question, why introduce a Front Controller into an event programming model like Flex? The Front Controller seems to be a perfect fit for Struts, as it was building on Servlet/JSP development where there was little notion of state and no event model. In addition, the entire flow can be controlled in a Flex based application, unlike traditional browser based deployments where a user could potentially jump into an application at any point by simply providing the URL.

Also, in the example applications the Front Controllers do not seem to be doing anything except dispatching custom events. No security checks, no decision points on redirecting the view (as Flex provides View States for this), none of the typical benefits outlined in the pattern.

Moving through the diagram, the Business Delegate makes good sense to me as a way to encapsulate interactions with the server. Although, I am surprised that the logic that ends up in the Commands (in the example applications) isn’t just part of the Business Delegate. I tend to view the delegate as a client that makes the call, does any necessary translation, and returns meaningful data types to the client side application. The delegates in the samples pretty much just provide a handle to the remote services, and the Commands make the call using the Delegate and return the meaningful types to the Flex application.

The Service Locator seems to make good sense, as a way to organize and access the different services needed for a given Flex application. Although, it does not appear to be a true Service Locator, but just a way to encapsulate the client side configuration for accessing the remote services.

I think that the custom events and value objects also make good sense, as they would be apart of any implementation that moves the model and flow logic outside of the mxml components.

Anyhow, after all of my analysis… I do still plan to use Cairngorm for an implementation I am coding in Flex, and then review my initial thoughts outlined in this post. Although I think it is overkill, I do believe it provides me the SoC I am looking for, and is good enough for right now. So, on to writing code!!!

Resources

http://www.cairngormdocs.org/

jonr originally posted this on Jon Rose's Blog.

I am a bit surprised to find out that ActionScript 3 doesn’t allow me to declare my constructor as private or protected. So much for implementing a true Singleton.

jonr originally posted this on Jon Rose's Blog.

When it comes to Rich Internet Applications (RIA), I am way behind to some, and way too far out there for others… Oh well!

It is time to completely embrace the RIA model and put to bed the old Request/Response type model of building web applications. My conclusion is simple, no longer do we have to train our customers to be disappointed with the final product when purchasing online software. The tools are finally good enough to give our business stakeholders and users the ‘rich’ applications they have been asking our industry to build for all these years.

Until recently, I have avoided the ‘Rich Internet Applications’/’Web 2.0’ craze, mostly because I saw Ajax as the primary method available to Java developers, like myself, for enhancing web based applications. I am finally ready to get onboard, but I am still uncomfortable with using the Ajax techniques on a large scale.

In this post, I am asserting the underlying assumption that the majority of the online user interface work going forward will be done in a Client Server like model over the Internet (e.g. Ajax and the like). As far as I am concerned, debate around the question of continuing to use JSF and Struts like frameworks is pretty much over, and any further discussion is for someone else’s blog. We should all be excited that we finally have better ways to build online applications. For me, it has been about finding a method that will enhance the user’s experience, but not be a complete pain to me as a developer.

Going forward, my personal platform of choice for building online user interfaces will be Adobe Flex. Adobe’s recent 2.0 release of Flex finally gives developers a robust solution for building ‘real’ applications and delivering them over HTTP through a browser.

I think Flex is cool and you can clearly build ‘sexy’ applications using it, but really who cares? I see way better reasons to utilize the Flex 2 framework as a Java developer:

1. Of most importance, Flex provides the ability to dramatically improve the end user’s experience, build complex features with ease, and improve productivity (of both the programmer and end user).
2. Tools:
   1. It builds on the tools Java developers already know.
      1. Eclipse IDE Plug-in.
      2. Ant build tasks for command line and automated builds.
      3. Flex and/or Granite Data Services used for easy Java integration, which deploy to a J2EE Servlet container.

3. Runtime:
   1. Everyone computer already has the Flash Player and users are used to interacting with Flash based content.
      1. This does matter!!! Overtime it will matter less, but it takes time for users to adopt a new runtime, and as we all saw with Applets it can end up being difficult to get a consistent runtime installed to the masses.
      2. Flash movies run inside a browser and allow for integration with other web technologies (e.g. HTML, CSS, Javascript).

3. Framework:
   1. A framework 100% geared toward user interfaces.
   2. ActionScript 3.0 is Object Oriented.
   3. The language’s heavy Java influences are obvious.
4. Seeing is believing… Spend some time looking at some of the sample applications at http://www.flex.org/showcase/.

I have been getting a bit of push back when I suggest Flex/Flash as a viable option for building user interfaces to other Java developers. Some of the more common questions/comments are below:

• ‘Doesn’t Flex cost money?’
  • Adobe does charge for the Flex Builder IDE ($599) and Flex Data Services (FDS) deployed beyond a single CPU. However, you can build and deploy an entire Flex application for FREE. The SDK is free and there are Ant Tasks for creating a build. For the applications I am building, I have concluded that the only paid tool I need is the IDE. Granite Data Services (http://www.graniteds.org/) and Open Source alternative to FDS has met my needs to this point. In addition, Flex also provides methods for integrating with Web Services.
• ‘I tried developing applications in Flash before, and it just doesn’t seem geared toward developers.’
  • I share this experience, and had the same apprehension about Flex. The key thing about Flex is that it is a framework geared toward application developers, not designers. Although the applications are deployed as Flash movies, little-to-no knowledge is needed of traditional frame-by-frame like Flash development.
• ‘Wow. Flash, really? That sounds like a really heavyweight method of building applications.’
  • Not to oversimplify, but I have come to view the Flash Player as just another browser when building and deploying Flex applications, except the Flash Player displays consistently across all supported Operating Systems.

If you are willing to embrace the Ajax-like model for building web applications there are a number of options to consider in addition to Adobe Flex: Microsoft SilverLight, Open Laszlo, Java FX, and the many Ajax frameworks. Below is a brief review of each of these from my perspective as a Java developer.

Ajax

My depth of knowledge on Ajax is limited, as I have avoided using it on any large scale to this point. I do know there are many developers out there with successful deployments of online applications that incorporate significant amounts of Ajax functionality. For me, it just seems to push the standard browser functionality beyond its natural capabilities. Regardless, by its nature, it is always going to be painful for the developer, as they have to support deployment to multiple runtimes and the many cross-platform issues that arise from that.

I do believe Ajax, along with HTML, CSS, JavaScript and server side technologies, will always be some part of any comprehensive online application. The only question that still intrigues me is, what parts should they make up?

Microsoft SilverLight

I would anticipate SilverLight being the strongest competitor to Flex in the near-and-long-term. As much as I love to hate the Evil Empire, we all know they will commit to making this a world class development platform that integrates with all of their other tools. It appears to already have stronger video support than Flex, and will surely catch Flex in other areas very quickly.

My biggest reservation with SilverLight comes strictly as a Java developer. It doesn’t seem to make a lot of sense to learn a new tool set (e.g. Microsoft Visual Studio) and be outside the mainstream trying to integrate Java and SilverLight when there are comparable technologies that are much closer to the Java space. That’s not to say a .NET developer shouldn’t consider Flex, but hey, I don’t know how things work on that side of the software planet.

OpenLazslo

OpenLazslo is similar to Flex, as it is an Open Source Framework for building applications that deploy as Flash movies. However, it is my understanding that the current release of the OpenLazslo Framework does NOT target the Flash Player 9 virtual machine (and its many performance benefits). Flash Player 9 was a virtual rewrite with many improvements including support for ActionScript 3.0 and much improved performance (up-to 10 times faster than previous versions according to Adobe). The Flash Player 9 actually ships with two virtual machines for backwards capability (Flash 8 & 9).

Regardless of the performance trade-offs, it is still attractive to some because it is an Open Source project. However, Abode committed to Open Sourcing the Flex framework in recent weeks. So, I am not sure that is still a compelling motivation to choice Lazslo over Flex.

Java FX

Java FX is a complete joke to me! It’s just another grand Java One announcement with NO release date… and foggy details on what it will look like when it is released. The most promising descriptions describe an Applet like deployment (over the samples that run in Java Web Start outside the browser), which just isn’t going to cut it. Thanks Sun… Thanks for showing us the raw work going on in your R&D labs (more Jon Rose skepticism run amok).

The only interesting thing about Java FX is that it is essentially Sun’s acknowledgement that the industry has already shifted away from server side user interface frameworks (e.g. Struts, JSF), in favor of richer client side runtimes.

Summary

Each of us comes to our own conclusions on how to best build online applications. For me, Flex is clearly the way to go. As a few wise developers have said to me, ‘Flex is just another tool.’ To a large extent I agree, but the difference to me is that the end product produced from Flex is such a large leap forward when compared with the current landscape.

References:

http://www.adobe.com/aboutadobe/pressroom/pressreleases/pdfs/200606/062806Flash9.pdf

http://msdn2.microsoft.com/en-us/library/bb428859.aspx

http://www.openlaszlo.org/front_page

http://www.jamesward.org