6.4 Web application server

Figure 6-2 on page 96 shows the recommended technology model for a Web application server.

Figure 6-2: Web application server technology model

We assume in this book that you are using a Web application server and server-side Java. While there have been many other models for a Web application server, this is the one that is experiencing widespread industry adoption.

Before looking at the technologies and APIs available in the Web application programming environment, first let's have a word about two fundamental operational components on this node, the HTTP server and the application server. For production applications, they should be chosen for their operational characteristics in areas such as robustness, performance, and availability.

We follow the well-known Model-View-Controller (MVC) design structure so often used in user interfaces. For the Web application programming model, the following applies.

The Model represents the data of the application, and the business rules and logic that govern the processing of the data. In a J2EE application, the Model is usually represented to the View and the Controller via a set of JavaBeans components.
The View is a visual representation of the Model. Multiple Views can exist simultaneously for the same model and each View is responsible for making sure that it is presenting the most current data by either subscribing to state change events or by making periodic queries to the Model. With J2EE, the view is generally implemented using JavaServer Pages (JSP).
The Interaction Controller decouples the visual presentation from the underlying business data and logic by handling user interactions and controlling access to the Model. It processes the incoming HTTP requests and invokes the appropriate business or UI logic. Using J2EE, the Controller is often implemented as a servlet.

6.4.1 Java servlets

Servlets are Java-based software components that can respond to HTTP requests with dynamically generated HTML. Servlets are more efficient than CGI for Web request processing, since they do not create a new process for each request.

Servlets run within a Web container as defined by the J2EE Model and therefore have access to the rich set of Java-based APIs and services. In this model, the HTTP request is invoked by a client such as a Web browser using the servlet URL. Parameters associated with the request are passed into the servlet via the HttpServletRequest, which maintains the data in the form of name /value pairs. Servlets maintain state across multiple requests by accessing the current HttpSession object, which is unique per client and remains available throughout the life of the client session.

Acting as an MVC Controller component, a servlet delegates the requested tasks to beans that coordinate the execution of business logic. The results of the tasks are then forwarded to a View component, such as a JSP to produce formatted output.

One of the attractions of using servlets is that the API is a very accessible one for a Java programmer to master. The specification of the J2EE 1.3 platform requires Servlet API 2.3 for support of packaging and installation of Web applications.

Servlets are a core technology in the Web application programming model. They are the recommended choice for implementing the Interaction Controller classes that handle HTTP requests received from the Web client.

6.4.2 Java portlet

Portlets are reusable components that provide access to Web-based contents, applications, and other resources. Web pages, Web Services, applications, and syndicated content feeds can be accessed through portlets.

Companies can create their own portlets or select portlets from a catalog of third-party portlets. Portlets are intended to be assembled into a larger portal page, with multiple instances of the same portlet displaying different data for each user.

From a user's perspective, a portlet is a window on a portal site that provides a specific service or information, for example, a calendar or news feed. From an application development perspective, portlets are pluggable modules that are designed to run inside a portlet container of a portal server.

From the development perspective, the portlets are components coded against the portlet API. The portlet components are part of the portal application. The portal application is deployed on the portal server.

For more information about portlets and portlets programming, you can refer to IBM Redbook entitled A Portal composite pattern Using WebSphere Portal V4.1 , SG24-6869.

6.4.3 JavaServer Pages (JSPs)

JSPs were designed to simplify the process of creating Web pages by separating the Web presentation from Web content. In the page construction logic of a Web application, the response sent to the client is often a combination of template data and dynamically generated data. In this situation, it is much easier to work with JSPs than to do everything with servlets. The JSP acts as the View component in the MVC model.

The chief advantage JSPs have over standard Java servlets is that they are closer to the presentation medium. A JavaServer Page is developed as an HTML page. Once compiled, it runs as a servlet. JSPs can contain all the HTML tags that Web authors are familiar with. A JSP may contain fragments of Java code that encapsulate the logic that generates the content for the page. These code fragments may call out to beans to access reusable components and enterprise data.

JSP technology uses XML-like tags and scriptlets written in Java programming language to encapsulate the conditional logic that generates dynamic content for an HTML page. In the runtime environment, JSPs are compiled into servlets before being executed on the Web application. Output is not limited to HTML but also includes WML, XML, cHTML, DHTML, and VoiceXML. The JSP API for J2EE 1.3 is JSP 1.2.

JSPs are the recommended choice for implementing the View that is sent back to the Web client. For those cases where the code required on the page is to be a large percentage of the page, and the HTML minimal, writing a Java servlet will make the Java code much easier to read and therefore maintain.

6.4.4 JavaBeans

JavaBeans are an architecture developed by Sun Microsystems, Inc. describing an API and a set of conventions for reusable, Java-based components. Code written to Sun's JavaBeans architecture is called JavaBeans or just beans. One of the design criteria for the JavaBeans API was support for builder tools that can compose solutions that incorporate beans. Beans may be visual or non-visual.

Beans are recommended for use in conjunction with servlets and JSPs in the following ways:

As the client interface to the Model layer. An Interaction Controller servlet will use this bean interface.
As the client interface to other resources. In some cases this may be generated for you by a tool.
As a component that incorporates a number of property-value pairs for use by other components or classes. For example, the JavaServer Pages specification includes a set of tags for accessing JavaBeans properties.

6.4.5 XML

XML (Extensible Markup Language) and XSL stylesheets can be used on the server side to encode content streams and parse them for different clients , thus enabling you to develop applications for a range of PC browsers and for the emerging pervasive devices. The content is in XML and an XML parser is used to transform it to output streams based on XSL stylesheets that use CSS.

This general capability is known as transcoding and is not limited to XML-based technology. The appropriate design decision here is how much control over the content transforms you need in your application. You will want to consider when it is appropriate to use this dynamic content generation and when there are advantages to having servlets or JSPs specific to certain device types.

XML is also used as a means to specify the content of messages between servers, whether the two servers are within an enterprise or represent a business-to-business connection. The critical factor here is the agreement between parties on the message schema, which is specified as an XML DTD or Schema. An XML parser is used to extract specific content from the message stream. Your design will need to consider whether to use an event-based approach, for which the SAX API is appropriate, or to navigate the tree structure of the document using the DOM API.

IBM's XML4J XML parser was made available through the Apache open source organization under the Xerces name. For open source XML frameworks, see:

http://xml.apache.org/

Defining XML documents

XML documents are defined using DTDs or XML Schemas.

DTDs are a basic XML definition language, inherited from the SGML specification. The DTD specifies what markup tags can be used in the document along with their structure.

DTDs have two major problems:

Poor data typing: in DTDs, elements can only be specified as EMPTY, ANY, element content, or mixed element-and-text content, and there is no standard way to specify null values for elements.

Date formats, numbers , or other common data types cannot be specified in the DTD, so an XML document may comply with the DTD but still have data type errors that can only be detected by the application.
Not defined in XML: DTD uses its own language to define XML syntax, and it is not compliant with the XML specification. This makes it difficult to manipulate a DTD.

To solve these problems, the World Wide Web Consortium (W3C) defined a new standard to define XML documents called XML Schema. XML Schema provides the following advantages over DTDs:

Strong typing for elements and attributes
Standardized way to represent null values for elements
Key mechanism that is directly analogous to relational database foreign keys
Defined as XML documents, making them programmatically accessible

Even though the XML Schema is a more powerful technology to define XML documents, it is also a lot harder to work with, so DTDs are still widely used to define XML documents. Additionally, simple, not hard-typified documents can be easily defined using DTDs with similar results to using XML Schema.

Whether to use one or the other will depend on the complexity of the messages and the validation requirements of the application. Actually, in many cases, both (a DTD and a XML Schema) are provided, so they can be used by the application depending on its requirements.

Note	We have to remember that the validation process of an XML document using XML Schemas is an expensive process . Validation should be performed only when it is necessary.

XSLT

Extensible Stylesheet Language Transformations (XSLT) is a W3C specification for transforming XML documents into other XML documents. The XSLT is built on top of the Extensible Stylesheet Language (XSL) which, like CSS2 seen in 6.1.4, "CSS" on page 79, is a stylesheet language for XML. Unlike CSS2, XSL is also a transformation language.

A transformation expressed in the XSLT language defines a set of rules for transforming a source tree to a result tree; it is expressed in the form of a stylesheet.

An XSLT processor is used for transforming a source document to a result document. There are currently a number of XSLT processors available on the market. DataPower has introduced an XSL just-in-time (JIT) compiler, which speeds up the time taken for the XSL transformation.

The XSLT processor has a performance overhead, so online processing of larger documents can be slow.

XML security

XML security is an important issue, particularly where XML is being used by organizations to interchange data across the Internet. Several new XML security specifications are working their way through three standards bodies - the W3C (World Wide Web Consortium), IETF (Internet Engineering Task Force), and OASIS (Organization for the Advancement of Structured Information Standards). We highlight a few of them here:

XML Signature Syntax and Processing is a specification for digitally signing electronic documents using XML syntax. According to the W3C, " XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere ."

A key feature of the protocol is the ability to sign parts of an XML document rather than the document in its entirety. This is necessary because an XML document might contain elements that will change as the document is passed along or various elements that will be signed by different parties.

WebSphere Studio provides you with the ability to create (using a wizard) and verify XML digital signatures.
XML encryption will allow encryption of digital content, such as Graphical Interchange Format (GIF) images or XML fragments. XML encryption allows the parts of an XML document to be encrypted while leaving other parts open, the encryption of the XML itself, or the super-encryption of data (that is, encrypting an XML document when some elements have already been encrypted).
XKMS (XML Key Management Specification) establishes a standard for XML-based applications to use Public Key Infrastructure (PKI) when handling digitally signed or encrypted XML documents. An XML signature addresses message and user integrity, but not issues of trust that key cryptography deals with.
SAML (Security Assertion Markup Language) is the first industry standard for secure e-commerce transactions using XML. It aims to standardize the exchange of user identities and authorizations by defining how this information is to be presented in XML documents, regardless of the underlying security systems in place.

For further discussion, see the Sun ONE article Riddle Me This: Is Your XML Data Safe? by Brett Mendel, which can be found at:

http://dcb.sun.com/practices/websecurity/overviews/xmldata.jsp

Advantages of XML

There are many advantages to XML in a broad range of areas. Some of the factors that influenced the wide acceptance of XML are as follows :

Acceptability of use for data transfer

XML is a standard way of putting information in a format that can be processed and exchanged across different hardware devices, operating systems, software applications and the Web.
Uniformity and conformity

XML gives you an common format that could be developed upon and is accepted industry-wide.
Simplicity and openness

Information coded in XML is human readable.
Separation of data and display

The representation of the data is separated from the presentation and formatting of the data for display in a browser or other device.
Industry acceptance

XML has been accepted widely by the information technology and computing industry. Numerous tools and utilities are available, along with new products for parsing and transforming XML data to other data, or for display.

Disadvantages of XML

Some XML issues to consider are as follows:

Complexity

While XML tags can allow software to recognize meaningful content within documents, this is only useful to the extent that the software reading the document knows what the tagged content means in human terms, and knows what to do with it.
Standardization

When multiple applications use XML to communicate with each other, they need to agree on the tag names they are using. While industry-specific standard tag definitions often do exist, you can still declare your own non-standard tags.
Large size

XML documents tend to be larger in size than other forms of data representation.

6.4.6 Enterprise JavaBeans

"Enterprise JavaBeans" is Sun's trademarked term for its EJB architecture (or "component model"). When writing to the EJB specification, you are developing "enterprise beans" (or, if you prefer, "EJBs").

Enterprise beans are distinguished from JavaBeans in that they are designed to be installed on a server, and accessed remotely by a client. The EJB framework provides a standard for server-side components with transactional characteristics.

The EJB framework specifies clearly the responsibilities of the EJB developer and the EJB container provider. The intent is that the "plumbing" required to implement transactions or database access can be implemented by the EJB container. The EJB developer specifies the required transactional and security characteristics of an EJB in a deployment descriptor (this is sometimes referred to as declarative programming ). In a separate step, the EJB is then deployed to the EJB container provided by the application server vendor of your choice.

There are three types of Enterprise JavaBeans:

Session beans
Entity beans
Message-driven beans

A typical session bean has the following characteristics:

Executes on behalf of a single client.
Can be transactional.
Can update data in an underlying database.
Is relatively short lived.
Is destroyed when the EJB server is stopped . The client has to establish a new session bean to continue computation.
Does not represent persistent data that should be stored in a database.
Provides a scalable runtime environment to execute a large number of session beans concurrently.

A typical entity bean has the following characteristics:

Represents data in a database.
Can be transactional.
Has shared access by multiple users.
Can be long lived (lives as long as the data in the database).
Survives restarts of the EJB server. A restart is transparent to the client.
Provides a scalable runtime environment for a large number of concurrently active entity objects.

A typical Message-Driven Bean has the following characteristics:

Consumes messages sent to a specific queue.
Is asynchronously invoked.
Is stateless.
Can be transaction aware.
May update shared data in an underlying client message.
Executes upon receipt of a single client message.
Has no component or home interface.
Is removed when the EJB container crashes. The container has to re-establish a new message-driven object to continue computation.

Typically, an entity bean is used for information that has to survive system restarts. In session beans, on the other hand, the data is transient and does not survive when the client's browser is closed. For example, a shopping cart containing information that may be discarded uses a session bean, and an invoice issued after the purchase of the items is an entity bean.

An important design choice when implementing entity beans is whether to use Bean Managed Persistence (BMP), in which case you must code the JDBC logic, or Container Managed Persistence (CMP), where the database access logic is handled by the EJB container.

The business logic of a Web application often accesses data in a database. EJB entity beans are a convenient way to wrap the relational database layer in an object layer, hiding the complexity of database access. Because a single business task may involve accessing several tables in a database, modeling rows in those tables with entity beans makes it easier for your application logic to manipulate the data.

An important change to the specification in EJB 2.0 is the addition of a new enterprise bean type, the message-driven bean (MDB). The message-driven bean is designed specifically to handle incoming JMS messages. The EJB container uses message properties and bean deployment descriptor to select the bean to invoke when a message arrives, so your application logic only needs to process the message contents.

The J2EE 1.3 platform requires support for EJB 2.0. As a tool provider, WebSphere Application Server V5.0 supports J2EE 1.3 and therefore supports EJB 2.0. EJBs are packaged into EJB modules (JAR files) and then combined with Web modules (WAR files) to form an enterprise application (EAR file). EJB deployment requires generating EJB deployment code specific to the target application server.

6.4.7 Additional enterprise Java APIs

The J2EE specification defines a set of related APIs that work together. Here are the remainder not discussed so far:

JNDI: Java Naming and Directory Interface. This package provides a common API to a directory service independent of any directory access protocol. This allows for easy migration to new directory services. Through this interface, component providers can store and retrieve Java object instances by name. Service provider implementations include those for JDBC data sources, LDAP directories, RMI and CORBA object registries. Sample uses of JNDI include:
- Accessing a user profile from an LDAP directory
- Locating and accessing an EJB home
- Locating a driver-specific data source
RMI-IIOP: Remote Method Invocation (RMI) and RMI over IIOP are part of the EJB specification as the access method for clients to access EJB services. From the component provider point of view, these calls are local. The EJB container takes care of calling the remote methods and receiving the response. To use this API, component providers create an IDL description of the EJB interface and then compile it to generate the client-side and server-side stubs. The stubs connect the object implementations with the Object Request Broker (ORB). ORBs communicate with each other through the Internet Inter-ORB Protocol (IIOP). RMI can also be used to implement limited-function Java servers.
JTA: Java Transaction API. This Java API for working with transaction services is based on the XA standard. With the availability of EJB servers, you are less likely to use this API directly.
JAF: JavaBeans Activation Framework. This API is not intended for typical application use, but it is required by the JavaMail API.
JavaMail: This is a set of classes for supporting e-mail. Functionally, it provides APIs for reading, sending, and composing Internet mail. This API models a mail delivery system and requires the SMTP for sending mail and POP3 or IMAP for receiving mail. Special data wrapper classes are provided to view and edit data in the mail content. Support for MIME data is delegated to the JAF-aware beans.
JAXP: API for parsing and transforming XML documents.
JAAS: Java Authentication and Authorization Service.