tij0028.html

学习java的经典书籍

applets within a “sandbox” of safety, which prevents it from
writing to disk or accessing memory outside the sandbox. 
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">ActiveX
is at the opposite end of the spectrum. Programming with ActiveX is like
programming Windows &#8211; you can do anything you want. So if you click on a
page that downloads an ActiveX component, that component might cause damage to
the files on your disk. Of course, programs that you load onto your computer
that are not restricted to running inside a Web browser can do the same thing.
Viruses downloaded from Bulletin-Board Systems (BBSs) have long been a problem,
but the speed of the Internet amplifies the difficulty.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
solution seems to be &#8220;digital signatures,&#8221; whereby code is verified
to show who the author is. This is based on the idea that a virus works because
its creator can be anonymous, so if you remove the anonymity individuals will
be forced to be responsible for their actions. This seems like a good plan
because it allows programs to be much more functional, and I suspect it will
eliminate malicious mischief. If, however, a program has an unintentional bug
that&#8217;s destructive it will still cause problems.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
Java approach is to prevent these problems from occurring, via the sandbox. The
Java interpreter that lives on your local Web browser examines the applet for
any untoward instructions as the applet is being loaded. In particular, the
applet cannot write files to disk or erase files (one of the mainstays of the
virus). Applets are generally considered to be safe, and since this is
essential for reliable client-server systems, any bugs that allow viruses are
rapidly repaired. (It&#8217;s worth noting that the browser software actually
enforces these security restrictions, and some browsers allow you to select
different security levels to provide varying degrees of access to your system.)
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">You
might be skeptical of this rather draconian restriction against writing files
to your local disk. For example, you may want to build a local database or save
data for later use offline. The initial vision seemed to be that eventually
everyone would be online to do anything important, but that was soon seen to be
impractical (although low-cost &#8220;Internet appliances&#8221; might someday
satisfy the needs of a significant segment of users). The solution is the
&#8220;signed applet&#8221; that uses public-key encryption to verify that an
applet does indeed come from where it claims it does. A signed applet can then
go ahead and trash your disk, but the theory is that since you can now hold the
applet creator accountable they won&#8217;t do vicious things. Java 1.1<A NAME="Index51"></A>
provides a framework for digital signatures so that you will eventually be able
to allow an applet to step outside the sandbox if necessary.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Digital
signatures have missed an important issue, which is the speed that people move
around on the Internet. If you download a buggy program and it does something
untoward, how long will it be before you discover the damage? It could be days
or even weeks. And by then, how will you track down the program that&#8217;s
done it (and what good will it do at that point?).
</FONT><P></DIV>
<A NAME="Heading49"></A><H4 ALIGN=LEFT>
Internet
vs. Intranet
</H4>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">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 company. With traditional
client/server approaches you have the problem of multiple different types of
client computers, as well as the difficulty of installing new client software,
both of which are handily solved with Web browsers and client-side programming.
When Web technology is used for an information network that is restricted to a
particular company, it is referred to as an 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>Intranet</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
Intranets provide much greater security than the Internet, since you can
physically control access to the servers within your company. In terms of
training, it seems that once people understand the general concept of a browser
it&#8217;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.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
security problem brings us to one of the divisions that seems to be
automatically forming in the world of client-side programming. If your program
is running on the Internet, you don&#8217;t know what platform it will be
working under and you want to be extra careful that you don&#8217;t disseminate
buggy code. You need something cross-platform and secure, like a scripting
language or Java. 
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
you&#8217;re running on an Intranet, you might have a different set of
constraints. It&#8217;s not uncommon that your machines could all be
Intel/Windows platforms. On an Intranet, you&#8217;re responsible for the
quality of your own code and can repair bugs when they&#8217;re discovered. In
addition, you might already have a body of legacy code that you&#8217;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 compelling reason to move to browsers because
upgrades are invisible and automatic. If you are involved in such an Intranet,
the most sensible approach to take is ActiveX rather than trying to recode your
programs in a new language.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">When
faced with this bewildering array of solutions to the client-side programming
problem, the best plan of attack is a cost-benefit analysis. Consider the
constraints of your problem and what would be the fastest way to get to your
solution. Since client-side programming is still programming, it&#8217;s always
a good idea to take the fastest development approach for your particular
situation. This is an aggressive stance to prepare for inevitable encounters
with the problems of program development.
</FONT><a name="_Toc408018406"></a><P></DIV>
<A NAME="Heading50"></A><H3 ALIGN=LEFT>
Server-side
programming
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">This
whole discussion has ignored the issue of server-side programming. What happens
when you make a request of a server? Most of the time the request is simply
&#8220;send me this file.&#8221; Your browser then interprets the file in some
appropriate fashion: as an HTML page, a graphic image, a Java applet, a script
program, etc. A more complicated request to a server generally involves a
database transaction. A common scenario involves a request for a complex
database search, which the server then formats into an HTML page and sends to
you as the result. (Of course, if the client has more intelligence via Java or
a scripting language, the raw data can be sent and formatted at the client end,
which will be faster and less load on the server.) Or you might want to
register your name in a database when you join a group or place an order, which
will involve changes to that database. These database requests must be
processed via some code on the server side, which is generally referred to as <A NAME="Index52"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>server-side
programming
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
Traditionally, server-side programming has been performed using Perl and CGI
scripts, but more sophisticated systems have been appearing. These include
Java-based Web servers that allow you to perform all your server-side
programming in Java by writing what are called 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>servlets</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
<A NAME="Index53"></A>
</FONT><a name="_Toc375545208"></a><a name="_Toc408018407"></a><P></DIV>
<A NAME="Heading51"></A><H3 ALIGN=LEFT>
A
separate arena: applications
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Most
of the brouhaha over Java has been about applets. Java is actually a
general-purpose programming language that can solve any type of problem, at
least in theory. And as pointed out previously, there might be more effective
ways to solve most client/server problems. When you move out of the applet
arena (and simultaneously release the restrictions, such as the one against
writing to disk) you enter the world of general-purpose applications that run
standalone, without a Web browser, just like any ordinary program does. Here,
Java&#8217;s strength is not only in its portability, but also its
programmability. As you&#8217;ll see throughout this book, Java has many
features that allow you to create robust programs in a shorter period than with
previous programming languages.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Be
aware that this is a mixed blessing. You pay for the improvements through
slower execution speed (although there is significant work going on in this
area). Like any language, Java has built-in limitations that might make it
inappropriate to solve certain types of programming problems. Java is a
rapidly-evolving language, however, and as each new release comes out it
becomes more and more attractive for solving larger sets of problems.
</FONT><a name="AAA"></a><a name="_Toc408018408"></a><a name="_Toc375545209"></a><P></DIV>
<HR><DIV ALIGN=LEFT><A NAME="fn8" HREF="#fnB8">[8]</A><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">
The material in this section is adapted from an article by the author that
originally appeared on Mainspring, at 
</FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black"><I>www.mainspring.com</I></FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">.
Used with permission.
</FONT><P></DIV>


<div align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0027.html">Prev</a> | <a href="tij0029.html">Next</a>
</div>
</body></html>