Content-Generation Technologies

Thin Client Application Models

Thin client wireless applications can be created using a number of different application models. One is based on existing Web content that is transformed for different client devices that require access. The other involves creating new wireless applications from the ground up. Both of these solutions are applicable to various situations.

Extending Existing Web-Based Applications

Many corporations use both internal and external Web sites to disseminate information and to allow users to interact with pertinent data. These Web sites are usually developed using HTML in conjunction with client scripting languages such as JavaScript or VBScript. They have rich graphics, multimedia, and various document formats, all of which makes them unsuitable for consumption by wireless clients which have much more limited capabilities. This creates a need for a way to transform these Web sites into a format appropriate for wireless devices.

Most wireless devices use HDML, WML, or a scaled-down version of HTML. They are unable to handle regular HTML and rarely have support for advanced layouts or graphics. So to display the information contained on existing HTML-based Web sites, essentially two options are available:

• Rewrite the Web site in the appropriate markup languages for the wireless devices, such as WML, HDML, or cHTML

• Use technology to transform the existing Web content into content appropriate for wireless devices

Which option is best suited for your situation depends on the complexity of the existing Web site, what functionality is required on the wireless device, and your Web architecture. If your goal is to make the entire Web site available to wireless users, as may be required in a wireless portal, rewriting the entire Web site is not practical. Why not? Because once you start re-creating the content in new formats, you also create a divide between the main Web site content and the wireless content. That means that every time the content needs to be updated, work will have to be done on both the wireline and the wireless clients. This is clearly unacceptable.

In this scenario, using transcoding technology is probably the path you want to take. This technology gives you the ability to extract existing Web content and transform it into different markup languages appropriate for wireless devices. This goal can be accomplished in many ways, depending on the vendor providing the solution. The following are some of the technologies that may be involved in this type of solution:

• HTML parsing

• HTML reduction to suitable formats for wireless devices

• HTML reformatting to WML, HDML, XHTML, VoiceXML, or other markup languages

• HTML-to-XML conversion

• XML-to-other XML variants

• Image reduction and reformatting

• Business document reformatting

As you can see, many different types of conversion are required to automatically convert existing Web pages to formats appropriate for wireless devices. Furthermore, due to the complexity of existing Web applications and the limitations of wireless Internet applications, this type of automatic transcoding rarely ends up meeting expectations. As you can imagine, reworking a Web site designed for desktop users into one fit for viewing on a wireless device is not easy. Even if you manage to reformat the content, the navigation is vastly different on wireless devices, adding new complexity to the situation. Figures 12.3 and 12.4 illustrate the differences between desktop, Pocket PC, and WAP devices.

Figure 12.3: Web site viewed using Internet Explorer.

Figure 12.4: Web site viewed with PocketIE and a WAP browser.

To help solve this problem, some vendors provide more of a programmatic way of extending existing Web applications. This approach allows developers to interact with various content sources, as well as the existing business logic, to create a wireless client for the existing Web application. In this scenario, the goal is usually to re-create only parts of the Web site that provide true value to the wireless user, as opposed to recreating the entire Web site for wireless access. Rewriting only some sections of the Web site for wireless users is not as problematic as rewriting the entire site. Many of the technologies listed earlier are also required for this type of transcoding; the difference is that you have more control over which sections of the Web application are used and how they are transformed.

Of course, for both of these solutions, the wireless device being targeted plays a significant role in the level of transformation required. WAP devices usually have very limited screen sizes, therefore dramatic changes are required to make the content useful. On the other hand, Pocket PC and Palm devices often have HTML browsers and can handle more complex layouts and graphics. Figure 12.3 shows the Yahoo! sports Web site on desktop Internet Explorer. Figure 12.4 shows what the same Web site looks like on WAP and Pocket PC devices after it has been transformed. You can see that the WAP device requires major design and navigation changes to the Web site, while Pocket PC is somewhere in between. (In Chapter 14, the features offered by the leading wireless application server and transcoding technology vendors are covered in more depth.)

Creating New m-Business Applications

For many corporate wireless applications, simply extending an existing Web site is not the optimal solution. Instead, new applications are created with specific goals in mind. These applications usually provide access to information, allowing users to have real-time access to critical data, so that they can make better-informed decisions. These applications can also allow the user to insert new data or update the data presented. Creating this application from the ground up gives you flexibility that is not possible when extending an existing Web site. You have the opportunity to direct the design of your application to meet the needs of wireless users—of course keeping the screen size and bandwidth constraints in mind. The most successful wireless applications are simple and to the point, so that the user can get at the application's core value with minimum effort. In order to accomplish this goal, key design and architecture decisions should be made at an early phase of development.

In Chapter 11, we covered the architectural layers in a wireless Internet application. Recall that this included the client presentation layer, the middleware business logic layer, and the data integration layer. When creating new applications from the ground up, you will have to address the requirements at each layer to build a successful solution. This is your chance to go through the steps covered earlier in this chapter to create a well-thought-out solution that will meet the needs of the target audience. The following are the main layers that you will have to develop for your new application:

• Support for multiple clients. You will most likely have to support client devices using different browsers and requiring multiple markup languages. Ideally, this will involve creating the presentation content once and then adapting it for each client device. This may involve some level of transcoding capability. Many techniques are available for creating this content; they are discussed in depth in Chapter 13.

• Reusable business logic. Because you may potentially have several wireless clients, and possibly traditional desktop clients, you will want to encapsulate your business logic in reusable components. This will save you from having multiple sets of the same logic. Some of the common object models being used are Enterprise JavaBeans (EJBs), COM or .NET-Managed objects from Microsoft, or just plain Java or C++ classes. Most wireless application server vendors will support at least one of these component models for creating your business logic.

• Data Integration. At some point, your application will be required to access a form of enterprise data. This may be a relational database, business applications, or Web services. In any case, you will be required to have an enterprise integration layer that provides access to these data sources.

When you start down the path of building this type of application, choosing a wireless platform vendor can make the task easier. In most cases, the vendor will provide you with tools, frameworks, and data connectivity components that remove the low-level complexities, allowing you to focus on developing the application itself. For client development, such tools and features may include device-detection capabilities, session management, and content repurposing. The vendor will usually also provide an engine for executing your business logic, and possibly tools to help create it as well. And for enterprise integration, you can minimally expect the ability to communicate with relational databases using ODBC or JDBC, as well as some XML integration support. When you add all of this together, the added capabilities and support will get you well on your way in the development of your application. When putting together a new application for your wireless users, you would be wise to consider the other client types for which, in the future, may require access to the same business logic and enterprise data. Chances are that desktop Web access will be required not long after the wireless interface is deployed, simply because users are not always going to want to access this application from a wireless device. At times they will be using a desktop Web browser, from which they will prefer to access the application for the simple reasons that, by doing so, they will save communication costs and most likely have a more productive, higher-speed interface to the data being presented. This is just one example of a situation in which other types of client access may be required. The point is, design an open architecture that is scalable for adding new clients.

Offline Web Support

One of the growing trends in wireless Internet applications is to provide offline Web support. In its simplest form, this support gives the user access to key Web data, even when a wireless connection is not available. The concept is similar to smart client applications, but usually implemented somewhat differently. Rather than creating client-side applications that contain the presentation layer, business logic, and persistent data storage, offline Web applications make it possible to store Web pages and their related data in a persistent store, either custom developed or sometimes using the cache capabilities of the client browser. Then, when a user requests a Web page when he or she does not have wireless coverage, the page will be taken from the client storage location, thereby providing offline access.

This capability is usually of interest to corporations that want to create wireless applications with a browser interface but are interested in obtaining some of the benefits that smart client applications provide. The goal is to get real-time content when a connection is available and cached content when it is not. When working with the cached content, any changes that are made on the client need to be queued up and sent to the server when connectivity is restored. While this seems like a great solution, it does introduce some restrictions.

For thin client applications, all of the business logic is executed on the server, meaning that when a connection to the server hosting this logic is unavailable, so is the ability to run the logic. This situation poses a problem: Even if you have cached the entire set of Web pages for a particular application, chances are that it will need to access business logic and data in order to be effective. Because the logic and data are not stored on the client, the usefulness of the application without connectivity is severely limited.

This situation is clearly a problem for corporate business applications, though it may not be as serious for some consumer Web sites. For example, if you are interested in reading the latest news or weather information, you may be perfectly happy with Web pages that have been cached for a few hours. In this case, you do not need to be able to interact with the application. It is in these scenarios where this application type has experienced some level of success.

For business application developers, there may still be hope. A new form of hybrid smart client/thin client technology is being made available by several vendors. It is usually based on J2ME, which gives you the ability to store actual business and data objects on the device while still having the ability to receive real-time data. Currently, it is really a scaled-down form of a smart client application, but there are promising signs that J2ME technology will provide us with new, more flexible forms of wireless applications. Additionally, increased support for client scripting languages such as JavaScript allows offline Web applications to offer some business logic on the client for more sophisticated applications.