Top Microsoft .NET Links
The Next-Gen User Interface
The Next-Gen User Interface
Dec. 3, 2001 12:00 AM
After months of hype, developers are finally sinking their teeth into the competing new initiatives by powerhouses Microsoft and Sun - MS .NET and Sun One. A beta version of .NET has been available on Microsoft's Web site since March, with Sun's beta platform due this spring.
At first glance the two projects are more notable for their similarities than their differences. Both seek the same two important goals: (1) universal back-end integration between every imaginable type of connected device via XML, and (2) moving desktop software onto the remote server, where it can be bought and sold on a per-use basis as a service.
Additional common goals include secure, universal access to your applications from any device and an IDE that allows you to create "smart" applications that react appropriately according to context (who you are, what platform you're on, etc.). And both support Java, to an extent. Even as Microsoft seeks to entice Java engineers away with C# and the Java User Migration Path (JUMP), Java applications can still take advantage of .NET Web services through XML and open standards-based protocols.
So far, so good. But what about the user interface? And what role will popular Java-based UI technologies like AWT, Swing, JSP, and servlets be assigned in the new order? Given both platforms' stated goal - the remote delivery of services that are every bit as good as the local, component-based software to which end users have grown accustomed - they're going to require a front end with a far richer user experience than is possible with today's standard client/server UIs. And they're probably not going to get it with the current HTML- and fat client-based paradigms.
In Figure 1 different kinds of applications are shown accessing Web services. Each application has a very different architecture and purpose. Components A and B are Web service providers. Component C is a desktop Java application that directly calls business logic in A and B. Component D is a multitier J2EE application. The business logic layer, implemented as EJBs, makes use of Web services. This fact is transparent to the presentation layer, implemented as servlets and JSPs. The UI is served to the end user in a browser.
Defining the UI of the Future
But these applications have serious problems related to the page-based nature of the Web. HTML was originally designed as a medium for the transmission of text, and while servlets enable these pages to be served as business logic dictates, the UI itself is less attractive and functional than local software.
Imagine, for example, trying to use Napster if it were an HTML-based servlet application. There would be none of the asynchronous, dynamic UI updates that allow you to follow the progress of each download as it proceeds. You'd have to wade through page after page in order to perform even the simplest tasks, response time would be much slower, and high-level functionality like Chat would be impossible. Napster's GUI may be a bit of an ugly duckling, but its presentation as an asynchronous piece of local software gives it a number of functional advantages over any HTML-based competitor.
But fat client GUIs like Napster have their own set of problems. Unlike Web-based solutions such as Hotmail, they don't allow you instant access to your account from any computer anywhere in the world, and administration is difficult. Upgrades must be done manually on every machine, forcing developers to account in the business logic for every legacy version that may still be in use.
What should the UI of the future look like? If Microsoft and Sun are to deliver on their promises, it would have to combine the benefits of Web-based and fat-client applications while simultaneously avoiding their many problems. As with servlet-based applications, the new UI will have to be:
And like fat-client software, the new UI will have to be:
This means that - in the first incarnation of both Sun One and .NET - Java developers will have the freedom to work with the existing UI paradigm of their choice. Sun One will speak Java as its language of choice, while Java presentation logic will be able to interoperate with .NET-based business logic, provided it speaks XML and the open standards-based protocols that Microsoft uses on top of it.
While Microsoft's JUMP initiative has been grabbing all the headlines, this is simply a way to give Java code access to Microsoft's answer to the JVM, the Common Language Runtime (CLR). But running on CLR is not at all necessary for Java to interoperate with .NET. All you need do is enable your Java front end to speak with the .NET back end using its open standard-based protocols on top of XML (see Table 1).
As far as new UI initiatives, Microsoft has contented itself with an upgrade of its Active Server Pages, now called ASP.NET - though use of this tool isn't required for presenting .NET applications. The new version of this familiar technology offers a dramatically different program model from both its predecessor and JSP, bringing Web programming a step closer to GUI toolkit programming. It boasts a new Web Forms class library that gives you programmatic access to the elements on a page; buttons and tables are exposed as objects whose properties can be manipulated. In addition, rather than force the developer to interpret the raw name/value pairs submitted as a result of an HTTP POST or GET, ASP.NET translates the user's actions into events delivered straight to the components' event listeners. Combine this with ASP.NET's automatic preservation of the state of each page from one HTTP request to the next, and the development paradigm looks very much like that of AWT and Swing. But the inherent limitations of Web-based applications still prevent ASP.NET from competing with the responsiveness and asynchronous dynamism of local software.
But in recognition of the limitations of these existing interfaces, Sun is also strongly considering the integration of a completely new (and very different) UI paradigm into Webtop - XUL (pronounced zool), an open-source, tag-based language created by Mozilla, and used to render Netscape 6. If their effort turns XUL into the next-generation UI framework of choice, developers may find their familiar Java GUI tools quickly marginalized.
Second, there needs to be a way to communicate between the front and the back end. Unlike HTML forms, XUL doesn't automatically send the data entered by the user back to a server whenever the user clicks on a widget. This is in fact an advantage, since there's potentially much finer-grained control over how and when that data is sent. But the plumbing has yet to be built.
Of the two companies we're aware of that are pursuing this strategy, AppStream and Softricity, neither, to date, has delivered a beta version of their product to the public. Such a paradigm would have to address a number of inherent difficulties. For one thing, delivering an entire application over the network is still bandwidth-intensive, whether whole or bit by bit. And a severed network connection might be difficult to handle since it could leave some part of the application partially downloaded. Finally, the logic to decide when to deliver each piece of the application would have to be quite intelligent. Since the technique is billed as a "no additional programming required" solution, little specific information about each application is likely to be available to the framework.
Remote Delivery, Local Appearance
Since all application logic resides on the server, the only necessary client-side piece is a generic, lightweight client. The user isn't aware of the client; all served UIs looks exactly like locally installed applications. A two-way, asynchronous protocol - we call it a User Event Protocol (UEP) - transmits UI update instructions from server to client and user actions from client to server (see Figure 2). Whereas a Web browser must receive an entire page in response to a user action, a Droplet receives only the changes necessary to update its display.
Limiting client/server communication to events and updates results in a lightweight protocol that increases application responsiveness dramatically and performs well over low-bandwidth devices. Since the client and server maintain a two-way connection, UEP can also deliver asynchronous UI updates to the client, enabling applications like Napster and instant messaging. This capability is crucial to many applications but eludes Web-based platforms. The protocol can also tunnel through HTTP when necessary, still supporting asynchronicity through efficient client polling. The fact that HTTP tunneling is sometimes necessary is thus hidden from the application programmer.
The advantage of this framework to Java developers is the ability to write remotely served, locally presented applications to end-user desktops using the AWT/Swing paradigm they're already familiar with. It also solves a number of engineering problems that occur in Web development: it hides all networking code, eliminates the need to track per-user session state (values of instance variables don't disappear until the user exits the application), and eliminates Web programming problems caused by the browser's back button - all while retaining acceptable speed and full interactivity.
Reader Feedback: Page 1 of 1
Microsoft .NET Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week