Slashdot Mirror
Thin-Client Applicaton Architectures?
Rob writes "This is a pretty broad question, but I'm in the process of evaluating alternatives for thin-client application platforms, and could use some insight into what's likely to emerge as next-generation standards over the next few years." There's more meat to this question. Click below for more.
"Leaving aside the backend, the choices for the frontend seem to come down to:
- HTML (and its possible successors)
- Java
- Plug-ins (or other types of browser-like 'universal client' modules)
- HTML is not designed for building traditional data-entry applications, requires all kinds of nastiness to maintain application context, and is inefficient in terms of bandwidth.
- Client-side Java isn't really thin enough by my definition. Run-of-the-mill application programmers shouldn't need to be writing GUI code at all (too damn complex). And then there is the (MS sponsored) murder of the portability promise.
- Plug-ins work well, if you're willing to accept the initial download (and occasional updates), but as platforms proliferate, it's not practical to support them all. A Java-based plug-in might work if only the portable GUI promise were really true.
What this world needs is a good, really smart, dumb terminal.
I've been at work on just such a thing for several years now, and while it's not general-purpose enough to fit the bill, the thing works great. It essentially distills down the N most frequently used GUI features and 'implements them for you'. A simple API on the server lets transaction-based apps talk to the terminal and maintain context easily.
Is it possible at this late stage for a new universal front end to emerge for building server-based applications? And become a standard? Do you think the open-source effect would help? Or am I nuts, and HTML/Java is all you need?"
Outside of some obvious markets like PDAs and appliances, why is there such emphasis on thin client? The computing power, network bandwidth, memory and so on are all rising pretty steeply. With technology like Java (only one of many such) that enables download of objects/classes as needed and competent end-nodes, who cares about thin-clients? What it seems to me is really needed is much more powerful peer-peer object communication and management. Too much thinking gets straight-jacketed into client vs. server.
As a first step, I have a grammar-sensitive JavaScript compressor which I'm releasing into open source.
Seastead this.
Given that you're looking for a forms based solution Java will be fine (although you probably should go with the plug-in). Swing DOES give you a nice cross-platform UI if the AWT proves to be unsatisfactory.
It's VERY easy to write a generic forms engine which generates it's layout from the data definitions. Java's Reflection support makes this that much easier. I don't know if there's a 3rd party package to do this, but I've written my own on several occasions.
sigs are a waste of space
I agree. In my experience, Citrix is hands down the best thin-client solution, especially in mixed OS environments.
Publishing aps to the web works well, and the java ica clients have worked flawlessly on our linux boxen. Running NT-centric accounting bloatware across ppp lines that run as fast as if they were on the lan. 20k MAX bandwidth. Sweet.
At the risk of over simplifying an answer . . .
Yes
Put it out there in Open Source and see what happens. Build a trademark-based certification program so that it can remain Open Source and have strong standards at the same time.
I agree with you that Java is fat. I'm not sure the "dumb terminal" is the right approach, though. Modern applications, for example word processors, need to do a lot of computation per event, and that is best done locally. I think Guido's use of Python, rather than Java, as a thin client language was a good approach and it's too bad it got buried in the Java hype. So, perhaps an Open Source lightweight widget kit plus an Open Source language would be better. But I'm not discounting your idea - it sounds like NAPLPS for the 2000s, but maybe the world needs a new NAPLPS.
I'd rather have the Open Source world charting the course of think client development, too. Thanks
Bruce
Bruce Perens.
Check out Apache JetSpeed (http://java.apache.org/jetspeed)
It is a thin client (HTML 4.0, JavaScript/DHTML, and DOM) that is a Groupware/Portal application.
I think it has what you are looking for and solves all your problems. It doesn't use Java on the frontend but solves the rich-client problem by using DHTML.
Kevin
I'm not sure what you want to be answered. Is there room in the market for a thin client application tool? Yes. (IMHO)
If you want my thoughts on current options, read on.
You seem to have decided on the idea of using a browser as a thin client. Is this just an assumption, or is there a good reason for it?
If you want (can) get away from the browser, there are plenty of "thin" client solutions - the question is, how thin do you want it?
Low Bandwidth X (LBX) is a possibility (and is even thinner than HTML), and then there are plenty of non-Standard application generator tools that will do something similar (Under windows, Delphi, VB, Powerbuilder, Oracle Forms), but the "Thin" client for these is "thicker" than HTML or X
Depending on your application, (please, no flames) ActiveX Forms may be suitable, but you seem to not want to go with Java, so I guess the same problems apply with Active X
XML based applications have a lot (as in - I think up new ideas every day) of potential. IE5 does some pretty cool stuff at the moment with XML, and the Mozilla GUI is "written" in XML.
My "Big Idea" (TM) at the moment (I should try for funding *S*) is to write a universal thin client that would use the libGLADE to build a GUI from a XML file delivered by HTTP. The button presses etc would be passed via the thin client framework to event handling code on the server using either CORBA or (my personal favourites) XML-RPC or SOAP
Anyway, there you go. If anyone decides to try coding it, please let me know - I might actually get around to doing some myself. *S*
This perl versus java thing confuses me. It seems that there are people who truly believe they can do anything with perl.
Perl is a scripting language, Java is a system programming language. Mind experiment: implement java in perl, now implement perl in java which of those two programs do you want to maintain?
Jilles
A curious thing happened on my way to Freshmeat.
Where the hell did Mindbright come from?
Mindbright, for those who don't know, makes the GPL'd Mindterm java applet. It's an incredible SSH client written in 100% Portable Java and has completely changed my perceptions of what a quality Java applet can do.
Suddenly, I have a SSH client at any web browser I sit at. And it's fast, to boot.
If that wasn't enough to impress me, MindVNC is a merge of their SSH classes and the GPL VNC Java client. (VNC is essentially a remote frame buffer--the display is rendered or copied into a virtual screen then sent over the network.) You authenticate against the ssh server that hosts the Java app, and you can VNC to any terminal the remote sshd can access--yes, this means you can connect to your bastion IP Masqing host, then VNC to some 10.* machine behind the firewall, all through a secure link.
The relevance to the story is in simple and speedy deployment of tools--any and every machine with a Java VM can immediately and securely access both text and X based applications with minimal deployment pain. This exceedingly low pain for large scale client deployment via Java may actually benefit VNC in surprisingly powerful ways. Since the VNC system has been ported all over the place, from svgalib linux to windows, and as it poses an open source, well tested, very portable, and highly functional remote access platform, it may just end up becoming a formidable force as the years go on.
Those who don't think projects should be allowed to fork--at all--need to see the amazing work that Mindbright's been allowed to do on the shoulders of the GPL. (The analogue to scientific development wasn't accidental.) More work is left to be done--the Mindterm client could use telnet support, and VNC could seriously use a "single app" mode that sizes the desktop to that exact size of the remote application, translating resizings on the client to resize attempts on the remote app.
The seed of possibility is definitely there, though.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Client-side Java isn't really thin ... true in a browser! A complete java desktop, cut loose from netscape or ie remains thin though, look to SevenMountains Software www.sevenmountains.com for a complete implementation of such a desktop, running on any platform with a decent vm, with a stunning performance. Client: 5 megs, browser included.
Really, Forms aren't so bad. The issues of maintaining application context were solved years ago.
They are well understood, there's an unbelievable number of tools and examples. Bandwidth use, while not entirely minimal, is not that bad, either.
If your concern is presentation, just a little Javascript goes a long way here.
If you are not concerned with presentation, you can actually do a lot with character-cell based forms over a telnet connection. It's a tough sell, but once your users are trained, they typically love the responsiveness and efficiency that can be had with a simple solution like this. Of course, these days, to run a character-cell based form typically means a PC, which is too thick for some.
As others have said, maybe there is a market for a new dumb terminal standard. You might want to try and work out exactly what your ideal dumb terminal would have, but unless you can build commodity hardware, it would probably have to be implemented with HTML, XML, Java or some other plug-in.
Although you accurately note that HTML is far from ideal, Java servlets can enter into the scene, and, say, take your an XML-defined GUI and map it to HTML on the fly for you. There are also several packages out there that will actually reconstruct the appropriate Java GUI complete with widgets for you in HTML. The servlet would maintain state I'm assuming.
/Java/, which is really nice, and may be able to solve a lot of your problems.
Full-blown Java app. Java does incur some overhead, but the portability really is there as long as you are not doing something really funky or attempting to make use of the latest whiz-bang features out of Sun. We deploy Java apps to a campus of over 30,000 people, which is also pretty heterogenous (Windows, Mac OS, Linux).
As for plugins, I would trust them as far as I can throw the bloated browsers out there today. But take note of Mozilla. When it comes to fruition you will be able to write pluglets in
Sun Ray...looks real spiffy...wish we could replace our public labs with them, instead of having, like, 40 computers per lab at @$1000 each plus maintainence costs and funky software distribution mechanisms.
It's 10 PM. Do you know if you're un-American?
Faster?
The Citrix ICA protocol is remarkable... it compresses the screen changes so well that you can run applications very smoothly over a mere 56K line. VNC, while very flexible, is much more bandwidth-intensive, and feels pretty sluggish even over a T1. They say right on their web site that it was designed for high-bandwidth LANs.
(VNC is highly portable and free, though. We have deployed it to every server and workstation to allow remote administration and help desk support.)
"Conclusion? Write in C. Or assembler, if you can. Or anything but BASIC."
Why not basic, it would suit you just fine judging from the rest of your post: ugly syntax, close to all those nice GPFs and blue screens and other interesting stuff you encounter when you descent to that level.
Assembler is nice if you are exclusively interested in performance. C becomes an option if you care about other things too but performance is still very important. Then it gets interesting because there's a whole bunch of languages each with a different goal. Perl: ugly syntax, good for implementing something fast, performance is also nice but could be better. Java: clean syntax, also good for implementing something fast, performance could be better but can be adequate in some domains given good programmer skill.
Conclusion c is for hardcore programmers who like to stay close to the hardware, perl is for people lacking programming skill who want to get the job done anyway and don't care about maintenance, Java is for people ranging from novice to hardcore programmers who like a powerfull language but also care about maintenance, scalability and platform independence.
Conclusion, you should reconsider your conclusion. I don't want to say perl is bad. I must admit I have looked at to see if I could script JavaBeans with it. In my opinion scriptlanguages can be very good for glueing together components in a system. You should check out www.scriptics.com if you are interested in this sort of stuff. One of the persons there, John Ousterhout wrote some interesting stuff about the use of TCL/TK in combination with Java.
Jilles
*sigh* I wrote my post in English. Be glad I don't reply in line numbers.
:). I like to use shell for this too. It's slow, but the whole point of a glue language is that you shouldn't be using it enough for it to be slow. All the real work should be done by something fast, like... C.
;)
I don't like BASIC because it is generally slow and interpreted and weak. (i.e. not powerful, you shouldn't have to code around the language to do basic tasks) You should have gathered this from the content of my post.
I'm interested in performance. C is good. Assembler is better for optimizing code, it's great if you can write that code for a couple of platforms, and include it in as needed, with substitute C code for other (unsupported as yet) platforms. MAME does this for some of its CPU cores.
Perl and Java speed implementation and are therefore good for prototypes and hacks. However, if you know C, it's great for hacks, and actual implementations. And it's already really portable too. Some Java VM's might get faster at least, they're still maturing. Perl will probably get rewritten into C++ for maintainability, so we'll see if it gets slower or not.
I'm not really saying that Perl or Java is outright bad, but for performance and real products that might need to run on, say, 486's with 8MB of RAM, they are obviously not the right choices IMO... (on a platform like that, I'd want the most speed possible!) And this is the platform that OSes like Linux like to claim to target. At least the GNU utils are coded well in C, but I remember when RedHat used Python for some of their control-panel tools, and it sucked...
Glue languages are fine, that's what TCL was supposed to be for, and what a lot of people use Perl for (or some freaks who use Scheme
VNC does have a Java client. That's okay. Why? Because VNC is slow too, usually because of network bandwidth. Java is fine, provided you make sure that it's not the bottleneck. Use it on the WWW, when you're waiting for a slow site or a modem, say, and it doesn't look that slow anymore.
And I think I had a 'holy war disclaimer' at the beginning, but these are of course my opinions.
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
What may be helpful, on the other hand, is to make sure there are ways of splitting applications into modular pieces so that you can have pieces on hosts here and there, and thereby keep the graphical pieces fairly thin.
To that end, I would commend the consideration of message-oriented middleware systems; there are expensive ones like Tuxedo or MQSeries, and "libre" ones like Isect.
Keep in mind that you can't keep the client thin unless you have already split the application cleanly into pieces that allow the client to stay thin...
If you're not part of the solution, you're part of the precipitate.
University of Georgia Department of English. Old, throwaway 486s as X terminals, with a central application server. (Disclaimer: not my project)
This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean.
I've had run-ins with other thin client architectures including Java, HTML and Citrix Win/MetaFrame/ICA type solutions.
It really depends if your application is in a closed environment such as a corporate intranet, or if it needs universal client compatibility.
In the closed environment, you have a lot more control over the client hardware specs. In this situation, if you can build a case around return on investment you may be able to find some takers.
I think that your best bet, though, is to stick with HTML. There may be some pains in maintaining application context but all in all the form/submit metaphor generally matches well with database access applications. It's really not much different from 3270/5250 type terminals. Furthermore, getting too tricky with GUI elements tends to limit usability rather than enhance it.
Ultimately, if you stick with HTML you'll have the widest range of client devices to choose from. Everything from big, fat, PC workstations to small, skinny, fixed function "internet appliances."
Even PDA's and cell phones become potential clients in this "everything's got a browser" age.
Yes, stick with HTML. Do all the harder stuff at the application tier.
Good Luck!
If you really want to do some thin client apps, why bother with the client at all? Forget about the client completely, spend the money on a fat ass server to do ALL the processing. There is no reason for the client to do anything at all but to display info and accept input. Amazon is a perfect example. Hell, you can order books with a Palm Pilot now. The clients don't get much more thin than that.
You don't need Java, you don't need cgi, all you need to do is process your info and publish it in html. Get the job done with bandwidth and processor power. Damn! Yankees just won again...
At the opposite end of the spectrum, the X protocol provides infinite control, but requires that you layer lots of stuff on top of it in order to do anything.
It may be worth looking at the PalmPilot; it represents, above all else, a useful set of compromises.
What is probably needed is some such useful set of compromises, a reasonably powerful widget set like one of
- Tk
- Gtk
- Qt
that has:Your idea of transmitting XML interpretable by a GLADE "server" on the client is certainly not outrageous; I would suggest the thought that it might be worthwile to have a protocol that passes across pre-parsed XML so as to cut down on the amount of network traffic.
The thing that libGlade does not (yet?) seem to admit is that of extensibility. In order to support that it would probably be necessary to have some form of interpreter on the client that can run (bytecompiled?) code to either provide additional widgets or to provide some further local processing.
If you're not part of the solution, you're part of the precipitate.
Your complaint against Java is that "programmers shouldn't need to write gui code". Have you checked out any of the non-programmer oriented java beans builders? Such as Lotus beanmachine or Jamba? You can build sophisticated guis which talk to databases with no code. I know you've probably heard this before, but this time I think they've done it. Java beans really are cool.
As for whether it's "thin enough". Well I think it's as thin as you're going to get whilst still getting all the features you may need. As you say, HTML is thinner, but it's also lame.
Try a SunRay1 (aka Corona in many circles). Thin as it gets, they're a framebuffer on ethernet, for the most part. A cheap dumb graphical terminal, your X session runs on the big monster server. One big expensive machine, but only one to manage. Talk about going full-circle, eh? They do have some interesting features. Stick a smartcard into one and log in, and your session follows the card. Yank the card out, and it goes to the login screen. Stick it into another corona box, and your session comes back up. Even the mouse is in the same place. The hardware is all USB, so you can use your favorite USB peripherals, including printers and scanners (it locates and adds them, presumably via Jini). Anyhow, you wouldn't run coronas over a WAN, but then again, ultra-thin clients aren't necessarily the best choice on a WAN either.
BTW, just as a disclosure, I do work for Sun. I personally don't think SunRays are the ultimate solution to desktops, but they're the niftiest dumb terminals I've seen yet.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I'll second that. I was going to post the same thing, but I read through all the comments first to see if anyone said it.
Tcl has the advantage over Perl of being a bit easier to read after it's written, and it integrates with the Tk library much more easily. You can write your applications in Tcl and use them through the web browser via the plug-in. All you'll need on the client side is a browser. The plug-in supports the sandbox concept, meaning that the Tcl scripts that you write will be safe for the users to run through their browsers. The gui's that you write will be good looking, and easier to develop than the equivalent Java gui. For more information on the plug-in and the Tcl language in general, go to www.scriptics.com.
If tits were wings it'd be flying around.
Take a look at http://www.wapforum.org for yet another approach to thin client architecture. This is the stuff that is going to get stuffed into pagers, cell phones, PDAs... most of the big players are adopting this emerging standard.
I have been setting up some thin clients based on our old (8MB, no hard disk) 486s. I boot off a floppy based on a modified LODS, which in turn is a modified Hal91 distribution. The machines are too small to boot X (thus, I can't use muLinux - it needs at least 16MB to boot X). VNC is ideal for me, I can have one big server with 10 running copies of the application I provide to the clients, which are completely stateless - you just boot the client and it appears exactly where you left it. On a LAN, display speed is perfectly comparable to X, and it can also be deployed (albeit VERY slowly) over a modem.
;) )
;)
I don't buy Java. Simply, it is an ugly language. If I were to start selling and marketing an all-purpose thin client solution (unlike mine, which is very purpose-specific), I would maybe build a Perl interpreter into its hardware... It would be much more appealing than Java to many programmers. (Of course, I'd have to get big bucks to do so
Anyway, my 20 mexican cents worth
Yeah, the worst thing is, is that our university has deals with Dell and Gateway, so in our labs we have, like fully equipped PIII 400 mhz monster machines, and all people use them for is as terminals for telneting in to PINE and the library catalogue! argh
It's 10 PM. Do you know if you're un-American?
I have used and really like Citrix thin client solution. Their Metaframe product works extremely well. Even better, they have been slipping out from Macroshaft's leash lately and announced they are working on Unix (Linux) versions of the Metaframe product. I think you should give them serious consideration.
I use a number of different 'thin client' type protocols on the networks I administer - X is a good protocol, but not very 'thin'. It doesn't work very well over long distances. On our Lan we have a number of X-terms that connect to DGUX servers, all of which can open a windows NT session on a box running Windows NT Terminal Server with Citrix Metaframe(sure, it's Windows, but get over it - users want Windows/Office). Additionally, we have PCs, Macs, and NCD ThinStar WinCE terminals. All can run the same applications, in many cases much faster than they could on their own machine. Plus, it really saves you money in the long run, because most users don't really use all the power a regular PC can offer, except in brief bursts. Maybe 10K for a huge server, and then any piece of crap can connect to it - instead of spending 1K for every person in the office.
Although WTS is a bitch to configure, once it's there, it works really nicely. Citrix ICA is an excellent protocol - it has clients for windows, mac, linux, solaris, java, etc, and can even be used over a modem, with encryption, with acceptable speed. People with the terminals as clients are easy to take care of. They won't screw up their machines, and if something goes wrong with it, we just pop in a new one and they're back online. Of course, Windows Terminal Server is pretty obscure at the moment, Windows 2000 will support terminal serving capabilities as well.
If you want multiplatform thin client capability, the names you need to know are NCD, Citrix, and Microsoft. VNC is an open-source alternative that works fairly well(although it is far slower than citrix), and supports almost every known platform. Although it has no built-in encryption, it can be tunneled through ssh relatively simply. It has fewer requirements than X, and shows good promise for the future. By the way, they needs more good developers - go to the site.
-lx