Composite Applications

The widespread presence of Web Services will enable and encourage a new style of user-oriented application: the composite application.

Navigation Giving Way to Composition

Traditional applications have evolved to become what is sometimes called "navigationally oriented" systems. The basic user interface is to go from screen to screen filling in whatever data is requested of you. Although this is true by necessity in mainframe systems with limited screen real estate and no possibility of local processing, it has become the paradigm of choice for most transactionally oriented Web sites. Often many of the screens will be in different systems. The user may have to set up the customer in one system, take an order in another, check inventory availability in yet another, and arrange the freight in yet a fourth. Figure 13.4 shows a small part of this schematically. Each interaction may have four or five screens. Many of the transitions are directed by the system, but the user has some choices along the way. The net result has been a lot of interest in procedures, training, and work flow. For example, a standard scenario might involve the user going to seven different screens in three different applications to complete one unit of work.

Figure 13.4: Navigationally oriented user interface.

Each of those screens represents either available information, or a transaction that can be processed. Preferably the information behind each function should be abstracted out as we discussed in Chapter 12, but even if all you do is extract the screen information into an XML representation you are ahead of the game. Figure 13.5 suggests what is now possible: Information from several screens, even screens from different systems, can be consolidated.

Figure 13.5: Composite applications consolidating information from several other systems.

The great challenges in this approach are twofold: How can we use the power of our client devices to get the most possible information from this type of architecture, and how we can manage context in this type of application?

Rich Client Interfaces

The thin client interface has been a remarkably successful paradigm for several years, but it is extremely limited. In many ways it is like the old mainframe interfaces, except with better artwork. The thin client interface owes much of its popularity to its ubiquity: Everyone can get at it from anywhere. It also doesn't have the configuration management problems of the "fat client," as client/server became known in the waning years of its existence.

There was some useful functionality in the fat client interfaces, though, if only they could be restored with the ease of distribution of the thin client. This is where "rich client" interfaces come in and how they relate to composite applications.

The goal of rich client interfaces is to allow some user interface interaction to be processed entirely on the client. A simple example is a "show/hide" feature to allow users to collapse some information they are not interested in, in the interest of getting the rest of the information on the screen at the same time for decision making.

Establishing Context

More advanced capabilities include using the actual content to change context and modify behavior. For example, a user may select an item from one panel in one part of the screen. The user may want to drag and drop it to another panel (in this case one that was populated from another system). The rich client allows this, but it's the semantic layer behind it that makes it work.

This behavior, which is very useful, could be hard coded, although this doesn't scale well. So there could be some code (Java applets, or .net-managed applications) that download to enable the interaction.

A more powerful approach would be to tag each of the messages from the legacy systems to a shared semantic representation (similar to what we discussed in Chapter 12). We then have a single set of code that establishes context based on the semantic objects (such that when a patient is dropped onto the scheduling panel, for example, the client would treat that as if it were natively keyed in).

Composite applications are primarily going to be an answer to the "wrap and extend" strategy for legacy systems, although I can also see mixing and matching composite applications built from internal components with those that are being used from third parties on the Web. This brings up the next topic: finding a service.