Get the latest Java books
h t t p : / /w w w . j a v a c o f f e e b r e a k . c o m /
Looking for Java resources? Check out the Java Coffee Break directory!
Q: What do you see has been the biggest change affecting the Java community in the last year?
A: One of the biggest changes is that twelve months ago, some businesses still needed to be convinced that they should be using Java. Today, there is no longer any need to sell the technology, but rather the issue has become simply how and where to best leverage Java to achieve one's goals.
Another important change that also factors into this widespread adoption of the technology is the availability of scalable application servers that support the Java 2 Platform Enterprise Edition (J2EE). Businesses now have their choice of numerous mature commercial products on which to base their Enterprise applications.
Q: How does Java Server Pages stack up to competing technologies like Microsoft's Active Server Pages (ASP)? Can JSP match the performance and scalability of ASP, or should developers be looking at other issues such as portability and ease-of-use?
A: The most important thing to consider when comparing these two technologies is that Java Server Pages (JSP) are designed to be platform and server independent, while Active Server Pages (ASP) are built on technologies that run natively only on the Microsoft platform. So, if you need to develop and/or deploy your solution on multiple platforms and/or servers, then JSP will provide a more flexible and powerful solution.
Additionally, JSP pages are compiled and cached in memory, providing extremely fast response time, while ASP pages are normally reinterpreted for each request. In terms of scalability, one need simply look at the growing number of cross-platform, scalable application servers on the market that support the Java 2 Platform Enterprise Edition (J2EE) of which JSP is an integral part. Not only do these containers provide high-performance, scalable, and secure environments that will run on multiple operating systems and hardware platforms, but the fact that they are fully J2EE compliant means the developer has the ability to integrate and leverage the large number of industry-standard Java libraries and APIs, such as:
So, it is hard to argue with the power and flexibility one has when leveraging JSP in combination with the J2EE for developing, deploying, and managing scalable and flexible, service-based architectures.
Q: How do you see JSP in relation to Java servlets? There seems to be a fair bit of overlap between the two. Are there some situations where JSP is preferable to servlets, and vice versa?
A: JSPs are built on Servlet semantics, so the evolution of each of these APIs is important to the JSP community. Version 1.0 of the JSP specification is based on the Servlet API version 2.1. Version 1.1 of the JSP specification is based on the Servlet API version 2.2.
A JSP page in source form looks more or less like an HTML page, while servlet source is composed entirely of Java code. When servlets alone are used, developers often embed HTML markup directly within their servlet's Java code. Conversely, when developers first encounter JSP, they often embed lots of Java code within their JSPs' HTML. Neither situation is ideal, since each involves overly intermingling business logic with presentation.
One way to think about this issue is to consider the multiple roles that exist on a project. There are individuals who fulfill a software development role and individuals who fulfill a web-production role. Software developers are comfortable working with Java artifacts, such as servlets, while the web-production team is often better suited to deal with the design and layout issues of an HTML presentation page. The aforementioned scenarios, where we have lots of Java mixed with HTML, means that we cannot cleanly separate the work that these individuals have to perform. We have introduced dependencies that can lead to time delays as well as a more buggy environment. As we reduce these dependencies, we create a cleaner role separation and a more efficient and productive work environment.
So, how do we improve this situation? We try and separate our Java code (business logic) from our HTML (presentation markup) as much as possible. But how do we decide what to put where?
In a nutshell:
So, now the question arises:
I refer to this process as "Factor-Forward-Factor Back", and it can be seen visually
Now we have servlets that handle business logic that is common across requests, such as authentication and authorization. We also have JSP pages which include very little Java code, but rather use snippets of Java along with JSP tags to interact with a helper (or worker) bean. The helper bean is simply a non-visual JavaBean that is a container for the request specific business logic, and is also responsible for adapting and validating the intermediate model for display.
As we can see, then, servlets and JSPs complement one another and are used in combination with JavaBeans in order to handle the presentation portion of a J2EE-based architecture.
Q: How do you see Java Server Pages fitting into the framework of the Java 2