Access Integration::Client Application Patterns

More detailed business and IT drivers can be found in chapter 4 and Appendix B of the IBM Redbook Patterns: SOA Client Access Integration Solutions

The Thin Client (TC) application pattern is used to provide consistent access to Web applications from multiple device types. This pattern assumes that the device, which is used for accessing a back-end Web application, has a built-in user interface. This might be a simple WAP or HTML browser on a mobile phone or a rich user interface with browser capabilities such as Eclipse. The back-end application is accessed synchronously in online mode (always connected).

Business and IT drivers

Example business drivers:

• Provide universal access to information and services.
• Time to market.
• Reduce Total Cost of Ownership (TCO).

Example IT drivers:

• Multi device access to Web application:
  • Simple browsing
  • Role based browsing
• Write once render many
• Device capability dependent:
  • Distribute device configuration
  • Configuration job transmission error recovery
  • Device inventory

Solution

The Thin Client application pattern consists of three components:

• Presentation component on the client device
• Application component (back-end)
• Data storage (back-end)

The presentation component is the user interface component on a device (such as a WAP browser on a mobile phone or a Web browser on a laptop). It renders data of certain formats depending on its capabilities (for example, WML and iMode format for mobile phone browsers).
Application logic is delivered by the application component located in the back-end. It also manipulates data supplied by the data storage component (in the back-end) and delivers the data to the presentation component on the device. The application component may represent a new application, a modified existing application, or an unmodified existing application. Predominantly these are browser-based applications that must be made available on wireless devices.
Additional services are required to prepare the data stream and to adapt the content to the capabilities of the presentation component (the devices user interface). Security and administration services are necessary to ensure that the device users can achieve a single sign-on to existing applications. These applications may represent applications that automate Self-Service, Collaboration, or Information Aggregation.

Guidelines for use

The Thin Client application pattern should be used for new or existing Web based applications which must be made available on mobile devices. Role-based access is covered by the extension of Portal applications to mobile devices. Depending on the number and capabilities of (mobile) devices which should be supported, appropriate products for Thin Client extension services must be chosen.
In general, a larger variety of devices with different capabilities increases the efforts for maintenance and operation. For this reason, we recommend to enterprises that are in control of their device strategy, to only support a few device types with similar capability (for example, WML, HTML and PDA devices with the similar screen sizes and browsers). This does not apply to Service Providers who must support as many device types (and customers) as possible.

Benefits

The Thin Client application pattern gives users a considerable choice of devices to access their applications and data sources (low function to rich function devices).

Limitations

Thin Client application pattern is unlikely to optimize the user interface for any particular device type. If this is required, additional application changes will be necessary.

Scenario

An insurance company has a team of claims assessors visiting policy holders to check the validity and value of their insurance claims. The claims assessors need frequent and fast access to the policy holder policies, claims details, and so on. In addition, they need to initiate contacts with auto repair garages and rental car companies through their extended enterprise applications. While on the road their preferred access is through a wireless-connected Smart phone device. At home or in the office they use a laptop computer for general activities like writing reports. Hence, the insurance company chose the Thin Client application pattern to extend the existing claims applications to be accessed through a Smart phone device.

Mapping of application patterns to runtime patterns

The Voice-Enabled Client (VEC) application pattern represents all applications which are accessed through speech user interfaces.
A telephony client is the most common example which provides a voice user interface (for example, land-line phone, mobile phone, Voice-over-IP telephone client on a computer with speakers and microphone). The voice user interface is used to access a telephony application at the back-end over telephony networks which are circuit switched (for example, PSTN, GSM). This means that the client side is assigned a dedicated channel through which it communicates with the back-end application. The back-end application is able to understand voice commands. It converts these commands to computer commands and uses its application logic to process data from the back-end data store. The results are converted back into human understandable speech output signals which are transmitted back to the client user interface.

Business and IT drivers

Examples for IT drivers:

• Provide voice access to application
• Add voice access channel to existing application

Solution

The Voice-Enabled Client application pattern consists of 3 components:

• Presentation component (speech enabled with microphone and speaker)
• Application component (back-end)
• Data storage (back-end)

The presentation component is a speech enabled user interface which is built-in to the client device. Typically, this is any kind of telephone. Transmission of data is carried out in the form of voice commands and responses over a telephony network.
The back-end application component is able to process voice commands by transforming them into computer commands. It computes the requested results using the back-end data storage. Then, the application component translates these results back to the human understandable voice outputs (audio signals). These are delivered back to the presentation component or user interface where they are presented to the end user.
If an existing back-end (Web) application is extended with a voice access channel, additional components are necessary to provide these capabilities within the application component. The corresponding Voice-enabled client::Runtime pattern provides these through additional components like a Voice Gateway with a Telephony Connector and the Distributed client extension service. The Voice Gateway with the Telephony Connector provide the functions required to use voice signals for input and output (signal and command translation). The back-end application could still use standard formats like XML for input and output. The Distributed client extension service (voice) takes care of the translation of these data formats to the format of the specific access channel.

Guidelines for use

The Voice-Enabled Client application pattern is used when an application needs to be accessed by telephony type clients. A Web type application which uses standard input and output data like XML is the preferred option. The Distributed client extension service (voice) can use this data and translate it to data for the Voice Gateway. The latter transforms these to voice signals for the presentation component (voice user interface).
It is important to understand that the voice user interface requires special considerations regarding the user interface design. Voice user interfaces must be designed so that users can navigate through menu options without seeing them. If voice recognition is used, the challenges of different languages and dialects must also be considered.

Benefits

The penetration with voice user interfaces (telephony clients) is very high. The number of telephony users is constantly growing thanks to the high availability of mobile/cellular telephony networks.
The user interface client device (telephone) is relatively cheap. It allows human understandable and hands-free communication (voice) which offers more convenience for certain user groups (e.g. drivers). It might even be an option for a user interface where other human-machine interactions are not possible (e.g. in certain industries).

Limitations

The voice user interface is more complex then other user interfaces. It requires special design considerations and extensions. It might be expensive if many languages and dialects must be supported.

Scenario

A ticket booking system for a movie theater is accessed through the Internet using a traditional Web browser. At the moment, a central call center is used to allow users to order and reserve tickets over the phone.
Now, the ticket company would like to extend the existing browser based ticket purchasing application with voice capabilities in order to reduce call center costs. For this, the ticket purchasing application, which is a Web based application producing XML, is extended with voice dialogues in English. The Distributed client extension services (voice) translate this XML content in data formats for the Voice Gateway. Now, the end user can directly interact with the Voice Gateway over the phone using the ticket purchasing application rather then needing the call center.

Mapping of application patterns to runtime patterns

The Distributed Presentation Client (DPC) application pattern describes applications which provide their own user interface for the client device. This pattern extends the Thin Client application pattern with its own application-specific user interface (presentation component). This application pattern also allows offline operation (disconnected operation), in addition to synchronous access to the back-end application component in online mode. Local data storage is used on the client to enable continuous operation with a subset of data in offline mode. Additional services assure that the local data subset is in sync with the back-end application data.

Business and IT drivers

The business and IT drivers are as follows:

• Cache Web site content from Web applications for offline viewing
• Provide offline capabilities for forms based Web applications
• Remote device management functions
  • Recovery in case of configuration job transmission errors
  • Inventory
  • Remote maintenance of middleware

Solution

The Distributed Presentation Client application pattern provides the application programmer with features to make Web content offline available as well as using existing application logic on the device. The programmer can use a locally available data store which is kept in sync with the back-end data source through additionally available client services. Only, the local user interface on the device must be developed to present data in offline and online mode. And even this user interface could be realized by a browser on the device (for example, for offline browsing and offline forms).

Guidelines for use

The Distributed Presentation Client application pattern should be used for new or existing Web based applications which must be made available on mobile devices in connected and disconnected modes. The disconnected use is only recommended if the available offline information must only be up-to-date to a certain extent (information is only updated during synchronization of the data storage). The use of offline forms for data capture in disconnected mode should be chosen when only small amounts of data are captured in static forms and application logic is not necessary during the data capture process (only field validation functions).
Content adaptation and rendering for different devices are also addressed by the Distributed client services.

Benefits

Content provided by existing Web applications can be viewed on mobile devices in online and offline mode. Simple forms might be used to capture data with mobile devices. The mobile devices only need a browser with cache capabilities and/or the Distributed client and extension services for synchronization of the content. The application programmer only has to provide the presentation component (user interface), the application logic runs on the back-end server. This requires less resources on the device, and lowers application operation and maintenance costs. High function devices and major changes to the existing application are usually not necessary. The additional required services are provided by the appropriate Runtime pattern.

Limitations

The Web site caching mechanism only works for static web sites. Forms based solutions with offline capabilities are restricted by the device�s browsers capabilities and limitations necessary for offline usage (only simple forms). Comprehensive application logic is not provided in offline mode.

Scenario

A insurance company provides driving directions through a Web based service. The directions are displayed statically by a Web page (including a map and printed driving instructions). Now, the salesperson can download the driving directions for their next customer visit to their PDA or Smart phone. This allows the sales person to take this information with them and to look it up without the need of an online connection (or carry paper maps).

Mapping of application patterns to runtime patterns

The Distributed Application Client (DAC) application pattern varies from the Distributed Presentation Client application pattern by providing an application component on the device and the asynchronous transmission option. It does not have a presentation component on the device (headless, no user interface).
The Distributed Application Client application pattern represents a custom developed application scenarios on the client with offline (not always online, or occasionally connected) capabilities. These types of clients process data in a store and forward mode where the data is stored locally until a connection can be made and the data can be transmitted to the server for onward processing. Application logic is provided locally by the application component and can run without the presence of a connection to the back-end application.

Business and IT drivers

Example drivers include:

• Use/exploit location information
• Simple push notification
• Alert application of defined state changes
• Remotely trigger actions on device
• Device management
  • Distribute device configuration
  • Transmission error recovery
  • Inventory
  • Remote maintenance of middleware services on the device
  • Remote maintenance of applications on device
• Disconnectable application that does not have a GUI (headless)
• Disconnectable relational database services on device with sync
• Disconnectable transactional messaging services
• Disconnectable Web services

Solution

The Distributed Application Client application pattern focuses on the application component on the client device. The application component is integrated with a back-end application through defined services like the Distributed client and Distributed client extension services.
The client application component uses these services by building on top of a common runtime and common framework that can run on numerous hardware devices and operating systems. The framework and the services ensure seamless back-end integration and offer a common programming model. For example, the data synchronization or messaging services are provided by the Distributed client and Distributed client extension services and can be easily used by the application on the device.

Benefits

The Distributed Application Client application pattern provides a common programming model for server and client side applications. Distributed Application Client applications can enable clients to operate in both online and offline mode. The applications can also use additional (platform and runtime) services, including transactionality, relational database, reliability, security and management services (like device management).
Although, the extension services provide a stable runtime environment, the application on the device should be designed and developed with great care. A local corrective user interaction on the (usually remotely installed) device is not possible.

Limitations

Caused by the higher resource requirements, the Distributed Application Client applications are limited to a set of devices that are capable of operating the runtime environment together with the framework required by the clients. A local user interface is not available.

Scenario

A possible scenario is a remote power meter in a household. A local application records the power consumption over time. The amount of consumed power is stored locally and transmitted to the energy provider in a timely fashion. This allows the energy provider to bill the household automatically. It also offers additional use cases, such as identifying peak times, remote power management and charges for different times of day.

Mapping of application patterns to runtime patterns

The Distributed Rich Client (DRC) application pattern extends the Distributed Application Client application pattern with user interface capabilities. This implies that client devices must fulfill higher resource requirements to provide user interfaces for human interaction (for example, hardware for user interaction such as a display and keyboard, software and graphical libraries).
The Distributed Rich Client application pattern contains local data storage in order to achieve independence from the back-end application in disconnected mode. Subsets of data are held on the device to be able to continue working when network connectivity is not available or not allowed. Synchronization services ensure that the locally manipulated data is kept in sync with the back-end data storage (for example, through an embedded database synchronization service). The local user interface (presentation component) provides access to the local data storage. The application on the device provides application logic for data manipulation.

Business and IT drivers

Examples for IT drivers:

• Use/exploit location information
• Simple push notification
• Alert user/application of defined state changes
• Remotely trigger actions on device
• Device management
  • Distribute device configuration
  • Transmission error recovery
  • Inventory
  • Remote maintenance of middleware services on the device
  • Remote maintenance of applications on device
• Disconnectable application that has a Web UI or rich UI
• Disconnectable relational database services on device with sync
• Disconnectable transactional messaging services
• Disconnectable Web services

Solution

The key to the Distributed Rich Client application pattern is the application itself. As opposed to other Web-based solutions such as the Thin Client application pattern, the DRC focuses on the client tier, which has many of the capabilities of a server platform on the local device to allow for working in a disconnectable mode.
The client application uses services and accesses components on the server side. It is built on top of a common runtime and common framework that can run on numerous hardware devices and operating systems.
Many Distributed Rich Client applications are capable of operating in both online and offline mode. These applications are always available for the user with full functionality, even if the network is down for any reason. Once the network is available, the data and information can be synchronized to/from the server and client. When working in a disconnected mode, it is important to note that only the business function is available all the time, not the most current data.

Guidelines for use

Distributed Rich Clients are similar to the clients of client-server era, in that the devices provide fat client functionality, however; they have the advantage of server-based management. Some of the application logic is implemented on the client-side where they can use services that are not available for thin clients. For example, transactionality, reliability, security, offline data store (relational database), and so on.
Distributed Rich Client applications do not have the usability constraints that Thin Clients have. Interactions can be longer and more complex. Distributed Rich Clients can have controls (user interface components) that are not available to Thin Clients.
Beyond the rich user experience, there are various qualities of service available to these clients. For example, a client and a server can exchange information over a reliable communication, and the user can make sure that the interaction was successful.
Distributed Rich Client applications should ideally be designed in a way so that they can operate in both online and offline networking modes. Imagine the online operation as a special case of the offline operation where information is exchanged (synchronized) instantaneously, not in a long-running store and forward manner.

Benefits

The Distributed Rich Client applications provide a richer and better user experience with extended functionality. Distributed Rich Client applications can enable clients to operate in both online and offline mode. The applications can also use additional services, including transactionality, relational database, reliability, security and management services (like device management).

Limitations

In light of the higher resource requirements of the Distributed Rich Client applications are limited to a set of devices that are capable of operating the runtime environment together with the framework required by the clients. Applications which require constant online connectivity, like instant messaging, or multimodal access are covered by variations of this pattern.

Scenario

The scenario is based on the fictitious ITSO insurance company. In this scenario, mobile adjusters can access and change insurance claims from there mobile device while inspecting the car damages at the scene of the accident. This is possible, because the function rich Mobile Adjuster application is able to work in a connected or disconnected environment. The underlying technology ensures that necessary data is available in offline mode and synchronized with the back-end regularly. Locally provided application logic guarantees application robustness (for example, correct data input).

Mapping of application patterns to runtime patterns

The Distributed Collaboration Client (DCC) application pattern is a variation of the Distributed Rich Client application pattern. It especially addresses rich applications which need frequent online connectivity to their server counterpart for collaboration purposes. Examples are instant messaging and Web-based e-mail applications.
The client side consists of one node with presentation and application components. Application logic is locally provided to ensure rich user experience and performance advantages.

Business and IT drivers

Since this pattern is a variation of the Distributed Rich Client application pattern, the same requirements can be applied. In addition, the following IT drivers and capabilities make this pattern unique:

• Instant messaging
• People awareness
• e-mail

Solution

The Distributed Collaboration Client application pattern provides client components for collaboration giving a rich user experience. The client application offers device dependent user interface capabilities.

Guidelines for use

The application pattern is used when Distributed Rich Client application pattern IT drivers also include requirements for collaboration functions with online connectivity needed frequently.

Benefits

The Distributed Collaboration Client application patterns provide a richer user experience with extended functionality. The applications can also use additional services, including transactionality, relational database, reliability, security and management services (like device management).

Limitations

Caused by the higher resource requirements, the Distributed Collaboration Client applications are limited to a set of devices that are capable of operating the runtime environment together with the framework required by the clients. The major difference and limitation to the Distributed Rich Client is the necessity of a constant online connection for capabilities such as instant messaging and people awareness. The DCC can run in a disconnectable mode for other application common to DRC and e-mail collaboration.

Scenario

An example scenario would be the extension of the our working example with instant messaging capabilities. The Mobile Adjuster would get the opportunity to communicate online with the other Adjusters or the back office whilst being at the accident scene. The back office would be able to inform him instantly of changes or other necessary information.

Mapping of application patterns to runtime patterns

The Distributed Multimodal Client (DMC) application pattern extends the Distributed Rich Client application pattern with richer user interface capabilities. Especially, the use of different input and output channels for application navigation are covered by this pattern. For example, a rich client application such as a vehicle navigation system needs to be enhanced with voice navigation features.
The presentation component is extended with additional input and output capabilities (e.g. microphone, speaker). The client application component provides application extensions for the additional presentation channels. The application framework might also provide the technology for this richer user interface experience.

Business and IT drivers

Since the Distributed Multimodal Client application pattern is a variation of the Distributed Rich Client application pattern, the same requirements can be applied. In addition, the following IT drivers and capabilities make this pattern unique:

• Disconnectable application with multimodal user interface

Solution

The Distributed Multimodal Client application pattern provides client components for the extension of rich user interfaces with multimodal capabilities. The combination of voice and text input and output capabilities in one application is provided by additional capabilities in the application and presentation components.
Challenges of the constant connectivity requirement on mobile devices are addressed by management functions of the platform. The client application offers device dependent user interface capabilities.

Guidelines for use

The Application pattern is used when the Distributed Rich Client application pattern IT drivers also include requirements for multimodal user interface extensions.

Benefits

The Distributed Multimodal Client applications provide an even richer and better user experience with extended input and output functionality. Distributed multimodal client applications can enable clients to be operated on mobile devices with limited resources. The applications can also use additional services, including transactionality, relational database, reliability, security and management services (like device management).

Limitations

The major difference and limitation of Distributed Multimodal Client are the higher target device requirements. The used device must support the different input and output channels (e.g. microphone, speaker, keyboard).

Scenario

An example scenario would be the extension of the ITSO Mobile Adjuster working example with multimodal input and output capabilities. The Mobile Adjuster would be able to communicate with the application over voice and keyboard. While driving to the scene, the adjuster could interact with the application using voice commands to open up and display the customer claim in advance.

Mapping of application patterns to runtime patterns

The Built-in Client (BIC) application pattern is a generic superset of all other Application patterns introduced in previous sections. The BIC includes functions which are provided by the device manufacturer as built-in applications where the device manufacturer has chosen to adopt the appropriate open standards to communicate with the enterprise middleware.
Examples are PIM and e-mail clients on PDAs or device management functions on mobile phones (remote configuration). Depending on the provided function of the built-in application, this pattern evolves into one of the other patterns above. The built-in application component will be replaced by the client component of the Application pattern which matches the IT drivers and capabilities identified for the solution.

Business and IT drivers

Examples for IT drivers and capabilities:

• Use devices with existing built-in standard functions and standardized interfaces (e.g. device management clients following the OMA-DM standard)

Depending on the built-in function required, the Built-in Client application pattern matches one of the other application patterns, where the appropriate IT drivers and capabilities are listed.

Solution

The Built-in Client application pattern covers all standardized functions which are provided by the device manufacturer as applications on the device. The client side application does not need to be developed anymore. The rest of the solution depends on the matching Application pattern.

Guidelines for use

This pattern is a generic Application pattern.

Benefits

The Built-in Client is used as an entry point and addresses the advantage that the client side application has standardized interfaces and is already provided by the device manufacturer. A client side application does not need to be developed anymore. The standardized interfaces enable the server side application to work with the client seamlessly.
Solution development, maintenance and operation efforts as well as potential risks are effectively reduced.

Limitations

In many cases, there is no way to alter built-in function unless at the platform level (software). The other limitations of the matching Application pattern apply.

Scenario

An example is the built-in device management functions of mobile phones. Mobile phones which include a OMA-DM client can be configured over the air through the standardized device management interface.