In the fast-changing world of Internet-based technologies, perception is everything. Is a business solution implemented in a particular technology truly cross-platform? Is it scalable? Is it robust? Is it easy to use? Does it do what it set out to do? Most times the answers to these questions are based on the perception of the functionality offered by the application. In a distributed application a large part of the burden of providing the perception falls on the designers of the user interface. One of Java's salient features - platform interoperability - is achieved via the perception of user interface portability.

I say "perception of portability" because seamless cross-platform portability is paradoxical by its very definition. Let's take a minute to consider what porting applications between platforms really means. Porting applications between platform A and platform B inherently implies that platforms are incompatible. What this boils down to is that the assembly code generated by an application on platform A will be different from the assembly code generated by the same application on platform B. The executable is different. The combination of hardware, operating system and compilers used by the application is different for the two execution environments. Indeed, it's this very difference that allows different vendors to tout their value-adds for the industry. And all this is good because it promotes healthy competition.

The Ultimate Thin Client
Sun Microsystems' "the network is the computer" message has been consistent right from the beginning. Since Java was introduced in the marketplace, Sun has touted it as the technology that will make this a reality. For the network to be the computer, the burden of installing and running the intelligent piece of software applications needs to shift application functionality to tiers that are different from the client user interface tier. In other words, the intelligence and complexity in a solution need to move out of the presentation tier and be buried in different tiers of a distributed application. The presentation tier should be concerned solely with presenting data served up by the next tier. The UI client should be as thin as possible.

The catch, however, is that the same application should be able to offer the same functionality via different clients. And the world of clients has morphed from dumb vt100 terminals to PCs sitting on every user's desk to PDAs, cell phones, set-top boxes and pagers. Java offers core technologies that support distributed networking like Jini as well as different flavors of the Java platform for distributing the application across various tiers of a distributed application. In theory, the same content can be presented across all these devices. As a result, porting the user interface across the various applications should be seamless. All the devices run Java. As long as the code is pure Java, we should be able to drag class files from a PC and drop them into a 3COM palm.

In reality, it's not as simple as that. Any portable code has to adhere to the least common denominator of features that can be provided across the different display units. This defeats the purpose of the different devices, each of which provides unique features in the way it presents the data. This uniqueness manifests itself in the user interface, which is the user's window into the device. The more realistic approach is to leverage the least common denominator of functionality as much as possible, while keeping in mind that parts of the user interface won't be portable across devices and platforms. The challenge is to decide how much of the functionality needs to be provided in the user interface. The thin-client model may still exist; however, the data served up by the next tier will be different for different devices.

Wait a minute....Does this mean I can keep my user interface device/platform dumb and drive the user interface from the other tiers of the distributed application? That would be neat. Well, as the saying goes, if it's too good to be true, it probably is. A big assumption here is that the features offered by a particular UI device or platform can be optimally leveraged by the "server." This is certainly not true.

In fact, the different levels of sophistication of the user interfaces translate to the value-add provided by the vendor. The minute you start mixing and matching unique features offered by the device with the least common denominator offered by Java, guess what? Your client just gained weight.

Java Clients vs Web Clients
Today it behooves Java-based computing solutions to offer several types of clients. One is a Java client (fat client) that takes advantage of specific strengths of an application and presents them in the user interface. This is implemented as a Java application. The second type is a thinner client that uses Java applets to add dynamism to a Web UI on the client. A third type of client is the pure Web client that achieves dynamism via scripting languages. The latter two types have at least one thing in common: they serve up HTML (or XML), i.e., they run in browsers. One of the advantages of the Web clients is that they achieve some level of UI device portability. However, they inherit the issues related to browser portability. Hence, the burden of UI configuration shifts from Java code to scripting code. The point is that you still have to provide unique implementations to accommodate your environment's idiosyncrasies.

There's no silver bullet. Designing user interfaces is hard. Creating the right balance of responsibility across the different tiers of distributed applications is hard. However, as long as the appropriate perception is maintained, the end user should be unaware of these complexities. And abstracting complexity is the reason we use software to create business solutions.