JSP technology speeds the development of dynamic web pages in a number of ways:

* Separating content generation from presentation

Using JSP technology, web page developers use HTML or XML tags to design and format the results page. They use JSP tags or scriptlets to generate the dynamic content (the content that changes according to the request, such as requested account information or the price of a specific bottle of wine). The logic that generates the content is encapsulated in tags and JavaBeans components and tied together in scriptlets, all of which are executed on the server side. If the core logic is encapsulated in tags and beans, then other individuals, such as web masters and page designers, can edit the JSP page without affecting the generation of the content.

On the server, a JSP engine interprets JSP tags and scriptlets, generates content (for example, by accessing JavaBeans components, accessing a database with JDBCTM technology, or including files), and sends the results back in the form of an HTML (or XML) page to the browser. This helps authors protect proprietary code while ensuring complete portability for any HTML-based web browser.

* Emphasizing reusable components

Most JSP pages rely on reusable, cross-platform components (JavaBeans or Enterprise JavaBeansTM components) to perform the more complex processing required of the application. Developers can share and exchange components that perform common operations, or make them available to larger user or customer communities. The component-based approach speeds overall development and lets organizations leverage their existing expertise and development efforts for optimal results.

* Simplifying page development with tags

Web page developers are not always programmers familiar with scripting languages. The JavaServer Pages technology encapsulates much of the functionality required for dynamic content generation in easy-to-use, JSP-specific XML tags. Standard JSP tags can access and instantiate JavaBeans components, set or retrieve bean attributes, download applets, and perform other functions that are otherwise more difficult and time-consuming to code.

The JSP technology is extensible through the development of customized tag libraries. Over time, third-party developers and others will create their own tag libraries for common functions. This lets web page developers work with familiar tools and constructs, such as tags, to perform sophisticated functions.

// By Ricky

Java Platform, Enterprise Edition is a platform for developing robust, scalable enterprise applications. Here are some highlights:

* Easier development. The focus in Java EE is ease of development. With Java EE , there is less code to write — much of the boilerplate code has been removed, defaults are used whenever possible, and annotations are used extensively to reduce the need for deployment descriptors.

* Enhanced web services. Java EE includes simplified web services support and the latest web services APIs, making it an ideal implementation platform for Service-Oriented Architectures (SOA).

* EJB -- simpler, better. EJB 3.0 makes programming with Enterprise JavaBeans technology simpler through the use of Plain Old Java Objects (POJOs), it also introduces a new persistence API.

* JSF, JSTL, AJAX, and more. Constructing web applications is made easier with JavaServer Faces (JSF) technology and the JSP Standard Tag Library (JSTL). Java EE supports rich thin-client technologies such as AJAX, technologies that are crucial for building applications for Web 2.0.

// By Ricky

Web applets have popularized the idea of downloading and executing untrusted compiled code on
the personal computer running the Web browser, without user’s approval or intervention. Obviously,
this raises major security issues: without appropriate security measures, a malicious applet
could mount a variety of attacks against the local computer, such as destroying data (e.g. reformatting
the disk), modifying sensitive data (e.g. registering a bank transfer via a home-banking
software [5]), divulging personal information over the network, or modifying other programs (Trojan
attacks).
Beyond Web services, the applet model is now being transferred to high-security embedded
devices such as smart cards: the Java Card architecture [6] allows for post-issuance downloading of
applets on smart cards. Smart cards are used as security tokens in sensitive application areas such
as payment, mobile telephony, and authentication. This makes the security issues with applets
even more acute.
The solution put forward by the Java programming environment is to execute the applets in a
so-called “sandbox”, which is an insulation layer preventing direct access to the hardware resources
and implementing a suitable access control policy [18, 54, 34]. The security of the sandbox model
relies on the following three components:
1. Applets are not compiled down to machine executable code, but rather to bytecode for a
virtual machine. The virtual machine manipulates higher-level, more secure abstractions of
data than the hardware processor, such as object references instead of memory addresses.
2. Applets are not given direct access to hardware resources such as the serial port, but only
to a carefully designed set of API classes and methods that perform suitable access control
before performing interactions with the outside world on behalf of the applet.

Bytecodes are the machine language of the java virtual machine. When a JVM loads a class file, it gets one stream of bytecodes for each method in the class. The bytecodes streams are stored in the method area of the JVM. The bytecodes for a method are executed when that method is invoked during the course of running the program. They can be executed by intepretation, just-in-time compiling, or any other technique that was chosen by the designer of a particular JVM.

A method’s bytecode stream is a sequence of instructions for the Java virtual machine. Each instruction consists of a one-byte opcode followed by zero or more operands. The opcode indicates the action to take. If more information is required before the JVM can take the action, that information is encoded into one or more operands that immediately follow the opcode.