Application Services

Business Challenge

The flexible content provisioning application just discussed addresses the issue of offering content-oriented Web sites that deliver comprehensive packages to users. A parallel issue exists with service-oriented Web sites. Such sites offer the user application functions over the Internet. Outsourced payroll, HR, and ERP applications are all good examples. These sites must also deliver a complete package, but of functionality rather than content. Users want all the functions associated with a particular process in one place.

In most cases, it is simply not cost-effective for a single Web site operator to implement every function that users require. Suppose a provider wants to offer applications to mobile sales forces. Such a provider needs everything from enterprise-oriented functions like contact management, contract processing, and sales force compensation to travel-oriented functions like airline reservations , hotel bookings, and map delivery. Moreover, the degree of integration in an application service is a competitive advantage. There will be an arms race between competing providers to offer an ever-greater number of integrated features.

While an application service operator may be able to find providers of lower-level components , integrating them is a challenge. Most such providers don't construct their applications with third-party use in mind. They all use different conventions for the interface and different back-end infrastructure. Enabling each component provider to contribute is a brute force integration project. Only the most critical applications could justify the cost.

XML Benefit

XML and, more particularly, Web Services solve the problem of integrating multiple Internet-based applications. The reason is simple: standardization. All the third-party providers can use the same standards for describing their interfaces and responding to requests . Even more important, the application service operator can use the same standards for its internal applications. In most cases, an operator needs to own the central functionality of the offering, relying on third-party providers for supporting features. While cutting down on the proliferation of third-party interfaces, Web Services can unify both the internal and external components as well. The operator simply has to implement new functionality using Web Services and provide a Web Services proxy to existing applications. Using the same methodology for invoking functions in every component, whether external or internal, greatly simplifies the architecture, reducing both development and maintenance costs.

Architecture

As Figure 8-3 shows, the architecture for application services is relatively simple because of the standardized interfaces. User requests arrive from their browsers via a Web server. The Web server forwards the request to the Web service gateway. Each gateway may actually run on the same machine as a Web server, or each may run on its own cluster of machines to separate the load balancing needs of each. The gateway disassembles the request into subrequests to the contributing Web services, based on rules stored in its repository. When the responses come back, it assembles them for delivery using stylesheets also in its repository. All third-party Web Services use the standard protocol stack. They may have extensive integration infrastructures of their own, but this implementation remains hidden from the application operator. Hopefully, the application operator implemented all of its internal components using the Web Services protocols natively. If not, it's relatively straight forward to build proxies that translate the native protocols into the standard ones.

Figure 8-3. Application Services Architecture

Key Features

The key feature of application services is that they decompose logical user requests into detailed requests of multiple components. This type of application applies the concept of separating interface and implementation at two levels. The user doesn't realize that the responses to his requests come from an implementation including multiple components. Each component further hides its implementation behind its public Web Services interface.

Development Process

The beauty of application services is that the use of a standard protocol stack eliminates much of the development. Implementations of these protocols for use in internal components are readily available. Connecting to external components requires only one integration paradigm for all components rather than one for each component. Therefore, the only significant development task is implementing the framework for disassembling user requests into component requests and reassembling the component responses into a user response. You can accomplish the first by designing a schema that maps the user request to component requests and component responses to user responses. A framework interprets these mappings at run time for disassembly. You could create a framework for the reassembly, but you could also use XSLT.

The development of the internal components is independent of this framework development process. Certainly, if you are beginning development of these components, you should use the Web Services protocols. If you have already developed some of them, you have to write Web Services proxies. A proxy bridges the standard protocols to the proprietary protocol of a particular application. If this proprietary protocol follows typical remote procedure call design, creating this proxy should be straightforward. If it requires extensive transaction and security support, you may well have to create your own SOAP extensions to propagate this additional information.

Schema Source

The schemas for the standard protocols clearly come from standards bodies. The schemas for message payloads exchanged via SOAP come from the component developer and are documented in its WSDL definition. For internal components, you will design these schemas. You must also design the schemas for the mapping rules.

Document Life Cycle

Because this application type relies on the Web Services architecture, its document life cycle follows that of Web Services. Each service provides interface definitions that persist, so other applications can discover the interface and use the application. But the SOAP messages produced by one component and consumed by another are transitory except for logging. The rules and stylesheets, of course, persist. As with a number of the other example applications, the rules are operational data, so you want to consider the use of a native XML store or data server as their persistence mechanism. If you do choose one of these mechanisms, you probably also want to use them for storing the interface definitions and stylesheets.