4.2 Technologies involved

< Day Day Up >

The integration techniques described in this chapter rely on several technologies; this section is a brief introduction to them. It begins with a look at J2EE and a description of some of its components, then provides a closer look at JavaServer Pages (JSP) technology and custom JSP Tag libraries.

4.2.1 J2EE overview

The benefits of Java 2 Enterprise Edition (J2EE)and its basic architecture and components are described in this section.

J2EE is a set of synchronized standards and practices that when used together enable solutions for developing, deploying, and managing multi-tier distributed server-centric applications. It is based on the Java 2 Standard Edition (J2SE, formerly called Java Runtime Environment or JRE), which has been complemented with enterprise standards that provide a scalable, robust, secure, and stable platform to build enterprise solutions. It enables developers to extend existing solutions by creating applications quickly, with reduced complexity, cost, and facilities.

A platform for enterprise solutions

Java 2 Enterprise Edition defines a set of standard technologies for developing multi-tier, distributed enterprise applications. J2EE lowers the risk for developers and customers since it's based on a standard and modular architecture. It also can simplify enterprise applications by taking advantage of a complete set of services to help avoid the most common pitfalls of application development, and automatically handling many details of your application without complex programming.

J2EE takes advantage of characteristics such as the "write once, run anywhere" paradigm, which enables Java programs to run on different platforms without requiring rewriting of the entire application. Also, it takes advantage of other well known technologies, like JDBC and CORBA, for interaction with existing enterprise information systems. It is based on a robust security implementation that will protect the data as it is exposed to public networks. Furthermore, J2EE includes a complete set of standards, compliance tests, and documented best practices that assure the stability and portability of applications across different platforms.

Benefits of developing with J2EE

J2EE provides the Lotus Domino developer with the following benefits:

J2EE will build enterprise solutions quickly and get robust solutions to market faster.

J2EE is based on containers which provide a clear separation of business components and enterprise services, which focuses developers on writing business logic rather than spending precious time on developing infrastructure code. For example, the Enterprise JavaBeans (EJB) components (implemented by J2EE) handle distributed communication, threading, scaling, transaction management, messaging infrastructure, and lots of others requirements of modern applications. Similarly, Java Servlets and JavaServer Pages (JSP) simplify Web development by providing a flexible infrastructure for component communication, and session management in Web applications that is integrated with the Web server.
Standards.

J2EE is a set of technologies that many vendors can implement and extend. Vendors like IBM with it's WebSphere Application Server, are free to extend on implementations but not on standards or APIs. Sun Microsystems provides a complete J2EE Compatibility Test Suite (CTS) to grant J2EE interoperability. The J2EE CTS helps ensure compatibility among the application vendors, which helps in ensuring portability of the applications and components written on J2EE. J2EE brings the "write once, run anywhere" paradigm to the server.

Figure 4-1: IBM WebSphere commitments on Open Standards
Separation of tiers.

J2EE brings to the Lotus Domino developer the capacity to separate the business logic from the presentation layer. By doing this the developer builds components that are loosely coupled, providing openness to your development environment and reusability to your software.
Extended connectivity.

J2EE will enable your applications to connect to external applications through technologies and standards (like the Java Connector Architecture and Java Messaging Service) that let you easily expose current business logic to Web applications, and that can serve different clients (Web browsers, cell phones, pervasive devices, voice systems), offering the basis of a multichannel e-business infrastructure. J2EE also offers CORBA support for external systems through remote method calls.

J2EE offers a platform with faster solution development time, freedom of choice, code reuse and extended connectivity. J2EE helps developers and customers to reduce Total Cost of Ownership (TCO), time to market, and take advantage of the evolving standards communities, while avoiding locking into a single provider for the infrastructure needed to build an e-business platform.

Technologies included in J2EE

Some of the technologies in the J2EE platform are:

JavaServer Pages (JSPs)
Java Servlets
Enterprise JavaBeans (EJBs)
J2EE Connector Architecture
Java Management Extensions (JMX)
Java API for XML Registries (JAXR)
Java API for XML-Based RPC (JAX-RPC)
Java Message Service (JMS)
Java Naming and Directory Interface (JNDI)
Java Transaction API (JTA)
CORBA
JDBC data access API

For updated standards and levels for each standard, check with the J2EE official Web site.

J2EE focus on portlet development for Domino developers

One of the main advantages and strengths that J2EE brings from a design point of view is the separation of the tiers or layers that compose an e-business application. Unlike a Lotus Domino application where all the data, business logic, and presentation objects are packed on a single .NSF file, in the J2EE design pattern there are several separate containers which represent different logical tiers, as depicted Figure 4-2. A brief explanation of these tiers follows.

click to expand
Figure 4-2: J2EE design

Database tier

Viewing the figure from right to left, the first tier is the Database tier. This tier is not included in J2EE and is accessed directly by a technology called JDBC, which provides access to the application data stored on relational databases. From a J2EE developer point of view this tier is basically a provider of data access and storage.

EJB container tier

Next is the EJB container tier, which is a J2EE runtime component. You would place business logic here by using Java components called Enterprise Java Beans (EJB), which actually are designed to provide seamless access to relational databases and enterprise information systems (EIS) with transactional integrity. Along with the data storage and access facilities, you can embed the business logic of your application in these components since they offer high performance and availability mechanisms that can be accessed from different channels of communication, not just through the Web.

Web container tier

The next tier is the Web container (also a J2EE runtime component), which is designed to construct presentation components and control presentation logic. It is based on technologies that offer a high performance, extendible presentation framework to build upon, like Servlets and JavaServer Pages. The Web container is also the host of other technologies, such as Web Services and XML-XSLT applications, that enable your applications to extend to other channels of interaction.

Client tier

The final layer is the client tier, which is represented by two types of client. The most commonly used is the thin client Web browser, which basically understands and renders the HTML or XHTML broadcast from the Web container into Web pages. Inside the browser you can have a Java component called Applets, which as shown in the diagram can only access the J2SE basic services. Also there is another type of client, called the J2EE Client container, because J2EE allows a client-server configuration. This fat client has access to several J2EE services; it is used when the use of external devices and usability issues arise that the Web Browser is unable to attend.

Additional thoughts on J2EE

The Web container and the EJB container are the two main blocks that construct a J2EE application server. The WebSphere Portal allows the construction of Portlet applications that will reside on the Web container, so our focus remains on this container as we explore the JSP - Domino custom JSP tag libraries option of portalizing Lotus Domino applications.

The Portlet components extend the Servlet component, and can present its information using JSP pages. And since JSP development is part of the Lotus Domino development environment, it seems natural to understand and unleash the power of JSPs in the portal environment.

First, let's take a closer look to the JavaServer Pages (JSP) component.

4.2.2 JavaServer Pages

A JavaServer Page, or JSP, is a simple but very powerful component of J2EE. It allows you to easily create content for Web applications while maintaining the ability to include information, generated on the fly, that can be computed by Java code or extracted from other third party systems like, in our case, Lotus Domino applications.

The JSP allows the developer to mix the robust advantages of the Java language and the visual facilities of HTML editors like WebSphere Studio.

Definition of a JSP

A JSP is a standard file that is written basically in HTML, which can include special tags to let developers include dynamic content for Web applications. From a Java point of view it extends the Servlet component used in most J2EE Web applications. The JSP files end with a .JSP extension.

The following code snippet contains the code of a simple JSP file.

Example 4-1: JSP sample snippet

 <html> <body> <% out.println("Hello World !!"); %> </body> </html>

As you can see, this snippet looks much like a standard HTML file, with some special tags that contain Java code inside. The output of this JSP will be a Hello World !! message on the Web browser.

The JSP file is stored on the file system in a text format and it is compiled when the first request is made through a Web browser. Figure 4-3 illustrates the steps a JSP goes through during that first request.

click to expand
Figure 4-3: Process of serving the first JSP request

As you can see, the JSP is compiled at runtime into a Servlet, and any subsequent request is served by the compiled Servlet. Most J2EE application servers, like WebSphere Application Server, can check on a preset schedule whether the original JSP has changed; if there is a change, the JSP file is recompiled.

There are several elements in a JSP file, one of which will help us include JSP Tag libraries. The elements included in a JSP file are briefly described in the following section.

Elements of a JSP

The JSP files can embed Java code through the use of special tags. These tags can be grouped into four main categories. In this section we describe the importance and use of each.

Directives

The JSP Directives are elements that give the J2EE Application Server global information on the JSP file. The syntax of the JSP Directive is:

    <%@ directive attribute=" value" %>

The attribute and value pair are optional. Table 4-1 identifies some of the directives.

Table 4-1: JSP Directives
Directive	Description	Available attributes
page	Defines information that affects the global definition of the JSP file. The attributes are not required since they are set by default.	autoFlush buffer contentType errorPage extends info import isErrorPage isThreadSafe language session
include	This directive let's the developer include files in the JSP at compile time.	file
taglib	Lets the JSP include custom tag libraries on the JSP.	uri prefix

We used the taglib directive in our JSP examples to include the custom Domino JSP tags.

For further information on the JSP directives and attributes refer to the references at the end of this chapter.

Declarations

Declarations are used when a JSP developer wants to include methods or define variables on the Servlet class generated by the J2EE Web Container.

Example 4-2 is a sample of a String variable declaration inside a JSP file.

Example 4-2: Sample variable declaration inside a JSP file

 <html> <body> <%! String myString=new String("My String");%> </body> </html>

Example 4-3 shows the declaration of a method inside a JSP file.

Example 4-3: Sample method declaration inside a JSP file

 <html> <body> <%! public getMyString() { return myString;)%> </body> </html>

Expressions

Expressions are used to display dynamic Java content on the Web browser. These are some of the most commonly used elements in JSP files. The expression tags are replaced by the evaluation of the Java code; this evaluation is performed at runtime.

The syntax of an expression is:

    <%= expression%>

The expression evaluated must successfully return a String class or a class that can be casted into a String.

Example 4-4 is a sample of a JSP expression.

Example 4-4: Sample JSP expression

 <html> <body> <%=this.getMyString()%> </body> </html>

Scriptlets

Scriptlets are general purpose Java tags within which a developer can embed normal Java code.

The syntax of the scriptlets is:

    <% javaCode %>

Example 4-5 is an example of a JSP Scriptlet.

Example 4-5: Sample JSP scriptlet

 <html> <body> <% out.println("Hello World !!"); %> </body> </html>

Implicit objects in JSP files

Working with JSP files, you will be able to reference-without declaring-several Java objects. These objects have exactly the same characteristics as if they where being called from a Servlet component. Table 4-2 outlines the most important objects.

Table 4-2: Some important implicit objects in JSP files
Object name	Description
session	This object represents the javax.servlet.http.HttpSession object and is most commonly used to store data that's related to the user, through the user interaction with the application. One of the most important uses of this object is to replace the stateless nature of HTTP by providing a temporary stateful storage of the information the user generates though his interaction with the Web application.
request	This object represents the javax.servlet.http.HttpServletRequest interface and is primarily used to allow the user to access the request parameters through the getParameter(String) method. Also this object is used frequently to pass attributes from one request to the target JSP file. It also exposes through different methods the requesting user and device information that is trying to access the JSP file.
response	This object represents the javax.servlet.http.HttpServletResponse and is responsible for passing information back to the requesting client. It is commonly used to write information to the output stream, although the out object takes care of that.
out	This object represents a JspWriter which is derived from the java.io.Writer and provides the client the ability to stream information back to the requesting client. One of the most common methods used by this object is the out.println(String) method, which prints the String parameter directly on the output generated by the JSP file.

For further information on JSP implicit objects, check the references at the end of this chapter.

Providing a stateful interaction through a stateless protocol

The nature of the HTTP protocol is stateless, meaning it basically accepts a request through a TCP/IP port and responds with a bytestream of characters that are rendered on the Web browser. To compensate for this shortcoming, the J2EE technology includes objects that can be used by our JSPs which are implicit on their use and solve the stateless characteristics of the HTTP protocol. In the previous section we discussed an implicit object called session. This object represents the javax.servlet.HttpSession class; its purpose is to maintain a temporary storage area that can be used by our applications to keep the context of who is interacting with our application and with what characteristics this interaction is taking place.

As shown in Figure 4-4 on page 149, there are two techniques used to enable this interaction. The first is to maintain a Session ID on a cookie inside the browser. This cookie contains the ID code that the Web container can use to look up the session data in which the current user is working. The second approach is rewriting the URL, which appends the Session ID to the URL to maintain the session-browser relationship. This approach is not supported by our portal infrastructure since we could have a session for each portlet.

click to expand
Figure 4-4: Stateful interactions using Java components

The use of the session object inside our JSPs will enable us to maintain portlet-specific information through the user interaction with the portal. To illustrate this, imagine you have a portlet that extracts user information, but then you change to another WebSphere Portal place or page to interact with other portlets. When you come back to the original portlet it would be useful to still get the same information as you had before. This can be accomplished using the session object.

JSP limitations

The JSP technology has one main limitation that should be taken into account: the size of the Java bytestream is limited to 64k.

< Day Day Up >