J2EE (Java Enterprise Edition)

The Java 2 Platform, Enterprise Edition (J2EE) is a set of coordinated specifications and practices that together enable solutions for developing, deploying, and managing multi-tier server-centric applications. Building on the Java 2 Platform, Standard Edition (J2SE), the J2EE platform adds the capabilities necessary to provide a complete, stable, secure, and fast Java platform to the enterprise level. It provides value by significantly reducing the cost and complexity of developing and deploying multi-tier solutions, resulting in services that can be rapidly deployed and easily enhanced.

Java 2 Enterprise Edition. A development environment which is independent of hardware systems and operating systems. The idea is that software developers need only write applications once and these applications can then be run unchanged on any computer or operating system.

J2EE is an open standard, pioneered by Sun Microsystems, for creating and delivering multi-tiered enterprise applications in the Java language.

Benefits

Complete Web services support. The J2EE platform provides a framework for developing and deploying web services on the Java platform
Faster solutions delivery time to market. The J2EE platform uses "containers" to simplify development. J2EE containers provide for the separation of business logic from resource and lifecycle management, which means that developers can focus on writing business logic -- their value add -- rather than writing enterprise infrastructure. For example, the Enterprise JavaBeans (EJB) container (implemented by J2EE technology vendors) handles distributed communication, threading, scaling, transaction management, etc. Similarly, Java Servlets simplify web development by providing infrastructure for component, communication, and session management in a web container that is integrated with a web server.

Simplified connectivity. J2EE technology makes it easier to connect the applications and systems you already have and bring those capabilities to the web, to cell phones, and to devices. J2EE offers Java Message Service for integrating diverse applications in a loosely coupled, asynchronous way. The J2EE platform also offers CORBA support for tightly linking systems through remote method calls. In addition, the J2EE platform has J2EE Connectors for linking to enterprise information systems such as ERP systems, By offering one platform with faster solution delivery time to market, freedom of choice, and simplified connectivity

The primary technologies in the J2EE

The primary technologies in the J2EE platform are: Java API for XML-Based RPC (JAX-RPC), JavaServer Pages, Java Servlets, Enterprise JavaBeans components, J2EE Connector Architecture, J2EE Management Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE Authorization Contract for Containers, Java API for XML Registries (JAXR), Java Message Service (JMS), Java Naming and Directory Interface (JNDI), Java Transaction API (JTA), CORBA, and JDBC data access API And Hibernate

Client-server Review

Java originally made its debut in browsers and client machines; at the time, many questioned whether it was suitable for server-side development. Now, with increasing third-party support for the Java 2 Platform, Enterprise Edition (J2EE), Java has become a widely accepted alternative for developing enterprise-strength server-side solutions.
The J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered Web-based applications.
In this article, we will examine the 13 core technologies that make up J2EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF. We will describe where and when it is appropriate to use each technology; we will also describe how the different technologies interact with each other.

In the past, two-tier applications -- also known as client/server applications -- were commonplace. Figure 1 illustrates the typical two-tier architecture. In some cases, the only service provided by the server was that of a database server. In those situations, the client was then responsible for data access, applying business logic, converting the results into a format suitable for display, displaying the intended interface to the user, and accepting user input. The client/server architecture is generally easy to deploy at first, but is difficult to upgrade or enhance, and is usually based on proprietary protocols -- typically proprietary database protocols. It also makes reuse of business and presentation logic difficult, if not impossible. Finally, and perhaps most important in the era of the Web, two-tier applications typically do not prove very scalable and are therefore not well suited to the Internet.

Client: Presentation Logic, Business Logic, Data Access Logic
Server: Business Logic, Data Access Logic

Sun designed J2EE in part to address the deficiencies of two-tier architectures. As such, J2EE defines a set of standards to ease the development of n- tier enterprise applications. It defines a set of standardized, modular components; provides a complete set of services to those components; and handles many details of application behavior -- such as security and multithreading -- automatically.
Using J2EE to develop n- tier applications involves breaking apart the different layers in the two-tier architecture into multiple tiers. An n- tier application could provide separate layers for each of the following services:
• Presentation: In a typical Web application, a browser running on the client machine handles presentation.
• Dynamically generated presentation: Although a browser could handle some dynamically generated presentation, for the widest support of different browsers much of the action should be done on the Web server using JSPs, servlets, or XML (Extensible Markup Language) and XSL (Extensible Stylesheet Language).
• Business logic: Business logic is best implemented in Session EJBs (described later).
• Data access: Data access is best implemented in Entity EJBs (described later) and using JDBC.
Backend system integration: Integration with backend systems may use a variety of technologies. The best choice will depend upon the exact nature of the backend system.
n-tiered Applications ( Deployment Architecture )
An n-tier application program is one that is distributed among three or more separate computers in a distributed network. The most common form of n-tier (meaning 'some number of tiers') is the 3-tier application , in which user interface programming is in the user's computer, business logic is in a more centralized computer, and needed data is in a computer that manages a database .
N-tier application structure implies the client/server program model. Where there are more than three distribution levels or tiers involved, the additional tiers in the application are usually associated with the business logic tier.
In addition to the advantages of distributing programming and data throughout a network, n-tier applications have the advantages that any one tier can run on an appropriate processor or operating system platform and can be updated independently of the other tiers. Communication between the program tiers uses special program interfaces such as those provided by the Common Object Request Broker Architecture ( CORBA ).

J2EE Overview

Java 2 Enterprise Edition (J2EE) provides an object-oriented, distributed and cross-platform framework for developing and deploying robust, secure and scalable E-Business and E-Commerce applications. J2EE enables efficient development of enterprise applications, while leveraging investments in existing business resources such as Database Systems, Messaging Systems and Naming and Directory Services. Using J2EE, enterprise developers may implement business objects using the Enterprise JavaBeans (EJB) technology and deploy them across a wide range of J2EE compliant application servers. Enterprise developers may also build sophisticated clients for their E-Business applications using the Java Servlet, Java Server Pages (JSP), XML or the Java Applet technologies. These clients may be packaged and deployed on a Web Container. J2EE enables component-based development of both the business logic and the presentation logic. Using this approach, enables the development of thin HTML, DHTML and JavaScript based clients. J2EE also supports the development of complex clients as regular Java applications and applets.

The J2EE platform provides access to a host of enterprise services using well-defined and standard Java Enterprise APIs that are listed below.
* Enterprise JavaBeans (EJB)
* extensible Markup Language (XML)
* Servlets
* Java Server Pages (JSP)
* Java Messaging Service (JMS)
* Java Database Connectivity (JDBC)
* JavaMail
* JavaIDL
* Java Naming and Directory Interface (JNDI)
* Java RMI/IIOP
* Java Transaction Services (JTS) and Java Transaction API (JTA)
Note: Two of the common and proven architectures for Java-based web applications.
1. Page Centric(Model -1) : all the display logic, business logic, and data are contained in JSP page

2. MVC (Model-2)

Model View Controller (Application Architecture)

Model Layer Technologies

Model A model represents an application's data and contains the logic for accessing and manipulating that data. Any data that is part of the persistent state of the application should reside in the model objects. The services that a model exposes must be generic enough to support a variety of clients. By glancing at the model's public method list, it should be easy to understand how to control the model's behavior. A model groups related data and operations for providing a specific service; these group of operations wrap and abstract the functionality of the business process being modeled.

A model's interface exposes methods for accessing and updating the state of the model and for executing complex processes encapsulated inside the model. Model services are accessed by the controller for either querying or effecting a change in the model state. The model notifies the view when a state change occurs in the model

View Layer Technologies

Controller The controller is responsible for intercepting and translating user input into actions to be performed by the model. The controller is responsible for selecting the next view based on user input and the outcome of model operations

Controller Layer Technologies

View The view is responsible for rendering the state of the model. The presentation semantics are encapsulated within the view, therefore model data can be adapted for several different kinds of clients. The view modifies itself when a change in the model is communicated to the view. A view forwards user input to the controller

“Glue” Technologies (Multi- Layer)

Glue is a distributed computing platform for Java, Glue Technology, delivers an open, Java and XML-based platform for seamlessly integrating distributed applications and Web services

GLUE, a simple, fast and comprehensive Java platform for creating, deploying and consuming web services, now includes many new features, including:

- Support for JAX/RPC enumerations
- Improved Wsdl2java and Java2wsdl utilities
- Source code for JBuilder plugin
- Support for com.sun.java.util collections
- JMS adaptor for Sonic MQ
- Enhanced .NET interoperability
- Native DOM support
- Fresh new look for user guide
- Support for UDDI version 2 operations
- iPlanet integration

Built 100% on standards like XML, SOAP, WSDL and UDDI, you can use GLUE to create software building blocks that are language, platform and location independent. GLUE can be used standalone or hosted in a third party application server.

GLUE can publish a Java object as a web service with just one line of code, and invoke remote web services as if they were local Java objects. GLUE generates proxies and WSDL on the fly, so you don't have to mess around with old-fashioned static development utilities.

GLUE standard ships as a 580K .jar file and is free for most commercial uses. GLUE professional adds enterprise features such as EJB integration, JMS integration and a UDDI server.

Glueware is Glue Technology's premier software engine that enables interoperability between partner and customer legacy systems and applications for real-time collaboration and business process automation.

Glueware enables non-intrusive integration with backend-systems and existing IT infrastructures, and makes it possible for existing IT infrastructures to provide Web services and to collaborate in P2P processes

Glue's READI (Rapid Enterprise Application Development for the Internet) methodology covers the entire development lifecycle from business analysis to architecture design to development and deployment

J2EE Application Servers

There are Many Application Server as like Apache Tomcat, GlassFish, Sun Java System Application Server, BEA Web Logic Server, IBM Web Sphere Application Server, JBoss Application Server

Introduction to Servlets

What are Servlets?

Servlets are snippets of Java programs which run inside a Servlet Container. A Servlet Container is much like a Web Server which handles user requests and generates responses. Servlet Container is different from a Web Server because it can not only serve requests for static content like HTML page, GIF images, etc. it can also contain Java Servlets and JSP pages to generate dynamic response. Servlet Container is responsible for loading and maintaining the lifecycle of the a Java Servlet. Servlet Container can be used standalone or more often used in conjunction with a Web server. Example of a Servlet Container is Tomcat and that of Web Server is Apache.

Servlets are actually simple Java classes which must implement the javax.servlet.Servlet interface. This interface contains a total of five methods. Most of the time you don't need to implement this interface. Why? Because javax.servlet package already provides two classes which implement this interface i.e. GenericServlet and HttpServlet . So all you need to do is to extend one of these classes and override the method(s) you need for your Servlet. GenericServlet is a very simple class which only implements the javax.servlet.Servlet interface and provides only basic functionality. On the other hand, HttpServlet is a more useful class which provides methods to work with the HTTP protocol. So if your Servlet works with HTTP protocol (in most cases this will be the case) then you should extend javax.servlet.http.HttpServlet class to build Servlets

Servlets once initialized are kept in memory. So every request which the Servlet Container receives, is delegated to the in-memory Java Servlet which then generates the response. This 'kept in memory' feature makes Java Servlets, a fast and efficient method of building Web Applications.

Servlets are server side components that provide a powerful mechanism for developing server side programs. Servlets provide component-based, platform-independent methods for building Web-based applications, without the performance limitations of CGI programs. Unlike proprietary server extension mechanisms (such as the Netscape Server API or Apache modules), servlets are server as well as platform-independent. This leaves you free to select a "best of breed" strategy for your servers, platforms, and tools. Using servlets web developers can create fast and efficient server side application which can run on any servlet enabled web server. Servlets run entirely inside the Java Virtual Machine. Since the Servlet runs at server side so it does not checks the browser for compatibility. Servlets can access the entire family of Java APIs, including the JDBC API to access enterprise databases. Servlets can also access a library of HTTP-specific calls, receive all the benefits of the mature java language including portability, performance, reusability, and crash protection. Today servlets are the popular choice for building interactive web applications. Third-party servlet containers are available for Apache Web Server, Microsoft IIS, and others. Servlet containers are usually the components of web and application servers, such as BEA WebLogic Application Server, IBM WebSphere, Sun Java System Web Server, Sun Java System Application Server and others.

Servlets are not designed for a specific protocols. It is different thing that they are most commonly used with the HTTP protocols Servlets uses the classes in the java packages javax.servlet and javax.servlet.http. Servlets provides a way of creating the sophisticated server side extensions in a server as they follow the standard framework and use the highly portable java language.

HTTP Servlet typically used to:

* Priovide dynamic content like getting the results of a database query and returning to the client.
* Process and/or store the data submitted by the HTML.
* Manage information about the state of a stateless HTTP. e.g. an online shopping car manages request for multiple concurrent customers.

HTTP Requests

HTTP is a simple, stateless protocol. A client, such as a web browser, makes a request, the web server responds, and the transaction is done. When the client sends a request, the first thing it specifies is an HTTP command, called a method , that tells the server the type of action it wants performed. This first line of the request also specifies the address of a document (a URL) and the version of the HTTP protocol it is using. For example: GET /intro.html HTTP/1.0

This request uses the GET method to ask for the document named intro.html , using HTTP Version 1.0. After sending the request, the client can send optional header information to tell the server extra information about the request, such as what software the client is running and what content types it understands. This information doesn't directly pertain to what was requested, but it could be used by the server in generating its response. Here are some sample request headers:

The User-Agent header provides information about the client software, while the Accept header specifies the media (MIME) types that the client prefers to accept. (We'll talk more about request headers in the context of servlets After the headers, the client sends a blank line, to indicate the end of the header section. The client can also send additional data, if appropriate for the method being used, as it is with the POST method that we'll discuss shortly. If the request doesn't send any data, it ends with an empty line.

After the client sends the request, the server processes it and sends back a response. The first line of the response is a status line that specifies the version of the HTTP protocol the server is using, a status code, and a description of the status code. For example: HTTP/1.0 200 OK

This status line includes a status code of 200, which indicates that the request was successful, hence the description "OK". Another common status code is 404, with the description "Not Found"--as you can guess, this means that the requested document was not found.

After the status line, the server sends response headers that tell the client things like what software the server is running and the content type of the server's response. For example:

The Server header provides information about the server software, while the Content-type header specifies the MIME type of the data included with the response. The server sends a blank line after the headers, to conclude the header section. If the request was successful, the requested data is then sent as part of the response. Otherwise, the response may contain human-readable data that explains why the server couldn't fulfill the request.

In addition to GET and POST, there are several other lesser-used HTTP methods. There's the HEAD method, which is sent by a client when it wants to see only the headers of the response, to determine the document's size, modification time, or general availability. There's also PUT, to place documents directly on the server, and DELETE, to do just the opposite. These last two aren't widely supported due to complicated policy issues. The TRACE method is used as a debugging aid--it returns to the client the exact contents of its request. Finally, the OPTIONS method can be used to ask the server which methods it supports or what options are available for a particular resource on the server.

DoGet() vs doPost()

When a client connects to a server and makes an HTTP request, the request can be of several different types, called methods. The most frequently used methods are GET and POST. Put simply, the GET method is designed for getting information (a document, a chart, or the results from a database query), while the POST method is designed for posting information (a credit card number, some new chart data, or information that is to be stored in a database). To use a bulletin board analogy, GET is for reading and POST is for tacking up new material.

The GET method, although it's designed for reading information, can include as part of the request some of its own information that better describes what to get--such as an x, y scale for a dynamically created chart. This information is passed as a sequence of characters appended to the request URL in what's called a query string . Placing the extra information in the URL in this way allows the page to be bookmarked or emailed like any other. Because GET requests theoretically shouldn't need to send large amounts of information, some servers limit the length of URLs and query strings to about 240 characters.

The POST method uses a different technique to send information to the server because in some cases it may need to send megabytes of information. A POST request passes all its data, of unlimited length, directly over the socket connection as part of its HTTP request body. The exchange is invisible to the client. The URL doesn't change at all. Consequently, POST requests cannot be bookmarked or emailed or, in some cases, even reloaded. That's by design--information sent to the server, such as your credit card number, should be sent only once.

In practice, the use of GET and POST has strayed from the original intent. It's common for long parameterized requests for information to use POST instead of GET to work around problems with overly-long URLs. It's also common for simple forms that upload information to use GET because, well--why not, it works! Generally, this isn't much of a problem. Just remember that GET requests, because they can be bookmarked so easily, should not be allowed to cause damage for which the client could be held responsible. In other words, GET requests should not be used to place an order, update a database, or take an explicit client action in any way.

Sending the response

After the client sends the request, the server processes it and sends back a response. The first line of the response is a status line that specifies the version of the HTTP protocol the server is using, a status code, and a description of the status code.

The HttpServletResponse class
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("");
out.println("Hello World");
out.println("");
out.println("Hello World");
out.println("");
} }

This servlet uses two methods and a class that have been only briefly mentioned before. The setContentType() method of ServletResponse sets the content type of the response to be the specified type:

public void ServletResponse.setContentType(String type)
In an HTTP servlet, this method sets the Content-Type HTTP header.
The getWriter() method returns a PrintWriter for writing character-based response data:
public PrintWriter ServletResponse.getWriter() throws IOException