This chapter is from the book
This chapter is from the book
This chapter is from the book
Multi-Channel Access
The primary purpose of most organizations (commercial, government, non-profits, and so on) is to deliver services to clients, customers, partners, citizens, and other agencies. These organizations often use many channels for service delivery to reach their customers to ensure good service and maintain customer loyalty. Just as a bank prefers to offer services in a variety of ways for the convenience of their customers, whether using the Web, an ATM, or a teller window, many other organizations similarly benefit from being able to deliver a mixture of direct and indirect customer services over a mixture of access channels.
In general, business services change much less frequently than the delivery channels through which they are accessed. Business services represent operational functions such as account management, order management, and billing, whereas client devices and access channels are based on new technologies, which tend to change more frequently.
Web services interfaces are good for enabling multi-channel access because they are accessible from a broad range of clients, including Web, Java, C#, mobile devices, and so on. SOA with Web services is, therefore, well suited to simplifying the task for any organization to enable these multiple channels of access to their services.
Figure 1-9 illustrates an example of multi-channel access in which an organization's customer service application might expose various services for reporting a problem, tracking the status of a problem report, or finding new patches and error reports published to the user community. A customer account manager might want to access the services from his cell phone, to discover any updates to the customer's problem report list, for example, before going on a sales call. If the product was shipped through a reseller, the reseller might provide its own customer service, which would be tied to the supplier company's application to provide first- and second-level support, respectively. The customer service manager for a given major account might benefit from direct access to all of the features, functionality, and information stored in the organization's customer service application. The customers themselves might want to check the status of a trouble ticket from a mobile PDA device. And finally, the support center employees need access to the services in the application to perform their own jobs of interacting with the customers who have problems.
)
Figure
1-9 Multi-channel access to customer service.
In the past, organizations often developed solutions like this as monolithic applications tied to a single access channel, such as a 3270 terminal, PC interface, or a browser. The proliferation of access channels, including new end-user devices, represents an opportunity for a service-oriented enterprise to better serve its customers, suppliers, and partners anytime and anywhere. However, it also represents a significant challenge to IT departments to convert existing monolithic applications to allow multi-channel access. The basic solution is, of course, to service-enable these applications using an SOA with Web services.
Occasionally Connected Computing
Integrating mobile devices into an SOA presents specific challenges because the mobile devices may not always be connected to a network. Mobile devices may also move through network connectivity zones, picking up new IP addresses when they reconnect. Most applications in production today are not designed to handle such variances in network connectivity. A new generation of "mobilized" software is emerging to integrate mobile devices quickly and easily into the service-oriented enterprise.
As shown in Figure 1-10, the SOAP messages in a mobile software solution are transported from the mobile client to the server using a store-and-forward asynchronous protocol that allows the mobile client to keep working even when a network connection isn't available. When the connection is available, transactions flow to the server-side SOA-based application directly using the messaging transport. When a connection isn't available, transactions are stored locally so that they can be transmitted when a connection becomes available.
)
Figure
1-10 Occasionally connected architecture for mobile devices.