Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
SYS-CON.TV
Top Microsoft .NET Links


The Next-Gen User Interface
The Next-Gen User Interface

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
Client/server UI development has been extremely Web-centric in recent years, enabling an entire generation of thin-client, page-based GUIs that are served through technologies such as Java servlets. All business logic remains on the server, allowing for centralized administration and automatic upgrades, and giving end users secure access to their applications from any computer with a Web browser and an active Internet connection.

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:

  • Universally accessible
  • Easy to administer
  • Secure

    And like fat-client software, the new UI will have to be:

  • Instantaneously responsive
  • Easy to use
  • Asynchronous
  • Persistent
  • Component-based

    UI Agnosticism
    Both Sun and Microsoft are reacting to the limitations of current UI paradigms by making their initiatives as UI agnostic as possible. Rather than lock themselves into a particular experimental scheme, they've chosen to ensure that their initiatives integrate with the existing Web-based and fat-client alternatives, despite their clear limitations - and will wait to see how the remote GUI evolves before placing any bets.

    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.

    Swung?
    Sun One's first release also strives to be as UI agnostic as possible, and will allow you to use all of the familiar Java-based UI frameworks. Consider, for example, Sun One's Webtop, a framework for developing productivity software that can be served remotely. Webtop is concerned almost exclusively with providing back-end services that can be called from the UI of your choice. This is good news for Java developers well versed in the current technology. Those with servlet and JSP experience can still leverage their skills in a new generation of Web-based software, while those wishing to write fat-client front ends will still be able to leverage Swing and AWT.

    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.

    XUL is not quite like anything else UI developers have worked with before, but its component technologies will seem familiar. Like HTML, the widgets in a window are described using XML. Cascading Style Sheets (CSS) provide the appearance parameters, and JavaScript is used to handle events and invoke business components. But the end result is quite different: XUL renders component-based GUI applications that behave like traditional desktop software.

    Given that Sun has pledged to make Java the main application-building technology for Sun One, XUL might seem a surprising choice. In its original form XUL uses JavaScripts to call business logic in C++ components. Fortunately, these components adhere to a cross-platform binary standard (XPCOM), and a Sun-supported project is underway to achieve full interoperability with Java.

    Remote XUL?
    Is XUL the UI of the future? If it could be served remotely via a thin client (like HTML), it could solve a number of "Web services" UI delivery problems. Unfortunately, its bandwidth requirements are extremely high and it can't provide the asynchronous UI updates to support interactive applications like stock watchers or IM. But even before these key limitations are addressed, the issues involved with keeping the XUL application's business logic on the server will have to be ironed out.

    There are several obstacles. First, to be a truly ubiquitous remote UI platform, a UI needs to adapt for display on different devices. While XUL shows promise in this area because of the inherent transformability of XML, it currently requires an extremely heavyweight client-side engine. In addition to an HTML renderer, the engine must embed a JavaScript interpreter and an XML parser, and support for CSS, the XUL language, and the XPCOM component model - essentially the entire Mozilla browser.

    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.

    One potential approach would be to make XPCOM components remotely callable. In its present form, the XPCOM specification, while not preventing remote calls from taking place, doesn't provide a framework to support it. The developer would have to take care of all marshaling and networking issues - an unacceptable burden in today's world. If remote proxies for components could be automatically generated, the JavaScript that accompanies the XUL code could transparently invoke business logic on the server.

    Work is also in progress to allow control code itself to be written in XPCOM components, and therefore in a language other than JavaScript. If mozilla.org provides an XPCOM-compliant interface for event handlers, event-handling code itself could potentially be a remote component invoked directly when the user performs an action, such as the click of a button. This would enhance security by keeping the client from downloading executable code. In addition, the client device would no longer need a JavaScript interpreter, significantly decreasing client-side footprint and processor consumption.

    Streaming Applications
    But wouldn't it be nice to keep writing AWT and Swing-like Java front ends, just as you always have? While Microsoft and Sun are focusing on the browser, a group of start-ups is attempting to find new ways to deliver Java GUIs to the desktop, bypassing both the sluggishness of Web applications and the long download times of large applets and fat clients. One such method, the "streaming applet," delivers application code to the client in a mode analogous to a media player. Developers write AWT or Swing front ends more or less as if they were served locally. The application server then automatically chops the application into chunks and serves them to the client as needed. The server attempts to make intelligent decisions about which pieces to deliver first, based on typical usage patterns. Once the Java logic arrives, it's cached (but not installed) and run on the client side, giving end users a centrally administered, locally processed application. Developers needn't worry about network issues.

    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
    Our company, Droplet, Inc., has developed a less bandwidth-intensive way to accomplish a similar goal. Droplets serve an AWT-style UI remotely without transferring any of the application code to the client. This allows developers to write and serve thin-client applications using Java's highly evolved, well-designed GUI development paradigms. Developers write the UI almost exactly as if they were building local software, but the application remains on the server and can be used from anywhere on the Internet.

    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.

    Conclusion
    The advent of Web services - and their whole-hearted adoption by the world's two most important software companies - requires a far more advanced UI framework than has been developed to date, and it's too early to tell which of the new competing paradigms will win out. While Sun's adoption of the tag-based XUL language and Microsoft's enhancement of Active Server Pages have cast a small cloud over the future of Java UI development, a number of companies have come up with innovative ways to leverage the sophistication of AWT and Swing as front ends for Web services. Meanwhile, the software giants are hedging their bets, lest their initiatives be outflanked by the rapid transformations now taking place in remote UI delivery.

    Resources

  • Appstream home page: www.appstream.com/
  • ASP.NET home page: www.asp.net/
  • Droplets Remote GUI Toolkit for Java: www.droplets.com/scripts/sdk.asp
  • Project Blackwood: Integration of the Java Platform with XUL: www.mozilla.org/projects/blackwood/
  • Softricity home page: www.softricity.com/
  • Sun One Webtop home page: www.sun.com/sunone/
    About Russ Atkind
    Russ Atkind is senior software developer at Droplets, Inc., where he ported the Droplets C++ API to Java, among other major development initiatives. Droplets is a thin-client, browser-independent UI delivery platform for serving remote applications with the functionality and speed of desktop software. Russ holds a BA in computer science from Yale University.

    About Sean Harvey
    Sean Harvey, senior technical writer at Droplets, Inc., developed the Droplets Platform SDK documentation from scratch. He previously worked for Tempest Software, Inc., and the UN. He has been widely published in numerous journals covering a variety of fields.

  • In order to post a comment you need to be registered and logged in.

    Register | Sign-in

    Reader Feedback: Page 1 of 1

    Sorry for Droplets.

    But thats a goodway showing that an artikel is good, and still not free.

    It really doesn't make sense as a promotional exercise to either the XML journal or to droplets technology, not to show the whole article here ...

    Very silly ... and annoying ...

    Its a shame this article is not complete. It won't help droplets' campaign... ridiculous!

    It looks like Droplets has some very good ideas, but proprietarty solutions (e.g. UEP) are not the trend. Finding talent that has the necessary J2EE backend skills and droplets should be about as simple as solving world peace. Do they realy want to advertise Enron as a backer??????

    Well, Python has already been integrated into XPCOM, so it is possible to write XPCOM components in Python, and even scripts in Python instead of JavaScript. I will admit, though, that it isn't widely used or supported yet.

    Java XPCOM components can communicate with remote Java objects using whatever RPC protocol you decide. This does, however, require mucking around at a fairly low level.

    I looked around the Droplets site, and while it is very interesting, I doubt it will be adopted on a wide scale. UEP is a proprietary protocol, one proprietary implementation, and the single available client only supports Windows. It looks like it would be useful for intranet applications, and may find some uses there, but will never find wide acceptance (even within the intranet).

    it's amazing we're still torturing ourselves with applets and html. new ways to make thin client apps is sorely needed.


    Your Feedback
    Christian Essl wrote: Sorry for Droplets. But thats a goodway showing that an artikel is good, and still not free.
    Doug Cruickshank wrote: It really doesn't make sense as a promotional exercise to either the XML journal or to droplets technology, not to show the whole article here ... Very silly ... and annoying ...
    Espo wrote: Its a shame this article is not complete. It won't help droplets' campaign... ridiculous! It looks like Droplets has some very good ideas, but proprietarty solutions (e.g. UEP) are not the trend. Finding talent that has the necessary J2EE backend skills and droplets should be about as simple as solving world peace. Do they realy want to advertise Enron as a backer??????
    David Freeman wrote: Well, Python has already been integrated into XPCOM, so it is possible to write XPCOM components in Python, and even scripts in Python instead of JavaScript. I will admit, though, that it isn't widely used or supported yet. Java XPCOM components can communicate with remote Java objects using whatever RPC protocol you decide. This does, however, require mucking around at a fairly low level. I looked around the Droplets site, and while it is very interesting, I doubt it will be adopted on a wide scale. UEP is a proprietary protocol, one proprietary implementation, and the single available client only supports Windows. It looks like it would be useful for intranet applications, and may find some uses there, but will never find wide acceptance (even within the intranet).
    denny farber wrote: it's amazing we're still torturing ourselves with applets and html. new ways to make thin client apps is sorely needed.
    Microsoft .NET Latest Stories
    The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a...
    Information technology (IT) advances are transforming the way we innovate in business, thereby disrupting the old guard and their predictable status-quo. It’s creating global market turbulence. Industries are converging, and new opportunities and threats are emerging, like never before...
    In his session at 19th Cloud Expo, Claude Remillard, Principal Program Manager in Developer Division at Microsoft, contrasted how his team used config as code and immutable patterns for continuous delivery of microservices and apps to the cloud. He showed how the immutable patterns hel...
    While DevOps promises a better and tighter integration among an organization’s development and operation teams and transforms an application life cycle into a continual deployment, Chef and Azure together provides a speedy, cost-effective and highly scalable vehicle for realizing the b...
    Hostway is announcing its hybrid cloud service based on Azure – all backed by managed support for configuration and provisioning, monitoring resource utilization, virtual networks, backup, storage and much more. Now, organizations can choose the best technology infrastructure to run th...
    Subscribe to the World's Most Powerful Newsletters
    Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
    Click to Add our RSS Feeds to the Service of Your Choice:
    Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
    myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
    Publish Your Article! Please send it to editorial(at)sys-con.com!

    Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


    SYS-CON Featured Whitepapers

    ADS BY GOOGLE