In part 1 of this article, we discussed Microsoft's .NET Framework. This month, we examine WebSphere's multi-product architecture with focus on the WebSphere Studio Application Developer (WSAD) for Windows, the Integrated Development Environment (IDE) that replaces IBM's Visual Age for Java. WSAD, a collection of development tools based on the Eclipse technology, provides an environment designed to enhance Web services development and build J2EE Enterprise applications. The overall WebSphere Application Server (WAS/WSAD) architecture is component-based and layered in multi-tiers. The Eclipse technology, a plug-in based approach, is integrated with WAS to allow users and third parties to extend the base IDE with their own plug-in technologies.

When you start WSAD, the opening view consists of several panes that represent the various components contained within your workspace, i.e., editors, properties, and perspectives. Editors facilitate the creation and modification of resources. Views present a way to navigate through resources. For example, you can rename files or folders from the navigator view. Modifications made in views are reflected immediately, whereas changes to your work do not show up in the navigator view. The properties view displays file properties such as the date the file was last accessed or modified. Perspective views present a series of editors and views organized for executing a specific task.

Each perspective contains its own unique view, displaying tools and editors appropriate for a particular view. For example, if you select the Web perspective, it provides quick access to the Web deployment descriptor and displays the specified hierarchy of folders that have been conformed to J2EE, such as the resources folder, the Web content folder, the images folder, the META-INF and WEB-INF folders, etc. To be more specific, the Java browsing perspective displays projects, packages, types, and members. It goes without saying that the debug perspective provides a server's view and displays its status, variables, breakpoints, expressions, and registers. It also provides a console view with a tasks tab. It is worth taking the time to explore the perspectives and options available to developers. The IDE is a full-service, one-stop environment for carrying out any task necessary to create an enterprise application. In many ways, it is similar to Microsoft's Visual Studio.NET, where a developer is presented with multiple choices for developing Web services or enterprise applications.

Before continuing the discussion on WSAD's infrastructure, let's look back to the mid 1990s and examine the early client/server paradigm. Originally, it was intended to increase productivity. Unfortunately, it failed primarily because business processes were designed to solve technological shortcomings rather than update a system to keep up with technological advances. Unknowingly, developers addressed the wrong issues. Mixing business logic and its implementation with presentation technology was the primary source of the problem.

The decision as to where to place data functionality and transactional processing was a major issue. Most efforts were focused on positioning business solutions on the back end with the user. Developing "thick client" applications was both costly and difficult to scale and distribute. Fortunately, today's Web-based technologies have resolved many previous issues.

The Web-Based Client/Server Design Paradigm
The present Web-based client/server architecture is component-based with large collections of abstract interfaces that promote component reuse. They represent several vertical slices of the actual business process comprising the following items.

• Remote object presentation uses either server-side scripting or Java servlets. The client makes requests via a Web browser and HTTP. The Java servlet is called to sit in memory and interpret incoming client messages. The servlet then dispatches the request to the appropriate JavaBean or Enterprise JavaBean (EJB) for processing. Finally, the servlet delegates a JavaServer Page (JSP) to return the result to the client's browser in HTML format. This represents a "thin client" solution.
• Remote object access and data management utilizes RMI-IIOP, JNDI, and/or RPC server-side calls, whereas the client uses either a Java applet or a Web application to achieve its task.
• Distributed data management places business logic/data on both the client and on the server.

By viewing these components from both a server and client perspective, we can understand how the components play an integral role in forming a multi-tiered architecture. Clearly, the business process has shifted from client-side processing to the server side. Only presentation functionality remains with the client.

WSAD conforms to the J2EE specifications for constructing a system architecture. The specifications define interfaces, their respective life cycles, and interaction with the various components' functionalities. Most importantly, the specifications introduce the concept of containers. The containers are designed to host J2EE components within a layered boundary. The containers serve as component managers by defining component relationships and their interdependencies within a specific tier. The following example demonstrates how the application containers can be partitioned (see Figure 1).

The individual components residing within each container interact with other container components based on business model requirements. This graphic introduces the Model/View/Controller (MVC) design pattern we shall examine shortly.

WSAD provides a built-in WebSphere Test Environment (WTE), which is a servlet and test development environment built into WAS. Three types of servlet engines exist.

• Standalone servlet engines: These contain the usual HTTP server functionality and provide support for servlets.
• Add-on servlet engines: These types of engines function as plug-ins to an existing Web server. WSAD provides a plug-in that installs into an HTTP server. By doing so, the HTTP server will determine which URLs refer to applications deployed in WebSphere and forward the servlet requests to a standalone application server (WAS) via HTTP.
• Embeddable servlet engines: These engines are servlet deployment platforms that can be embedded in other applications. Subsequently, the applications become the servers. IBM's WebSphere Test Environment is such a servlet engine.

Explaining the MVC Design Paradigm
WebSphere has adopted the MVC design pattern created by Xerox PARC for Smalltalk-80 in the 1980s. This model is becoming increasingly popular with the programming community. Significantly, MVC was selected by Sun Microsystems as the recommended model for its J2EE specifications. MVC can be used by any programming language or platform and enforces the separation between (1) the view, (2) the model, and (3) the controller. It separates data input and processing from data output.

The view interface presents users with a wide range of options such as making a selection from a series of radio buttons or a drop-down list. For example, he/she can select the type of delivery service, i.e., UPS, FedEx, USPS, or DHL from a list. Traditionally, the view is presented in HTML format. However, an interface may be also presented as XHTML or XML/XSLT templates. Because the view is display-neutral, it can present many diverse views of the same data. A view always reflects any event changes occurring in the "model" layer.

The model contains business objects that interact directly with JavaBeans or EJBs. They implement transactional business rules such as data persistence or retrieval from a relational database.

The controller serves as interpreter by intercepting client requests and calling a servlet's service() function to fulfill the client's request. The controller applies no formatting nor does it output anything. It serves only as a notification service both to the view and model to respond accordingly.

Applying the Mediator Design Pattern
The WebSphere architects have taken the MVC concept one step further by applying the mediator design pattern introduced in Design Patterns by Erich Gamma. The mediator/controller pattern places another layer of indirection between the view and the model/domain. A mediator/controller captures and decouples application-specific functionality from presentation technology by implementing behavior that would usually exist as methods in presentation classes. The mediator can be better understood by viewing it as an abstract interface that must be implemented by providing a concrete mediator object. When a client submits a request, the mediator intercepts the request and delegates the task to a concrete class of objects to fulfill mediator/controller-directed tasks. The mediator is responsible for controlling and coordinating the interactions of groups of objects. As Gamma explains, "the mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the mediator, thereby reducing the number of interconnections." Doing so places behavior in one class, thus allowing the behavior to be modified or replaced locally. Abstract interface substitutability is the key to object reuse.

There is more than one approach to designing an MVC-based enterprise application. Let's assume that we have an application designed especially for registering and managing new students in an academic environment. The first step is identifying the model classes; in our case we have only one model class, namely, student. The attributes for the student are his/her ID, name, age, address, and academic class. The next step is determining the views in our application. We assume they are JSP pages. Any dynamic changes in a page will be presented in a JSP page. We now have three JSP pages:

• PeruseStudents
• NewStudents
• StudentDetails

The next step is looking for transitions between pages. They occur as a result of selecting a button to make the transition. The button selected is either an HTML button that submits a form or executes a GET or URL link between the JSP pages. In a normal context, each button has its own controller. If the content is dynamic, the controller must implement the transition to a specific page. In other words, the controller must act as a filter for each individual set of data. For example, examining the logic for page transitions suggests the link from PeruseStudents to NewStudents does not alter the way the NewStudents page is presented. Therefore, we can identify the controllers for each unique transition:

• PeruseStudentList
• DisplayDetails
• CreateNewStudent
• UpdateStudent
• DeleteStudent

Now we have two approaches: (1) use a controller to implement each servlet, or (2) employ a single controller to handle all servlet requests and pass the processing to an ancillary class. This solution is called a gateway servlet. With this method, a unique controller is identified for each individual request. This is accomplished by employing a polymorphic controller along with an object factory to create new object instances. The benefit obtained from applying this type of approach is obvious - the ability to add new functionality to your application without requiring reconfiguration of the application server. This results in either the implementation of a simple interface or extending an abstract controller class. The Struts Framework we introduce next is built on this model.

WSAD Provides Support for the Struts Framework
Jakarta's Struts Framework was created by Craig McClanahan and donated to the Apache Software Foundation in 2000. The framework is made up of approximately 300 classes divided into core packages. The top level packages consist of the following components.

• Action: Contains controller classes ActionForm, ActionMessages, and several other framework components
• Actions: Contains the action classes such as DispatchAction, which can be used to extend your application
• Config: Includes the configuration classes that are in-memory representations of the struts configuration file
• Taglib: Contains the tag handler classes for the struts tag libraries
• Tiles: Contains classes used by the tiles framework
• Upload: Includes classes used for uploading and downloading files from the file system using a browser
• Util: Contains general-purpose utility classes employed by the framework
• Validator: Contains the struts-specific extension classes used by struts when deploying the validator

In short, the Struts Framework is based on the Java servlet technology. Additionally, the framework utilizes a servlet to process incoming requests. However, it relies on other components that are part of the controller domain. The Struts Framework is considered a Model II MVC architectural model, meaning it uses servlets as the mediator/controller layer, and delegates JSP pages to function as the presentation layer. The servlet is the recipient of HTTP post requests and passes the posted data to the model domain for processing. Furthermore, it selects a specified JSP to return and display the results. Struts definitely makes it easier for developers to build Web applications. And this explains precisely why WSAD supports this framework.

The Struts Framework solves problems developers usually face when using servlets as the mediator. Passing HTTP parameters to JavaBeans is cumbersome because this process requires invoking a JSP to manage the HTTP request. This violates the Model II MVC architecture. Listed below are some of the challenges developers encounter.

• Servlets/JSPs: These provide no mechanism for page or form validation. The developer must implement his/her own validation procedures manually.
• Hard-Coded JSP URIs: Modification or re-organization of JSPs in a Web site is difficult without updating Java code in the servlets.

The Struts Framework resolves these issues. Unfortunately, we cannot examine the entire framework here. Therefore, we recommend that you locate the source code by entering the following URL in your browser: jakarta.apache.org/struts.

WSAD includes a test environment for testing servlets and JSPs. WSAD also provides Web interfaces using XML/XSL technology.

We have not discussed WSAD's support for building enterprise applications with EJBs. This topic will be reserved for a future article. However, we have discussed the presentation and model layers in considerable detail. Additionally, we have considered the MVC design paradigm, its impact on program design, and how it is implemented in WSAD.

The next article in this series will contain a direct comparison of .NET's ASP.NET technology with Java servlets and JavaServer Pages. Several coded examples will provide a comparison of how both .NET and WSAD implement the MVC architecture. Until then, happy computing.

Resources

Kyle Brown et al. (2003). Enterprise Java Programming with IBM WebSphere. Addison-Wesley.

Nillson, Dale R. and Mauget, Louis E. (2003). Building J2EE Applications with IBM WebSphere. John Wiley &Sons, Inc.

Cavaness, Chuck. (2002). Programming Jakarta Struts. O'Reilly Media, Inc.

Peltzer, Dwight. (2004). Interoperability Between .NET & J2EE. McGraw-Hill Osborne Media.

Hunter, Jason and Crawford, William. (1998). Java Servlet Programming. O'Reilly Media, Inc.

• Figure 1