Developing J2EE

Developers must implement a strategy and design that offers flexibility, scalability, and reuse of application components. Application responsibilities include application start-up and shutdown, accessing external properties, error handling, and applying interface preferences.

Developing and deploying a J2EE application requires three distinct phases: development, assembly, and deployment. During development, web component providers and developers build components that encapsulate presentation logic.

The reusable components are deployed as WAR files. EJB component developers create the EJB components that encapsulate business logic, and subsequently deploy them as EJB-JAR files.

In the assembly phase, an assembler puts together both the WAR and EJB-JAR files and merges them into an EAR file. The assembler is responsible for examining both types of files and customizes fields in the deployment descriptor file.

Finally, the deployer examines the EAR file, resolving any external dependencies, and configures the application to execute and deploy in an operational environment.

Several different development models exist within the Java environment. They include the time-tested traditional client-server model, which is similar to the web services client-server model. A client submits an HTML-based request to the server for processing server-side business logic.

This process typically involves submitting updates, deletes, storing, and retrieving data to a relational database. Other traditional development models include the following:

• Remote presentation model
• Distributed logic model
• Remote data management model
• Distributed data management model
• Web-Based Remote Presentation Model

In the remote presentation model, commonly referred to as the thin client paradigm, the only tool a client needs for communicating with the server is a web enabled browser for submitting HTML-based requests via the HTTP transmission protocol to the server.

This model represents a simple request-response solution. All business logic sits on the server. The user invokes the desired web service, which redirects the client request to a service provider.

This development model offers the following benefits:

• All server-side components, including business logic, servlets, Java Server Pages, and data management components, reside on the server.
• The server-side controller (a servlet) provides dynamic content to a client.
• The only tool needed is a web browser.

Developers have chosen our java hosting solutions for to trust their projects.

Developers face minimal challenges when utilizing this model. They must deal with exception handling and noncompliant user agents—that is, the inconsistencies between Netscape, Mozilla, Opera, and Internet Explorer. For example, an HTML presentation in Internet Explorer differs from a servlet streaming HTML raw output to a Netscape browser. Presenting a consistent display to the client requires extensive testing and making provisions for outputting the correct formatted data in different browsers by querying a browser for its version, for example.

The web server is a server-side program that invokes a servlet to manage and execute a server application. The servlet's chief task extends the functionality of a web server and functions in two separate capacities.

It can stream HTML to a client as a response to its request, or it can serve as manager by receiving client requests and delegating the task to the appropriate JavaBean or Enterprise JavaBean for business logic processing. Once the task is complete, the servlet calls a Java Server Page to stream the results via HTML back to the client.

The latter role is preferable because it separates presentation data from business logic.

Servlets interface with existing JavaBeans or Enterprise JavaBeans. In either case, they access databases or transactional systems, providing such core services as user authentication, authorization, and session management.

The servlet's life cycle defines the business process by loading the servlet into memory, executing the servlet, and finally, unloading it from memory. The client provides a URL that identifies a specific servlet in order to access the servlet and leverage its services.

Servlets offer excellent security by running within the context of a container such as WebSphere's application server.

The container is responsible for providing low-level application services such as automated garbage collection, memory management, user authorization, and authentication.