Here’s a question for anyone about to select a development platform for rich internet application (RIA) development:  How can your choice of languages limit your flexibility in design and architecture?

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?