Summary
Using an XML syntax to declare and generate a rich UI for service-oriented and data-driven applications is getting a lot of traction. While much of the talk is about the application model, as it should be, it's also true that approaches like XAML, Royale, and XUL all make assumptions about the ubiquity of the client containers which they target.

Richness

From Microsoft's debut of Avalon and XAML to Macromedia's work with Royale and Flash to existing projects based on XUL, rich clients are a hot and ROI-relevant topic. There is a need to get much server-side data out to clients in a more powerful, richer way than mingling it with HTML and delivering it to a web browser that can't work very well offline, can't have relevant data pushed out to it very intelligently, and can't expose rich desktop behaviors to app developers and to users. There's a need to get beyond requiring a server roundtrip and state reconstruction for the simplest of actions; there's a need to take advantage of power available on the client rather than render all clients dumb terminals, all the time, for all use cases. But there's also a need to retain the ease of deployment, management, and other attractions of HTML-based web applications.

Rich Development Models

There's also a need to retain familiar development models for the web tier folks who build the apps. XML and tags generally work pretty well for this sort of thing. To that end, one might use XAML to generate Direct3D-based components once Avalon is released (seems to be still three years or so away) or use a similar syntax in Royale or Laszlo to generate Flash-hosted components, or use XUL/CSS to manipulate Mozilla components. Perhaps an intelligent set of JavaServer Faces renderkits will enable JSF to generate content for any of these platforms (although JSF seems to be mainly about simplifying the J2EE web app development experience rather than adding richness to client and presentation experiences, as its delegated rendering model treats client richness as sort of secondary to the framework). Others exist but the approach is generally the same: Declarative construction of a UI using existing components makes sense, as component interfaces or classes are easily addressed as elements and their properties easily addressed as attributes. Events tend to be addressed through script or similar code, data models tend to be either Schema- or RDF-compliant, and the declarative binding of services to models and UI components to models, and UI components to UI components is all fairly similar (whether XPath-based, or whatever).

Rich Client Containers and Ubiquity

But these approaches do not yet target a common set of client behaviors, but rather they target specific client container products. It's not as if you can use these new models to write to rich web browsers in general, and expect all the clients to interpret the content or specified behaviors roughly similarly. So in order for the model to be broadly useful, you currently need a ubiquitous client.

And the issue of client ubiquity can be a little squishy in my mind. It deserves to be separated from the client development model (mentioned some of this in a response to Adam's blog, which always makes me think really hard).

It is possible to (1) create a model that targets a specific ubiquitous client, such as Flash (being deployed on more than 90% of the world's desktops, it is the most widely distributed software product in history, or so our marketing info goes), but it is also possible to (2) create a model that targets a set of clients, where none of the clients in the set is ubiquitous but collectively they come pretty close, amounting to targeting a set of ubiquitous client behaviors; on the other end of the spectrum it's also possible to (3) target a platform like Windows in Intranets or Symbian or J2ME on phones that is very close to ubiquitous in a given niche or space.

Seems to me that XAML is aiming primarily for #3. Maybe Longhorn will be ubiquitous enough for corporate development of Intranet apps. Maybe the thought is that this will eventually drive changes in the broader consumer space. Too, there is nothing stating that Royale will always and forever be at #1, targeting Flash only. One could imagine, if a reason arose for it, growing into #2 (the most difficult of the three options) and targeting Avalon or Java or whatever other rich client technology requirements dictate. It aims to be an application development model, not a client-specific set of utilities. Similarly, XAML might theoretically target Flash or other technologies (though MS will very likely not do such a thing, perhaps other ISVs would).

The app development model (Royale, XAML) is certainly positioned according to relative ubiquity of specific clients (Flash, Central, Avalon), but is ultimately more dependent on the ubiquity of certain client behaviors such as compositing techniques and extensibilty of content handling than it is on the actual implementation and productization of those behaviors in one specific form. In practice mileage may vary, however.

What about Java?

So what do you think is Java's place in this rich client world? It is obvious that Java can be used as the basis of the development and deployment model, on the server at least. We and others are taking full advantage of this. But does Java -- realistically now -- have a place on the client as well? It was the original write-once run-... okay, nevermind. And legal battles on top of early applet technical issues caused issues. But what about now that the technology has matured?

I don't think it's a matter of just getting the technology right, but rather a matter of branding and business. In order to achieve ubiquity, the technology must either be something that is acceptable to users everywhere -- acceptable by name, for users everywhere will not be so well-informed as to base acceptance on the quality of technology, by and large -- or be embedded in something that is acceptable to users everywhere. At the moment a few brands have the ability to get consumers to install products onto their systems and trust them: Yahoo because of the IM client, Macromedia, Microsoft (my many friends in the linux and mac communities are still niches in this scope, by the way), perhaps Adobe, America Online, Symantec... not BEA, not IBM, not Sun, not Oracle, not the powerhouses of Java today.

Will it take one of the companies with ubiquitous reach to either champion Java on the desktop or embed it in order for Java to make real waves there? Java is everywhere on mobile devices, thanks to OEM deals with device manufacturers -- will it take something along those lines, which Sun seems to be pursuing with Dell and HP? Is there even a good reason for this (I've already suggested there is, in as much as I seek common rich client behaviors across rich client products, but am willing to be wrong)? I'm very interested in your thoughts.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Sean Neville adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Sean Neville is a software architect at Macromedia where he is focused on creating the Flex platform. His previous projects include the JRun application server and Flash-related products for J2EE and .NET. His experiences include membership in the JCP Executive Committee and numerous JSR expert groups; authoring articles, contributing to books, and speaking on enterprise topics; financial services app consulting; building doomed yet fun web startups; maintaining open source projects; and half-decent fiddling of Irish jigs and reels.