Java Server Pages Model 2 architecture

April 2, 2008

Java Server Pages (JSP) technology is well on its way to becoming the preeminent Java technology for building applications that serve dynamic Web content. Java developers love JSP for myriad reasons. Some like the fact that it brings the “write once, run anywhere” paradigm to interactive Web pages; others appreciate the fact that it is fairly simple to learn and lets them wield Java as a server-side scripting language. But most concur on one thing — the biggest advantage of using JSP is that it helps effectively separate presentation from content. In this article, I provide an in-depth look at how you can gain optimal separation of presentation from content by using the JSP Model 2 architecture. This model can also be seen as a server-side implementation of the popular Model-View-Controller (MVC) design pattern. Please note that you should be familiar with the basics of JSP and servlet programming before continuing on, as I do not address any syntax issues in this article.

So, what’s wrong with servlets? 

While JSP may be great for serving up dynamic Web content and separating content from presentation, some may still wonder why servlets should be cast aside for JSP. The utility of servlets is not in question. They are excellent for server-side processing, and, with their significant installed base, are here to stay. In fact, architecturally speaking, you can view JSP as a high-level abstraction of servlets that is implemented as an extension of the Servlet 2.1 API. Still, you shouldn’t use servlets indiscriminately; they may not be appropriate for everyone. For instance, while page designers can easily write a JSP page using conventional HTML or XML tools, servlets are more suited for back-end developers because they are often written using an IDE — a process that generally requires a higher level of programming expertise. When deploying servlets, even developers have to be careful and ensure that there is no tight coupling between presentation and content. You can usually do this by adding a third-party HTML wrapper package like htmlKona to the mix. But even this approach, though providing some flexibility with simple screen changes, still does not shield you from a change in the presentation format itself. For example, if your presentation changed from HTML to DHTML, you would still need to ensure that wrapper packages were compliant with the new format. In a worst-case scenario, if a wrapper package is not available, you may end up hard coding the presentation within the dynamic content. So, what is the solution? As you shall soon see, one approach would be to use both JSP and servlet technologies for building application systems.

Differing philosophies 

The early JSP specifications advocated two philosophical approaches for building applications using JSP technology. These approaches, termed the JSP Model 1 and Model 2 architectures, differ essentially in the location at which the bulk of the request processing was performed. In the Model 1 architecture, shown in Figure 1, the JSP page alone is responsible for processing the incoming request and replying back to the client. There is still separation of presentation from content, because all data access is performed using beans. Although the Model 1 architecture should be perfectly suitable for simple applications, it may not be desirable for complex implementations. Indiscriminate usage of this architecture usually leads to a significant amount of scriptlets or Java code embedded within the JSP page, especially if there is a significant amount of request processing to be performed. While this may not seem to be much of a problem for Java developers, it is certainly an issue if your JSP pages are created and maintained by designers — which are usually the norm on large projects. Ultimately, it may even lead to an unclear definition of roles and allocation of responsibilities, causing easily avoidable project-management headaches.

The Model 2 architecture is a hybrid approach for serving dynamic content, since it combines the use of both servlets and JSP. It takes advantage of the predominant strengths of both technologies, using JSP to generate the presentation layer and servlets to perform process-intensive tasks. Here, the servlet acts as the controller and is in charge of the request processing and the creation of any beans or objects used by the JSP, as well as deciding, depending on the user’s actions, which JSP page to forward the request to. Note particularly that there is no processing logic within the JSP page itself; it is simply responsible for retrieving any objects or beans that may have been previously created by the servlet, and extracting the dynamic content from that servlet for insertion within static templates. In my opinion, this approach typically results in the cleanest separation of presentation from content, leading to clear delineation of the roles and responsibilities of the developers and page designers on your programming team. In fact, the more complex your application, the greater the benefits of using the Model 2 architecture should be.

Forwards and Redirects:-

March 10, 2008

The forward and redirect operation both replace content. The current page is terminated and is replaced with the output of the specified page.

Both <jsp:forward>; and RequestDispatcher.forward() are server side redirects. The redirect operations are performed in the server side, and the browser is unaware of the change. If page1.jsp forwards to page2.jsp the browsers address bar will still show page1.jsp.

The response. Redirect() is a client side redirect. The redirect operation is passed to the browser, which is aware of the change. If page1.jsp redirects to page2.jsp, the browsers address bar will be updated to show page2.jsp.

Forward operations are faster because all the processing happens at the server side.

Redirect operations update the browser history, however which is often desirable. Forward operations are useful when you don’t want the browsers address bar to be update.

With the sendRedirect() you can connect to any URL outside the web application. Whereas the forward () operation will work only within the web application.

The Java Sandbox

March 6, 2008

Discussions of Java’s security model often center on the idea of a sandbox model. The idea behind this model is that when you allow a program to be hosted on your computer, you want to provide an environment where the program can play (i.e., run), but you want to confine the program’s play area within certain bounds. You may decide to give the program certain toys to play with (i.e., you may decide to let it have access to certain system resources), but in general, you want to make sure that the program is confined to its sandbox.

This analogy works better when you consider it from the view of a close relative rather than from the view of a parent. If you’re a parent, you probably consider the purpose of a sandbox to be to provide a safe environment for your child to play in. When my niece Rachel visits me, however, I consider the purpose of a sandbox not (only) to be to protect her, but also to protect my grandmother’s china from her. I love my niece, but I can’t give her leave to run through my house; I enjoy running the latest cool applet on the Internet, but I can’t give it leave to run through my file system.

The Java sandbox is responsible for protecting a number of resources, and it does so at a number of levels. Consider the resources of a typical machine as shown in Figure 1-1. The user’s machine has access to many things.

Figure 1.1

A machine has access to many resources

· Internally, it has access to its local memory (the computer’s RAM).

· Externally, it has access to its file system and to other machines on the local network.

· For running applets, it also has access to a web server, which may be on its local (private) net, or may be on the Internet.

· Data flows through this entire model, from the user’s machine through the network and (possibly) to disk.

Each of these resources needs to be protected, and those protections form the basis of Java’s security model.

We can imagine a number of different-sized sandboxes in which a Java program might run:

· A sandbox in which the program has access to the CPU, the screen, keyboard, and mouse, and to its own memory. This is the minimal sandbox–it contains just enough resources for a program to run.

· A sandbox in which the program has access to the CPU and its own memory as well as access to the web server from which it was loaded. This is often thought of as the default state for the sandbox.

· A sandbox in which the program has access to the CPU, its memory, its web server, and to a set of program-specific resources (local files, local machines, etc.). A word-processing program, for example, might have access to the docs directory on the local file system, but not to any other files.

· An open sandbox, in which the program has access to whatever resources the host machine normally has access to.

The sandbox, then, is not a one-size-fits-all model. Expanding the boundaries of the sandbox is always based on the notion of trust: when my one-year-old niece comes to visit, there’s very little in the sandbox for her to play with, but when my six-year-old godchild comes to visit, I trust that I might give her more things to play with. In the hands of some visitors, a toy with small removable parts would be dangerous, but when I trust the recipient, it’s perfectly reasonable to include that item in the sandbox. And so it is with Java programs: in some cases, I might trust them to access my file system; in other cases, I might trust them to access only part of my file system; and in still other cases, I might not trust them to access my file system at all.

Web Server and an Application Server

February 19, 2008

Web server serves pages for viewing in a web browser while Apps server provides methods that client application can call. The web server exclusively handles HTTP requests where as apps server serves business logic to application program through any number of protocols. Web server cannot handle huge load (handles request/response up to 10,000 request/responses).An apps server is for all types of protocols such as HTTP, FTP, and SMTP so on. An apps server can handle huge request/response.

The web server handles the HTTP protocol. To process a request a web server may respond with a static html page or image, send a redirect or delegate the dynamic response generation to some other program such as CGI scripts, JSP, Servlets, ASP, Serverside javascripts, or some other server side technology. The web server does not provide any functionality beyond simply providing an environment in which the server side program can execute and pass back the generated responses. The web server may not itself support transactions or database connection pooling. It may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering features often times erroneously assigned as features only for application server.

Application server exposes business logic to client application through various protocols. An application server provides access to business logic for use by client application program. The application program can use this logic just as it would call a method on a object. In most cases the server exposes this business logic through component API such as the EJB component model. Moreover the application server manages its own resources such as security, transactions, resource pooling and messaging.

Why Collections Framework in Java?

February 13, 2008

JDK 1.2 introduces a new framework for collections of objects, called the Java Collections Framework.

• It dramatically increases the readability of your collections by providing a standard set of interfaces to be used by many programmers in many applications.
• It makes your code more flexible by allowing you to pass and return interfaces instead of concrete classes, generalizing your code rather than locking it down.
• It offers many specific implementations of the interfaces, allowing you to choose the collection that is most fitting and offers the highest performance for your needs.

And that’s just for starters.
Our tour of the framework will begin with an overview of the advantages it provides for storing sets of objects.

The Java Collections advantage: An overview

Before Collections made its most welcome debut, the standard methods for grouping Java objects were via the array, the Vector, and the Hashtable. All three of these collections have different methods and syntax for accessing members – arrays use the square bracket ([]) symbols, Vector uses the elementAt(), and Hash table uses get and put methods. These differences have long led programmers down the path to inconsistency in implementing their own collections – some emulate the Vector access methods and some emulate the Enumeration interface.

To further complicate matters, most of the Vector methods are marked as final; that is, you cannot extend the Vector class to implement a similar sort of collection. We could create a collection class that looked like a Vector and acted like a Vector, but it couldn’t be passed to a method that takes a Vector as a parameter.

Finally none of the collections (array, Vector or Hashtable) implements a standard member access interface. As programmers developed algorithms (like sorts) to manipulate collections,a heated discourse erupted on what object to pass to the algorithm.Should you pass an array or a Vector? Should you implement both interfaces? Talk about duplication and confusion.

Thankfully, the Java Collections Framework remedies these problems and offers a number of advantages over using no framework or using the Vector and Hashtable.

A usable set of collection interfaces
By implementing one of the basic interfaces – Collection,Set,List,or Map -you ensure your class conforms to a common API and becomes more regular and easily understood. So,whether you are implementing an SQL database, a color swatch matcher, or a remote chat application, if you implement the Collection interface, the operations on your collection of objects are well-known to your users. The standard interfaces also simplify the passing and returning of collections to and from class methods and allow the methods to work on a wider variety of collections.

A basic set of collection implementations
In addition to the trusty Hashtable and Vector, which have been updated to implement the Collection interfaces, new collection implementations have been added, including HashSet and TreeSet, ArrayList and LinkedList, and HashMap and Map. Using an existing, common implementation makes your code shorter and quicker to download. Also, using existing Core Java code core ensures that any improvements to the base code will also improve the performance of your code.

Other useful enhancements
Each collection now returns an Iterator, an improved type of Enumeration that allows element operations such as insertion and deletion. The Iterator is “fail-fast,” which means you get an exception if the list you’re iterating is changed by another user.Also, list-based collections such as Vector return a ListIterator that allow bi-directional iteration and updating.

Several collections (TreeSet and TreeMap) implicitly support ordering. Use these classes to maintain a sorted list with no effort. You can find the smallest and largest elements or perform a binary search to improve the performance of large lists. You can sort other collections by providing a collection-compare method (a Comparator object) or an object-compare method (the Comparable interface).

Finally,a static class Collections provides unmodifiable (read-only) and synchronized versions of existing collections.The unmodifiable classes are helpful to prevent unwanted changes to a collection. The synchronized version of a collection is a necessity for multithreaded programs.

Security in Java

February 13, 2008

The security in java is implemented at four different levels.

1) Language and the compiler – The language and the compiler acts as the first level security.
• Java program has no direct access to memory.
• No arbitrary type casting.
• Strongly typed language.

2) Byte code verifier – The byte code verifier acts as the second level of security. It ensures or checks whether the byte code coming is coming from a worthy compiler or not. It ensures that the code sticks to java standard and does not violate system integrity. The byte code verifier checks that the code does not have
• Forged pointers
• Access restriction violations
• Object mismatching
• Operand stack over or under flows
• Incorrect byte code parameters
• Illegal data conversions

3) Class loader– The class loader acts as the next level of security. The class loader loads all the classes needed for the execution of a program. The class loader allocates memory spaces for each class and ensures that code does not attempt to by pass the built in class. In other words programmers cannot write their own version of an existing built in class and have it executed instead of the default one. The built in classes are always checked first.

4) Sandbox – This is the next level of security. This is applied to applications which are remotely added. This is also known as sandbox model. The first three levels of security are hidden from the user and the java developers while the fourth level is not.