Section 10.1. Building Web Applications

10.1. Building Web Applications

As previously discussed, Web applications are particularly suited as clients for a Service-Oriented Architecture because they offer a natural means of storing context or state information when making calls to a mainly stateless service architecture. In addition, they offer a rich user interface, and users of Web applications are accustomed to a high degree of interactivity. Although the interaction model in Figure 10-1 remains a possibility for providing check-in functionality using a Web interface, it is likely that an airline will provide the user with a richer set of choices during the booking process.

Figure 10-1. General service interaction for passenger check-in. The check-in service takes tickets as input parameters and creates boarding passes as output parameters, invalidating the relevant coupon of the ticket. Note that all services are basically stateless.

These choices will at least include the selection of seats and meals available on the flight. On the other hand, some of the options that were originally present might not be applicable. For example, checking in online is often only possible if a registered user has purchased the ticket because logging in to the airline's Web site is required in order to perform the check-in operation. On top of that, two people traveling together must check in separately if they purchased their tickets separately.

In a Web application, users will authenticate themselves against the Web tier, usually through a Web page form with username and password or client-side certificates. Users can then be stored within the Web tier of the application. For subsequent calls to services, there are two possible models: principal propagation or trust. Principal propagation is trivial and uses frameworks that are built to support this feature. For example, within the J2EE framework, the same principal object used in the Web tier can directly be used to call other J2EE services such as Enterprise Java Beans. For other service types, such as CORBA or SOAP, the process is not as straightforward. It might include the need for mapping credentials from the Web tier to the service layer in a specific way. As mentioned in Chapter 9, "Infrastructure of the Service Bus," SOAP does not support a standardized means of passing credentials. Because Web sites can operate within a controlled corporate environment, trust between the Web tier and the service layer is a common scenario. All calls to the service layer are then carried out using a common identityor no identity at alland the actual caller principal is just passed as a parameter using call parameters. Of course, this requires that the Web application is not exposed directly to a sensitive network segment.

The interaction diagram in Figure 10-2 illustrates the need to expose the "assign seats" functionality to the outside client. In addition, displaying the available seats to the user for a given plane's seating configuration is also necessary. Although it is tempting to provide this type of layout in an ad-hoc manner within the Web application, perhaps as a number of configuration files, this implementation would soon become unmanageable. Airlines often change their seating configurations and add new planes, and it is important to provide this information to customers. In addition, the seat configuration of the airplane and the listing of available seats can be transferred within a single call, providing a good example of a coarse-grained data structure.

Figure 10-2. Interaction that shows the check-in process for a Web application. The state of the application is maintained in the Web application.

Figure 10-2 shows the full interaction diagram for the Web application invocation. Note that we made use of the results from Chapter 8, "Process Integrity," by pushing state as far up the chain as possible. In fact, all state is stored in the Web application itself. This enables a rich interaction between customer and application without the need for any stateful services. Note that the transaction boundaries of the original example have not changed. There is no need to expose transactions directly to the client.

A reasonable amount of interaction takes place between the client and the Web application directly without any need to involve the service layer. This is the result of a well-defined location for storing conversational state along with an optimistic concurrency model (see Chapter 8). After the available tickets have been retrieved from the TicketService, users may choose any selection of flight coupons for which they want to check in. Any logical checks, such as whether a check-in for the coupon can be performed at the current date, can be easily carried out at the Web tier. This is achievable because one person generally handles a single coupon at a time. Of course, race conditions can still occur, such as if someone tries to check in using the telephone and a Web application simultaneously. The same holds true for seat selection. While making the seating selection, one user might select some seats that are already reserved by another user. However, given the time available for check-in and the total number of passengers on a plane, this is rather unlikely. In the event of an error when assigning seats, the user can be prompted with an updated seat map to perform a reselect.

Although the service calls for reserving seats and invalidating a ticket are technically idempotent, this fact cannot be exposed to the customer. One reason is that you shouldn't expose a recoverable error to the customer in the first place. The other is that although changing the state of a ticket is idempotent, the creation of boarding passes might well not be. In that case, it is usually necessary to prevent the customer from making the same call more than once. In Web applications, this is a common scenario that can happen easily if the customer impatiently hits the reload or submit button repeatedly. If not handled properly, such behavior can at worst stall the application. The solution is to apply a one-time transaction pattern (OTT). This involves storing a transaction ID with associated states such as running, finished, and failed. If a customer reattempts an operation, the system retrieves the state of the one-time transaction ID and forwards the customer to an appropriate page. Figure 10-3 illustrates this behavior.

Figure 10-3. One-time transaction pattern. The Web application manages a number of transaction tokens and serves requests based on the state of the tokens. For example, a token can start precisely one operation. While the token is in the running state, some meaningful information is returned to the client.

As we mentioned before, service calls can be either synchronous or asynchronous and can be long running. The one-time transaction pattern is a suitable technology for handling such an invocation scenario. Here, the invocation returns a status page immediately after dispatching the asynchronous call. The status page checks periodically for available results using the OTT token. This is a common technique for complicated and long-running processes such as purchasing airline tickets.

It is worth mentioning that the creation of a Web application can justify implementing an SOA. In many Web applications, it is necessary to interface with an organization's operational core systems, which can be anything from mainframe systems or relational databases to CORBA or J2EE servers. Thus, the creation of Web applications often involves the integration of multiple types of enterprise systems. Usually, this is achieved by using various vendor-specific APIs to connect to the different systems and exposing some consolidated API to the application. Because this integration effort must be performed one way or another, the implementation of these integrations as services presents relatively small overhead and manifests itself mainly during design time in the way transaction boundaries and principal propagation are addressed in the application. This will at least lead to an internal API that is "service-ready" and that can be exposed as a service using appropriate tools.

Web applications can be created using a number of tools, including Perl, PHP, Python, Java Server Pages (JSP), and Microsoft's ASP.NET. When creating a Web application that is simply a client to existing services, any environment that fosters access to the technology used to implement these services can be a reasonable choice. For example, if your SOA is built using Enterprise Java Beans, then using Java Server Pages and Servlets for the Web application is the natural choice. Likewise, if the SOA is implemented using XML over HTTP, perhaps with SOAP, you can use any platform with support for the latest Web service technologies for the Web application. For effectively employing an OTT pattern, the platform should also facilitate the easy creation of request interceptors. J2EE Servlet filters provide one such mechanism.

Many Web applications involve not only the use of existing services but also the direct integration of existing systems. It is usually a good idea to focus on a common skill set for the creation of such an application. The J2EE platform and Microsoft .NET are suitable to that end, not least because components created on these platforms can easily be turned into Web services.