【正文】 our fastest solution, and since it will probably solve most typical client/server problems you might be hard pressed to justify learning Java. If you’re experienced with a scripting language you will certainly benefit from looking at JavaScript or VBScript before mitting to Java, since they might fit your needs handily and you’ll be more productive run its applets withi To some degree, the petitor to Java is Microsoft’s ActiveX, although it takes a pletely different approach. ActiveX was originally a Windowsonly solution, although it is now being developed via an independent consortium to bee crossplatform. Effectively, ActiveX says “if your program connects to its environment just so, it can be dropped into a Web page and run under a browser that supports ActiveX.” (IE directly supports ActiveX and Netscape does so using a plugin.) Thus, ActiveX does not constrain you to a particular language. If, for example, you’re already an experienced Windows programmer using a language such as C++, Visual Basic, or Borland’s Delphi, you can create ActiveX ponents with almost no changes to your programming knowledge. ActiveX also provides a path for the use of legacy code in your Web pages. vs. intra The Web is the most general solution to the client/server problem, so it makes sense that you can use the same technology to solve a subset of the problem, in particular the classic client/server problem within a pany. With traditional client/server approaches you have the problem of multiple types of client puters, as well as the difficulty of installing new client software, both of which are handily solved with Web browsers and clientside programming. When Web technology is used for an information work that is restricted to a particular pany, it is referred to as an intra. Intras provide much greater security than the Inter, since you can physically control access to the servers within your pany. In terms of training, it seems that once people understand the general concept of a browser it’s much easier for them to deal with differences in the way pages and applets look, so the learning curve for new kinds of systems seems to be reduced. The security problem brings us to one of the divisions that seems to be automatically forming in the world of clientside programming. If your program is running on the Inter, you don’t know what platform it will be working under, and you want to be extra careful that you don’t disseminate buggy code. You need something crossplatform and secure, like a scripting language or Java. If you’re running on an intra, you might have a different set of constraints. It’s not unmon that your machines could all be Intel/Windows platforms. On an intra, you’re responsible for the quality of your own code and can repair bugs when they’re discovered. In addition, you might already have a body of legacy code that you’ve been using in a more traditional client/server approach, whereby you must physically install client programs every time you do an upgrade. The time wasted in installing upgrades is the most pelling reason to move to browsers, because upgrades are invisible and automatic. If you are involved in such an intra, the most sensible approach to take is the shortest path that allows you to use your existing code base, rather than trying to recode your programs in a new language. When faced with this bewildering array of solutions to the clientside programming problem, the best plan of attack is a costbenefit analysis. Consider the constraints of your problem and what would be the shortest path to your solution. Since clientside programming is still progra