Philip Brittan's Blog

Java vs. .NET, part 5 - Rich thin clients

Let Java play to its strengths and co-opt Microsoft’s 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 I’m 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 Microsoft’s strength) from server-based applications (playing to Java’s 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.

I’m 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 Microsoft’s 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 -- that’s 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 won’t 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 doesn’t matter -- in the rich thin client world, it’s invisible to the application.

I am also not talking about terminal server technology, like Citrix or X-Windows. Today’s 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 it’s 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, it’s 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 don’t 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.

Comments

• How would this be possible?
  While I agree with the premise that we need rich thin client applications (I posted a message on a Mac-centric site today comparing web-based apps with dumb terminals), I don't think that it is possible to have 100% of the code running on the server and still have a rich client.

  Even in a web app, not 100% of the code is on the server. First, of course, there is the web browser, which is an application running on the client. Less pedantically, JavaScript is often used (rather poorly) to bring some marginally "rich client" features to a web page, such as dynamic updates or client-side validation. Again, this is code running on the server.

  If NO logic runs on the client, the only way for the application to "do something" is to go to the server to get some sort of processing of data, even if its just the simplest validation of a date, for instance. Sounds a lot like a web app, doesn't it? You simply cannot have a "immediate, responsive...user experience" without some degree of code running on the client.

  I have a feeling maybe you haven't explained yourself clearly, and that I am taking you too literally. If you really, honestly, and truly meant no code would run on the client, why would you worry about WORA: If 100% of the code runs on the server, the application could be written in native assembler for all the client cares; WORA is irrelevant.

  Frankly, I think that Flash (despite your disimsal) stands a better chance of winning this "epic battle" because a Flash application, which can run inside or outside of a browser, is lighter weight and more responsive than a Swing based Java application, and the Flash plug-in is actually more ubiquitious than modern JVMs. Plus, unlike Sun, Macromedia is actually giving the client side proper attention.

  Posted by: jimothy on August 26, 2003 at 11:29 AM

• How would this be possible?
  Sigh, the world may never no the details of this grandiose plan.

  Posted by: jimothy on August 28, 2003 at 07:19 AM

• How would this be possible?
  I'm very glad to hear you agree with the need for rich thin clients. I'll try to address at least some of your questions here.

  To start, I can assure you that what I describe is entirely possible. I don't want to talk about specific propducts here, but if you write to me (pbrittan@droplets.com), I'd be more than happy to discuss it with you offline.

  >>Even in a web app, not 100% of the code is on the server.

  Agreed. I think that calling Web apps "thin client" is very misleading. Web apps push tons of application code (JavaScript, Applets, even HTML itself) to the client to execute there. I maintain that all application code must stay on the server, and Web apps as we know them today violate that.

  >>First, of course, there is the web browser

  OK, yes that is pedantic :) Of course there is "code" which is the generic client application (just like the browser or RealTime player, etc.). When I say "no code on the client", I am referring to the code of a specific application that is delivered through the rich thin client framework.

  >>You simply cannot have a "immediate, responsive...user experience" without some degree of code running on the client.

  Yes, you really can. Rich thin client frameworks have generic clients that are quite smart and although they don't run code related to the application itself, they can handle a lot of user interaction, including simple parsing and validation, on the client side in a generic way.

  >>If 100% of the code runs on the server, the application could be written in native assembler for all the client cares; WORA is irrelevant.

  Precisely. You can say that WORA is irrelevant, or you can say that it is perfectly fulfilled. If your code always runs on the server and simply "projects" a rich UI onto various devices, desktops, and browsers, then your application will necessarily be cross-platform deliverable, which is the goal of WORA.

  Again, please write me if you'd like to discuss this further.

  Thanks.
  - Philip

  Posted by: pbrittan on August 28, 2003 at 12:17 PM

• How would this be possible?
  I'm very glad to hear you agree with the need for rich thin clients. I'll try to address at least some of your questions here.

  To start, I can assure you that what I describe is entirely possible. I don't want to talk about specific propducts here, but if you write to me, I'd be more than happy to discuss it further with you.

  >>First, of course, there is the web browser

  OK, yes that is pedantic :) Of course there is "code" which is the generic client application (just like the browser or RealTime player, etc.). When I say "no code on the client", I am referring to the code of a specific application that is delivered through the rich thin client framework.

  >>You simply cannot have a "immediate, responsive...user experience" without some degree of code running on the client.

  Yes, you really can. Rich thin client frameworks have generic clients that are quite smart and although they don't run code related to the application itself, they can handle a lot of user interaction, including simple parsing and validation, on the client side in a generic way.

  >>If 100% of the code runs on the server, the application could be written in native assembler for all the client cares; WORA is irrelevant.

  Precisely. You can say that WORA is irrelevant, or you can say that it is perfectly fulfilled. If your code always runs on the server and simply "projects" a rich UI onto various devices, desktops, and browsers, then your application will necessarily be cross-platform deliverable, which is the goal of WORA.

  Again, please write me if you'd like to discuss this further.

  Thanks.
  - Philip
  pbrittan@droplets.com
  

  Posted by: pbrittan on August 28, 2003 at 12:19 PM

• How would this be possible?
  For one example, visit the site in his email.

  Posted by: d_bleyl on August 29, 2003 at 12:17 PM

• This strategy does not need Java
  Putting all the functionality on the server may or may not be a good strategy, but it makes Java irrelevant. The whole point of Java was that you could send it down a wire to any kind of computing device running any OS on any CPU, and it would execute. Obviously, your server strategy does not need that. So it does not need Java. The next question is, why lock yourself into Java, when there are more widely-known languages (C++) and arguably better languages (Eiffel) to choose from?

  Posted by: observer386 on September 08, 2003 at 12:56 AM

• This strategy does not need Java
  You are correct that one of the benefits of this approach is the ability to more easily use various languages. I think this is a pre-requisite for the "Java Platform" to be able to integrate legacy code seamlessly.

  Just because you can use other languages does not mean that this doesn't play to Java's strengths. Java has been an extremely effective and popular lanuage on the server-side. Yes, you can do all the J2EE apps do with server-side C++ or Eiffel or LISP, but there are some extremely good reasons to use Java for that. As much as I love C++, I was personally very happy to make the transition from it to Java.

  The original point of Java may well have been that you could send it down the wire to any kind of computing device and it would execute. But that capability has not been the feature that has driven Java's success so far.
  

  Posted by: pbrittan on September 08, 2003 at 01:20 PM

• This strategy does not need Java
  I should add that although Java's cross-platform client-side capabilities haven't been the main driver of Java to date (we'll see how the Java Everwhere campaign changes that, if it all), but Java's cross-platform capabilities do appeal in the server-room. Corporate IT managers love the idea that they can can pretty easily change server platforms without having to port apps.

  Posted by: pbrittan on September 08, 2003 at 04:35 PM

• This is what I want.

  Pure Java, loaded to a thin client, app and libraries, once each morning, to a thin client terminal, from a server, by tftpboot. No browser. No frankenware. Just Java. No ICA, no RDP, no WINDOZE, no maintenance, no ' I know, but I HAD to download the smileys, they were free ...'

  The app logic would stay server side. The display (output) stream and the user (input) stream would be the only thing managed by the terminal.

  As a long time Delphi programmer and victim of windoze's ENDLESS problems, I must find a way to do this.

  d.
  

  Posted by: dendragonsix on December 05, 2007 at 06:24 PM

• F.Y.I. I looked at Providex, but it seems the server side is not Java.
  

  Posted by: dendragonsix on December 05, 2007 at 06:27 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版
  网络营销软件
  论坛群发软件
  论坛群发软件
  论坛群发软件
  网络营销软件
  信息群发软件
  信息群发软件
  信息群发软件
  群发软件
  论坛群发软件
  

  Posted by: mimi9989 on December 06, 2007 at 06:43 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling on December 13, 2007 at 12:38 AM

This work is licensed under a Creative Commons License.