Now that I’ve had a week to let all the new information bounce around in my head for a while and settle into semi-organized piles of data, I have two major takeaways from the conference.

Firstly, Adobe users love their products, and they’re tremendously enthusiastic about the direction Adobe is taking them. In the main sessions, where all 6,000+ attendees were in the same huge room, many new features were met with thunderous applause. You just don’t get that sort of thing at a WebSphere conference.

Secondly, if CS4 is a big success – and I have no doubt but that it will be – we’ll start to see changes in the relationship between designers and developers on teams building RIA’s. CS4 contains a brilliant piece of software, Flex Catalyst, that lets designers using PhotoShop and Flash save content to the same source files as developers using Flex Builder. This provides a seamless transition from initial UI mockup to prototype to working application – and keeps the UI in the hands of the designer a little longer than has traditionally been the case. Designers can now exert great control over not only over the way an applicaiton looks, but also over the way it behaves as a user interacts with the various widgets in the UI. This will bring new challenges to RIA developers who work on teams with designers – developers will have less control, less latitude to say “We can’t do that – it’ll take too long”, or “Sorry, the tool won’t let us do that.” Developers will inherit a prototype that is quite complete in terms of look and feel, and will be focused more on adding functional meat to the UI bones (filling lists with live data, wiring events to real business services, etc.).

Oh, I did forget to mention one thing. This was my first time in San Francisco. What a wonderful city! I’ll definitely be back…

Of course it can; different programming languages have always had different strengths and weaknesses, and RIA languages are no different.  But in what ways?  I’ve been thinking about this quite a bit lately, as Redpoint has been engaged in projects that represent a few variations on the RIA theme.  In particular, I’ve noticed how eerily similar two particular technology stacks are, and yet how different they are in at least one key area.

Consider two applications, both of which use standard Java-based web technology on the application server (say, Tomcat, Spring and Hibernate).  For client-side technology, one uses Java Swing (via Web Start), and the other Adobe Flex.  Both employ middleware (Spring HttpInvoker on the one hand, Adobe Blaze on the other) to accomplish simple and efficient communication between client and server in the form of serialized objects over HTTP (as opposed to a more verbose SOAP or XML-RPC-based solution).

From many angles, these applications are very similar; the app server receives requests containing binary data (serialized from client-side objects), and returns binary data to the client in response.  In neither case do programmers need to pay attention to the object serialization; once it’s configured into the environment early in the project, it’s done, and thereafter it "just works."

But there is one difference, and I think it’s profound.  In the all-Java solution (with the Swing front end), not only does the client receive objects from the server, but – this is key – those objects are instances of the same classes the server uses in its JVM.  Okay, great – but why is this important?

It’s very important if, as an application architect, you’re interested in building a rich set of domain classes that contain all of the important business rules and operations in the application.  (If you’re content with "domain classes" that are little more than containers for data that’s been spewed forth by Hibernate, read no further – the rest won’t interest you.)

In the Tomcat-to-Swing application, we have tremendous flexibility in terms of location of code that some refer to as "transaction script" – code that manipulates a rich set of domain objects in order to produce some meaningful outcome (place an order for the latest Tom Petty CD, transfer funds from your beleaguered mutual fund into bonds, etc.).  Because the rich behavior of the Java domain classes resides on both the server and the client, we have the option of writing our transaction script code on the client as well as the server.

In the Tomcat-to-Flex application, this flexibility, ironically, is gone.  The Flex application sits on the other side of a technology chasm – yes, it is based on objects, and yes, they are returned from the server and magically "appear" in responses received by the client.  But the Flex classes are written in ActionScript, not in Java.  Which means they are not the same behavior-rich set of domain classes that exist in the server JVM.

As an architect of an application with disparate development languages on client and server, you have an important choice to make.  Do you maintain two full-featured sets of domain classes, one in ActionScript and one in Java?  Or do you treat the ActionScript layer as "domain light," eschewing the dual development (and more importantly, dual maintenance), and do all of the meaningful application work on the server (where a lot of traditionalists and web service or ESB lovers will argue that it belongs anyway)?

I’ve built applications both ways.  The traditional approach of pushing all of the meaningful application work onto the server does have its benefits, in terms of simplifying the architecture, and helping to ensure that the client app doesn’t get too "chatty" (communications with a very thin client tend to be less frequent and larger-grained in nature).  But there are benefits to taking advantage of a rich client and doing some of the work there.  Scalability is one obvious benefit; by allowing the client to do some of the work, you by definition relieve some of the load on the server.  All other things being equal, an application that shares processing responsibility between client and server will scale better than one in which the server carries the load alone.  The "thicker client" application can also be more responsive, responding quicker and more meaningfully to the user (this is, after all, why we are building rich applications now instead of relying on creaky old HTML forms, right?)

I’d love to hear from others who have thought about this.  Is having a single set of domain classes, with rich behavior available to both client and server, an important consideration when selecting an architecture?  Is it important enough to sway your choice of client-side development technologies?