Section 10.6. Multi-Channel Applications

10.6. Multi-Channel Applications

SOAs are extremely effective at implementing multi-channel applications. Strengths such as building a reusable, functional infrastructure, mastering heterogeneity, and providing easy access to data and business logic are key factors for successful multi-channel projects.

A multi-channel application is characterized by a functional core that can be accessed through different channels by either human users or programs, as shown in Figure 10-15. Each channel typically has its own characteristic variant of the basic business processes and specific access technology. These specifics depend directly on requirements of the channel's users such as sales department, back office, or service center. Due to the different requirements, you will often find significant differences in the channels' business processes. For example, a sales representative will require a different view of customer data from a back office clerk or from a service center agent. The processes also depend on the access technology. As we have already discussed in the previous section, you will probably find that the processes on a mobile device with a low bandwidth connection to the functional core and a small display are different from the processes that can be supported by a Web application.

Figure 10-15. A multi-channel application consists of a functional core that is shared by several channels. Each channel provides a specific view of core functionality, according to the requirements of the channel user and the channel technology.

Typical multi-channel applications can provide channels such as the Internet, various mobile channels such as WAP, B2B, fat clients, call centers, or voice applications. They also provide cross-channel functionality, such as co-browsing or channel switching.

10.6.1. FUNDAMENTAL SOA

A fundamental SOA represents the simplest model of SOA-based multi-channel applications (see Chapter 6, "The Architectural Roadmap"). In many cases, this simplicity makes it the preferred choice of model. In this scenario, you have services neither in the aggregation layer nor in the process layer. Consequently, you can also abandon extra tiers and the appropriate hardware, which can lead to reduced latency and improved application response times.

The authors recommend the usage of this minimal approach where possible. This advice does not apply only to multi-channel applications, either. It is beneficial for every SOA to keep operations as simple as possible. Abandoning complexity should be a permanent effort. Every tier that can be avoided is a valuable contribution to the system's maintainability and performance (see Figure 10-16).

Figure 10-16. The fundamental SOA represents a lean service approach that basically implies the usage of application frontends and basic services. No services in the aggregation layer or process layer are involved.

Although a lean approach is desirable, you might find reasons to apply a more complex approach in practice. Requirements such as co-browsing or channel switching, highly complex processes, heterogeneous backend systems, load balancing, and other reasons can force the usage of façades or process-centric services.

10.6.2. SERVICE FA<ADE

A service façade represents a unified interface to the basic service layer for a specific project and encapsulates the functionality of the underlying services. In the airline example, this is particularly useful in order to handle the heterogeneity of the underlying basic services. The façade encapsulates the different technologies and concepts and provides a convenient view of the functionality (see Figure 10-17).

Figure 10-17. A service façade can encapsulate the complexity of the underlying service infrastructure. In particular, heterogeneous application landscapes can benefit from service façades.

Ironically, façades provide only limited benefits for multi-channel applications. It is true that multi-channel applications suffer worst from the heterogeneity of the application landscape. A unifying layer that encapsulates the heterogeneity of the backend systems should be very helpful at first glance. Unfortunately, the frontend of a multi-channel application is also heterogeneous. Thus, a unified façade for access to the backend can only support a subset of channels directly, or it must provide specific operations for some channels. More often, some channels will require a technically different access to the backend, which will require additional technology gateways or extra efforts in the process layer.

There is a benefit however, because this façade approach decouples the individual project-specific code from general domain code. If nothing else, this creates better maintainability due to decoupled release cycles in the basic layer and the enterprise layer. It can also provide an easier way to manage delivery responsibilities within a project.

Service façades are highly project-specific. Although the idea of one unifying layer might be tempting, it is not realistic. In practice, it's usually better for every project to use its own service façade if it requires one (see Chapter 6).

10.6.3. PROCESS-ENABLED SOA

Choosing whether to introduce a process layer is an important design decision. You should consider a process-centric service if several channels have similar processes and the according process logic can be shared. A process-centric service is also useful if features such as channel switching or co-browsing are required. Last but not least, you can consider process-centric services to handle load-balancing issues (see Chapter 6).

However, keep in mind that the implementation of process-centric services introduces an additional element to the architecture that could increase latency, could make the overall design more complex, and might need additional maintenance. Therefore, you should know the exact benefits before deciding to implement a process-centric service. In our airline example, we introduce the booking process service in order to provide channel switching (see Figure 10-18).

Figure 10-18. The introduction of a process-centric service is a major design decision that requires careful consideration.

Although a process-centric service can cover the generic behavior of the business process booking, the application frontends that represent the different channels must add channel-specific behavior. In general, every channel has certain specifics that differentiate it from other channels. This pattern is typical for multi-channel applications. In fact, it is their nature to provide "similar" processes using different channels. At this point, the process layer is rather thin, only exposing the processing steps that are common to allor mostclients that retain their channel-specific logic.

As soon as you have introduced a process layer, the next potential step is the implementation of channel-specific process logic in distinct services that can also serve as technology gateways (see Figure 10-19).

Figure 10-19. Every channel requires its own channel-specific process logic.

Another decision applies to the booking façade. If you already have a generic process-centric service, then the functionality of the booking façade can be included in the process-centric service. Every tier inevitably increases the system's latency. As a distinct entity, it also requires additional attention in the maintenance phase.

Consider a user who attempts to book a specific flight using the airline's Web site. The user can access the flight search functionality, select the flight, and even book a specific seat. However, the actual booking operation fails due to a temporary failure or due to an error in the billing engine. A normal airline simply presents the customer with a message indicating that there is a problem and that it is okay to try laterat which time the booking might or might not work. The actual details of the error might well be far beyond anything the user can easily understand. As a practical example, all credit cards of the brand "Eurocard" ceased to work in 2004 with a major airline's Web site, even though the actual card did not change. The problem was that all the users needed to change the identification of this type of card to "Mastercard."

To cope with such issues, the service-enabled airline goes a step further. A ticket is automatically created for a service center agent indicating the type of failure. The service center agent can complete the booking, using the very same service that the original Web site uses. If needed, the agent can contact the ticket purchaser to request additional information. The Web site, however, might still be unable to access the service due to a network problem or an availability constraint. After the booking is completed, the user is sent an SMS or email indicating that the flight has been successfully booked and payed for. The message includes a link to an appropriate Web or WAP page. This page again uses the same service to access the required information.

Co-browsing is another feature that requires similar implementation techniques. It is a very powerful feature if you want to provide highly interactive portals. You can enable a customer to contact a service center agent at any time within a session by clicking on a button in an Internet form. This click opens a voice and video channel to the agent. The agent gets access to the same application and can support the customer to finish the session. The customer and agent can work with exactly the same user screens to make their dealings as interactive as possible.