Architecting Web Services

Textbook Web applications are typically developed with an n-tier architecture. This architecture separates the presentation, business, and data components into distinct tiers, or layers (see Figure 1-1). The presentation layer contains the user interface (UI), built with HyperText Markup Language (HTML), various scripting languages, and/or client-side components. The business layer (also referred to as the business logic or logic layer) consists of server-side components or objects, which contain all the business rules and application-specific algorithms. The data layer contains at least the database and possibly the data access logic.

Figure 1-1: N-tier architecture model

The most common layer shared on any Web application is the presentation layer. Whenever one site links to another, both sites share the presentation experience by routing users from one application to another. This was the first example of integration on the Internet and has become commonplace in terms of technology and availability, as evidenced by the millions of Web sites that exist.

Web sites, fundamentally, are about sharing information with people. This information may be generated statically or dynamically, but either way it is information for people. For several years now, we've been developing various methods for displaying this information. These methods have allowed the truly artistic to build very appealing sites and the rest of us to make sites that are truly annoying if not unusable!

Programmatically, presentation-focused efforts have not increased the value of the information being shared in any way. While HTML presents information in a way that is very readable, it takes the human mind to understand the context of what is being displayed. If someone is looking for information on adobe construction, that person can quickly discern by the content of a page whether it is about clay houses or the company that makes the imaging software named PhotoShop. How would a computer make such a distinction?

While this may seem to be an issue of a different sort, it still identifies a fundamental obstacle to sharing on the Internet. One of the most popular instances of sharing is for business-to-business (B2B) partnerships. In this instance you are exposing certain information you have, not to the public, but to a business partner that needs to see it in a consistent format. This could take the form of a custom Web page on your site, but it probably means sharing information with another computer or computers. This is because your partner will not want, and may not even be able, to manually review and discern your information every time it changes.

In a best-case scenario, we could write a program to request information from the Web server and scrape the returned page in a very manual and unsophisticated manner. To assist the reader, the server could possibly expose a simple, unformatted page to help streamline the string parsing that has to occur. This might be a page of duplicate information though, and you can easily slip into building custom solutions to meet your requirements. You also get into a dangerous area of limitations, since even an extra space might throw off a partner's ability to "read" your information.

In our scenario, the first thing we wanted to know was whether we should continue going to the airport or make plans to spend the night in a hotel. Today, most airlines allow you to look up flights on their Web site and check schedule and gate information. To integrate the information from their site into hypothetical application, we could develop a scheduled program designed to call the appropriate Web pages with the required information. This program would be simulating a HyperText Transfer Protocol (HTTP) browser on the airline's site and parsing the required information from the resulting Web page. Because you are using an interface developed for their Web site, there might be several different calls to the site to get the information you want. For example, the airline might have one page that shows the gate and schedule information, but another page that shows availability. Our decision whether to continue going to the airport depends on both, which means that two different routines are necessary.

If you extend this same process out to the hotels, traffic information, and Starbucks, you will have a lot of routines looking up information. Hopefully none of the sites you are researching change their designs, or you will have to make code modifications to your routines. Otherwise, you might get information on an available flight leaving tomorrow at "b>07" instead of "0748." Of course, this is an undependable process on which to build an application, but some applications do use this approach today (but hopefully not to this extreme!). Either way, this scenario illustrates the limitations of using the presentation layer to share information with complex integration applications.

One alternative approach is for companies to directly link their own applications to those of their partners. This approach has limitations in practice, though, such as the unwillingness of most organizations to send users away from their site. If the airline's application sends a user to the hotel site directly for room availability information, the airline is losing all access and reference to that user. Additionally, any sharing of information happens instantly through the linking itself and has very limited capabilities. The airline might tell the hotel automatically what day the user is looking for availability, but after the user leaves, the airline and hotel have no way of communicating about that user. This solution requires much less logic, but companies are at the mercy of their partners and have relatively little to show for it.

Another option is to share the ownership of the presentation layer in an application. Since both partners are bringing one or more application functions, those partners would need to own that function's presentation, because an application's presentation is inherently tied to the application's logic and data in current Web methodologies. Replicating content is far easier than replicating data and logic, so the one with "the back end process" usually wins.

What if a hotel and airline collaborate to build an application for our traffic scenario? If the airline site hosts our application, it has to host some content from the hotel owner that initiates the hotel's process. From that point, the hotel owns the resulting pages of the application until it actively returns users to the airline's site. Figure 1-2 shows how such an application might flow. The airline's application exposes a link called "Find a Hotel" on its site. Clicking this sends the user directly to the hotel's site to access the room availability application. This results in a total handoff of the user to the hotel site, possibly never to return.

Figure 1-2: Application partnership through presentation links

The physical sharing of the presentation layers by different organizations is very high maintenance, as some content from one partner is located on one server and therefore has one owner. The owner of that system must handle a partner's updates, and thus the partner is at the mercy of the owner and the owner's priorities and timelines. Not many companies like, or even accept, being in that situation.

Yet another approach is to encapsulate a partner's content into your presentation via frames or a client-side script. While this provides more control, you can still potentially lose the viewer. Also, there is no true integration, since the content brought to the collaboration step (the actual linking process) is static HTML ready for viewing. In this instance, the airline may send a frameset definition that references an application from the airline's own site as well as an application from the hotel's site. Figure 1-3 shows a diagram of the integration process in a frameset application. In this implementation, the airline has a link connecting the user to the hotel's site, so the user still physically goes to the hotel's site. The difference is that the airline maintains a presence to the user and has some level of control. However, whatever the hotel does in its frame is unknown to the airline. This could not only affect the functionality of the application, but also the user's view of that functionality.

Figure 1-3: Application partnership through a frameset

• A frameset is a tag in HTML that allows the client to reference separate presentation pages in a single browser window.

Here, the exchange of information between the airline and hotel applications is limited, since the browser actually makes independent requests to each. The airline has no knowledge of whether the client even reached the hotel's application. Also, the options for modifying the presentation by one partner are limited to a defined area without directly impacting the other partner's content, and vice versa. Any modifications that do not fit into this defined box impact either its own presentation or the presentation of the applications around it.

All of these approaches should show you why an application's presentation layer leaves limited options for integration. This never improves because it is the top layer and is presented directly to the user. When you integrate presentation layers, you usually push this integration to the browser, and this always has limited success because you have effectively "released" control of the application from the back end systems. Any sharing of this layer by a group of systems can only be superficial since the browser only makes independent requests of one system at a time, receiving a distinct response.

Another approach to making the Internet more interoperable is needed. We need to evolve from the idea of sharing information on the presentation layer and focus on sharing processes earlier in the application's execution.