Java vs. .NET, part 5 - Rich thin clients
Let Java play to its strengths and co-opt Microsofts advantages
In the previous parts of this series on Java vs. Microsoft .NET, I lay out the threat that .NET poses to the Java ecosystem and the advantages on which Microsoft is relying to carry out that threat.
So what is the response to this threat? Those of you who know me already know what Im going to say: rich thin clients. In fact, a month ago java.net readers byronsebastian and d_bleyl forshadowed this entry.
The concept of rich thin client technology is to deliver the user experience of native locally-installed desktop software (co-opting Microsofts strength) from server-based applications (playing to Javas strength). With this approach, Java gives developers a cross-platform method for delivering applications that feature the desktop benefits that users want with the deployment and administration benefits that CIOs are looking for.
Im not talking about Java Applets, Flash, or other disguised fat-clients. In order to deliver on the full benefits of the server-based model, and to avoid walking into a Microsoft trap, rich thin client technologies must leave 100% of application code on the server. Putting code on the client means putting it in hostile territory where it can be attacked and thwarted by Microsoft. Additionally, rich thin clients need to be browser deliverable, but must also be able to operate independently of the browser.
It may, in fact, be necessary to use Microsofts own technology to implement the generic client-side piece of a successful rich thin client framework on Windows PCs/devices. I know that there is a feeling in the purist Java community that applications must be 100% pure Java to be acceptable, but I believe that the most important piece of the chain is that the applications themselves are written in Java -- thats the part that builds a developer community. If those applications are then displayed by Microsoft technology on the desktop so that they can take advantage of all the desktop benefits, so be it. If Microsoft really does banish Java from the PC, it just wont matter to rich thin client Java apps running safely on the server. On non-Windows desktops and devices, J2SE, J2ME, or even native technology can be used for the generic client. The desktop technology doesnt matter -- in the rich thin client world, its invisible to the application.
I am also not talking about terminal server technology, like Citrix or X-Windows. Todays rich thin clients can offer an immediate, responsive native desktop user experience, with no lagging remote mouse and with very high server scalability and super low bandwidth usage. They can offer the user experience that Microsoft promises with Smart Clients.
The Java platform must offer compelling benefits beyond simply matching Microsoft. Rich thin clients can do this:
Write Once, Run Anywhere: I just read this article titled Java Everywhere, which stated To get Java working properly on all devices, we must compromise one of Java's most recognized principles: Write Once, Run Anywhere (WORA). How sad, and unnecessary. With rich thin client technology, a single Java code base can run on the server and project its UI onto a very wide variety of client platforms. WORA can be preserved.
Open Standards: Move the entire balance of power to the server. Then open standards have some teeth.
Security: Keeping all your code on the server means that your application cannot be a vector for viruses and destructive bugs to client PCs.
Developer Productivity. Writing software that has 100% of its code on the server is easier to architect, debug, and manage than either client/server or multi-layer Web apps. Rich thin clients let developers architect their systems into as many layers as they want, not as many as the technology dictates. And its easy to bring standard, best-of-breed tools -- Java IDEs, debuggers, profilers, optimizers, etc., -- to bear on the entire code base.
- Resource-leveling: Utility computing promises to help companies save costs by virtualizing processor load and other resources across a managed grid. Keeping all the code on the server means all the code can benefit from this.
Rich thin client frameworks are also architecturally amenable to supporting a variety of languages. As I argued in the last part of this series, the Java platform needs to recognize the huge investment companies have in legacy systems and provide a way forward for those companies without requiring that they rewrite their apps in Java. Rich thin clients bring that legacy code into a server-based, network-centric environment and then give developers a way to add new features to those legacy apps in Java. Since all the code is on the server, its architecturally easy to deal with big piles of spaghetti (without having to disentangle them) and to mix and match languages and technologies, all under the covers and away from users and hard-to-manage desktop computers.
If rich thin client technology takes off, then it has the effect of marginalizing the desktop PC, a big strategic win for the Java camp. Rich thin client apps dont generally care what kind of client hardware is displaying them. Customers can go with whatever is cheap and convenient, not with the platform that happens to support their favorite apps. This paves the way for non-Windows desktop proliferation.
I believe that our industry is shaping up for an epic battle between the Microsoft ecosystem, wielding .NET, and the non-Microsoft vendors, championing Java. The battle will be very hard fought and Microsoft will give no quarter. Already they have put Java into a difficult position. The best way out of the trap is not to fight them on their terms, but to redefine the battlefield. This opportunity is available because the world is moving towards being always connected. Microsoft realizes this and is trying to use our increasing connectedness as a way to drive their platform from the desktop to the server room. The Java world needs to head them off at the pass and make real the fear that Bill Gates had of the Internet in 1995.