What Is Presentation Tier Interoperability?

I'm asked this question a lot (usually after discussing the scenarios and boundaries presented in Chapter 2). Many of the chapters in this book have concentrated on interoperability with components that reside at the business tier. For example, in Part II, "Interoperability Technologies: Point to Point," you saw a number of components hosted by using a J2EE application server that were invoked from an ASP.NET page or a command-line client. You also saw this demonstrated the other way, with .NET components invoked from a JSP tier or Java client.

In most applications, the presentation tier is responsible for rendering and delivering content to the client. This content might be a number of HTML pages, images, and static controls. Some of the pages might also contain scripts (ASP.NET code-behind for .NET, and JSP for the Java platform). In general though, little "business processing" is done at the presentation tier. For example, heavy calculations and transactions are normally performed at tiers behind the presentation tier. This makes the concept of interoperability at the presentation tier more difficult to conceptualize and understand. Static pages ”and even pages with script embedded ”usually don't have the need or power to call other pages on a remote system. So why would we want to do this?

Requirements for Interoperating at the Presentation Tier

To start exploring the requirements for interoperability at the presentation tier and the benefits of doing so, let's revisit Chapter 2, where we covered the three common business requirements for interoperability. The first requirement involved replacing or extending an existing presentation tier. To illustrate this, the representation shown in Figure 12.1 was used.

Figure 12.1: Replacing the J2EE presentation tier with ASP.NET.

As discussed in Chapter 2, this scenario shows how ASP.NET can be used to create a new presentation tier for an existing J2EE application. This model, combined with the requirement to provide interoperability between the presentation and business tiers, is perfectly valid, but it does assume that the entire presentation tier is hosted on one platform.

What about a scenario in which part of the presentation is based on a new ASP.NET implementation, yet part of the presentation still resides on the existing JSP and Servlet tier (or vice versa)? In this case, you might have an application flow that looks like Figure 12.2.

Figure 12.2: A presentation tier consisting of JSP, Servlets, and ASP.NET pages.

Here, a number of pages and/or controls are still served to the user via the existing technology (JSP and Servlets), whereas part of the application has been migrated to the new presentation tier (ASP.NET). To investigate this further, let's consider a fictitious but valid business requirement.

Woodgrove Bank is a large investment bank located on Wall Street. Free from corporate scandal, Woodgrove Bank operates a network of highly integrated applications and services for its trading floor. A lot of the bank's success with its existing system is based upon the introduction of a unified, Web-based portal. This particular portal delivers a user experience with separate Web components, many of which interact with each other and/or back-end systems. The layout for the bank's portal is shown in Figure 12.3.

Figure 12.3: Layout of a Web portal consisting of many integrated parts .

The components within the portal (which are also known as Web parts ) allow an investment banker to perform functions relative to his daily needs. For example, one Web part might show a summary of a particular banker's current trading portfolio. Another Web part might show the breakdown of a company that the banker is interested in, and another might show online news feeds about that particular company. This multiple “Web part interface isn't unique to the bank. Many of the more complex intranet and Internet sites in use today typically are built around a framework that consist of a number of integrated Web parts. To make the portal functional, each of the Web parts is integrated with the others to provide both a unified view of the application and a manageable way for the information services department to maintain the application. Each Web part can in theory be hosted and developed upon independently.

For this example, let's also suppose that the system has been in place for some time (and therefore is well proven) and is based upon a number of JSP and Servlets. For the upcoming financial year, the CTO has made a strategic decision to undertake and deploy a pilot application using .NET. Using ASP.NET, the CTO wants to create a new look and feel for the portal ”displaying additional information and Web parts to create a more compelling user experience. During initial discussions about a new version of the portal based on ASP.NET, the CTO suggested a fundamental requirement to reuse existing Web parts that currently reside in the JSP/Servlet version of the application. A significant amount of development effort and time has already been invested in these JSP pages and Servlets, and the new .NET pilot application needs to seamlessly run side by side with this existing application to be accepted into production.

The integration required by this scenario might include the sharing of stock data, portfolios, and other trading recommendations among Web parts on these two different platforms. The ability of this new .NET application to know the state of and interact with the other components hosted by J2EE defines presentation-tier interoperability.

Challenges of Interoperating at the Presentation Tier

To continue with our example, let's assume that the investment bank's development team takes on the project with much enthusiasm . This is a great opportunity for the bank to embrace .NET, but to be accepted, .NET must be implemented in a way that's not considered a "rip and replace" of the existing system in production.

After reviewing the design of the new .NET application and based on using existing JSP Web parts in ASP.NET, the development team identifies two potential challenges for the new project:

ASP.NET doesn't have access to session state used by the existing JSP and Servlets, and vice versa.
No common authentication mechanism exists between ASP.NET and JSP.

Let's examine the first challenge for a moment: In the existing implementation, many of the Web parts within the portal rely on a technology known as session state to pass session-based data to and from other parts of the Web application. For example, when a user performs an action on one part of a Web page within the portal, the component may write a value into the session to indicate to other parts of the application that they should update themselves accordingly . A real-life example of this is a shopping cart for an online store. In many implementations , shopping cart data is created and maintained as online buyers select goods to purchase. This data is stored as one or more objects in the session.

Let's return to the investment bank scenario. A second example of the use of session data occurs when one of the components of a Web page within the portal asks the investment banker to select a company to display information for. This selection (and any other related information) can be saved to a session by one of the components of the Web page. When the page is refreshed, the other Web components within the portal will read the data stored within the session and alter their appearance accordingly.

Note

How does a session work for each platform? Both ASP.NET and version 2.0 of the Servlet API provide session functionality. A session gives users the ability to store and retrieve data for a particular Web session. This is achieved by associating every user of the application with a System.Web.SessionState.HttpSessionState object (for ASP.NET) and a javax.servlet.http.HttpSession object (for JSP). In most cases, the instance of the user's browser is tied with the session object by using a cookie. When the user first reaches a page on a Web server that supports sessions, a new Session ID is created. This Session ID is encrypted in some cases and is sent back to the user in the form of a cookie. When the user next browses to a page on the same Web site, the cookie is passed as part of the request and the session object for that user can be reactivated and accessed.

Using sessions involves taking some data that will be stored, serializing that data, and saving the value with the client's session for later use. Both the .NET and J2EE platforms store sessions by using different methods . In the Microsoft .NET Framework, the session object within ASP.NET serializes the object by using a proprietary serializer. This greatly increases the throughput for multiple accesses to the session object, but at the same time, it doesn't lend itself well to extending and working with the objects that have been stored. Sessions on the J2EE platform tend to depend on the vendor of the Servlet engine and/or application server. One vendor's implementation of the J2EE platform might store the session object differently from another vendor's platform. Writing an implementation for each vendor would be time-consuming . In addition, the .NET and J2EE implementations of session state don't lend themselves well to being accessed by other APIs ”apart from the Web page making the call. If the session can't be accessed, components on one platform can't read and write session data on the other.

For the investment bank, the second challenge is that the existing application based on JSP requires the user to log in before she can access the data. This login process is done by using a user table in a database and then writing a cookie to the browser, thereby giving the user access for that session. Looking for an equivalent authentication mechanism in .NET, the IT group examines Forms Authentication , an authentication technology provided with ASP.NET. The group finds that Forms Authentication works using a process similar to their existing system in JSP, but the lookup, the format of the cookie sent to the browser, and the general operations are different.

In summary, if Web parts from each platform will be displayed in a unified way (via a single page) to the user, authentication can be an issue. Authentication will either have to be abandoned ”clearly, not an option for the bank ”or the user will be required to enter her credentials twice (once for the new .NET portal, and a second time for the collection of existing JSP components to be hosted). This is a classic example of a requirement for a Single Sign-On (SSO) at the presentation tier.

Avoiding a Disjoint User Experience

These fundamental challenges of session and authentication lead to what I refer to as a disjoint user experience . This isn't unique to interoperability between .NET and J2EE ”in fact, it's common in new systems that involve rewrites of the user interface.

The problem with these systems is that the existing (or legacy) user interface has been in place for so long that replacing the entire framework in one step often isn't feasible or desirable. Because of these challenges with sessions and authentication, in many cases a new, second user interface is created. I've seen this scenario play out on a number of occasions where interoperability wasn't possible between two systems. When building a proof-of-concept project, the development team spends additional time creating a new experience that requires the user to work with a second interface in conjunction with the original. Unfortunately for the user, despite the effort that went into the project, this new user interface is disjointed (by being separate) from the original. The result can be that the user ends up rejecting the system (by not using it), and ultimately the project fails.

To help you overcome these challenges when interoperating between .NET and J2EE, this chapter will present sample code addressing shared session state and shared authentication among components and pages that are based on a mix of ASP.NET and JSP. This sample code is intended only to illustrate the concepts covered in this chapter and should be used only in conjunction with this chapter ”these samples aren't production-ready implementations.