ThinAir Server Platform White Paper June 2000 ThinAirApps, Inc. 1999, 2000. All Rights Reserved
Copyright Copyright 1999, 2000 ThinAirApps, Inc. all rights reserved. Neither this publication nor any part of it may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without permission from ThinAirApps Inc. June 2000. Printed in the United States of America. Trademark Attributions ThinAirApps SM, ThinAir Server, ThinAir Provider, ThinAirApps logos and/or other ThinAirApps products referenced herein are trademarks of ThinAirApps. The names of other products mentioned herein may be the trademarks of their respective owners. ThinAirApps 428 Broadway New York, New York, 10013 USA ThinAirApps, Inc. 1999, 2000. All Rights Reserved 1
The ThinAir Server Platform ThinAir Server is an open and extensible platform, offering applications a broad range of services focused on the wireless access paradigm. The server provides a rich execution environment, capable of supporting access from many different types of wireless devices, and of allowing applications to serve data to and interact with the users of these devices. Applications leverage core ThinAir Server functionality such as the ability to detect and gather device-specific information, store persistent user information, and access various distributed data access components. Real-Time Access to Data In contrast to mobile computing technologies that rely exclusively on synchronization between device and desktop, the ThinAir Server application model focuses on providing a real-time, two-way communication channel between end-users, with their myriad devices, and back-end data stores and organizational applications. Device users gain instant access to the most up-to-date information and have the ability to affect that data remotely. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 2
A Secure Solution The modular architecture of ThinAir Server is designed to specifically address the wide range of security models employed by all types and sizes of organizations. The server leverages the same 128-bit Secure Sockets Layer (SSL) protocol relied upon by industry-leading Internet e-commerce and financial applications. The distributed architecture supports the most complex and tightly regulated firewall and LAN configurations with ease. The platform also takes maximum advantage of security mechanisms provided by Wireless Service Providers (WSPs) and device manufacturers, ensuring that your data is secure as it travels the numerous links between the enterprise and wireless device. Groupware Access for ThinAir Server The Groupware Access for ThinAir Server application is included with this server distribution, giving your organization an immediate channel from the most popular wireless devices into secure groupware and messaging servers. The devices supported by the Groupware Access application are include Palm handhelds, WAP and HDML handsets, RIM Inter@ctive Pagers, and any HTML Micro-Browser including Pocket IE on Pocket PCs. Leading corporate messaging servers, such as Microsoft Exchange and Lotus Domino, are supported, as well as any open standards-based server which utilizes IMAP, POP, and LDAP. Empowering Developers ThinAir Server is designed to allow developers to quickly build applications that interface with existing Web sites, groupware servers, sales automation tools, databases, or virtually anything else. Please visit the Developer section of the ThinAirApps Web site at www.thinairapps.com/dev for more information and to download the Wireless SDK for ThinAir Server. An Open Platform ThinAir Server is an open, extensible platform for developing and delivering applications to a variety of wireless devices, from palmtops to WAP-enabled handsets. Implemented in 100% Pure Java, the ThinAir Server architecture manages the communication details of each device automatically, allowing developers to concentrate on writing the business logic of their applications. This document introduces developers to the tools and services that make up the Wireless SDK for ThinAir Server. It includes both a general overview of the ThinAir application development model and a series of step-by-step examples that use the SDK APIs to implement useful applications. An application built for ThinAir Server is composed of one or more components called Connectors. Each Connector is a small Java program written on top of the ThinAir Platform API that implements the application for a set of device types. The server provides each Connector with several run-time services, including device identification, session management, and a persistent data store for user information, that satisfy requirements common to most applications. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 3
For more complex applications, a Connector can be complemented with a data-acquisition component called a Provider. By implementing a Provider, developers can delegate the interaction with a remote data store to a separate module, allowing the Connectors to focus exclusively on communication with devices. ThinAir Server supports Providers running within the same process, as separate processes on a single machine, or as fully distributed components on multiple servers within a public network. These options allow an organization to configure its applications for optimal scalability and fault-tolerance. Groupware Access for ThinAir Server is an example of a full-featured application leveraging the capabilities of the ThinAir Server. The Groupware application is composed of Connectors for Palm and RIM handhelds, WAP and HDML-enabled phones, and HTML Web browser devices including Pocket PC. The standard ThinAir Server installation includes Providers for POP, IMAP, Exchange, and Lotus Domino groupware servers. Each Connector can communicate with any of these Providers to obtain groupware data. Finally, the ThinAir Server architecture employs full SSL services (including HTTPS) to protect communication between devices, Connectors, and Providers. This and other features, including a fully encrypted user profile store, ensure that ThinAir Server meets the highest industry standards for security within a distributed system. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 4
Architecture ThinAir Server provides a highly modular and pluggable foundation for serving applications to wireless devices. ThinAir Server accepts HTTP (or HTTPS) requests and distributes them to registered applications. These applications then respond to requests with content appropriate for each type of device. In the case of browser-based devices, this may be markup content such as WML, HDML, HTML, or others. For devices that support other types of content, applications may support them as well. Applications running on the server may consist of just a single component, or may in fact be made up of several discrete pieces, all easily administered, which communicate through the core server framework. Depending on the particular scheme of the device/wsp, ThinAir Server applications may also leverage client-side components to handle user-interface and network operations. Devices Independent of any applications running on it, ThinAir Server maintains a pool of device decision logic. This logic, built into dynamically pluggable components installed in the server, allows it to examine an incoming request, make decisions about the nature of the requesting device, and gather detailed information on that device to make available to applications. The server framework takes these responsibilities away from the application developer in a flexible, extensible way. Support for new devices can also be added as they are released into the market, ensuring long-term value of the server. Connectors Connectors, the fundamental building blocks of ThinAir Server applications, are responsible for receiving requests from particular types of devices and returning responses appropriate to the capabilities of those devices. ThinAir Server manages a set of loaded Connectors and delegates incoming requests to them appropriately based on device type and application. By using this approach, a ThinAir Server application can be expanded to support new types of devices simply by adding additional Connector functionality. Connectors may or may not support custom client software installed on the wireless device. ThinAir s Groupware Access application for the Palm handheld consists of both a server-side (Connector) and client-side (.PRC application) component. However, the same application also supports WAP-enabled handsets by taking advantage of the device s built-in WML browser and does not require any ThinAir software on the device. Connectors, then, support ThinAir Server applications and are configured as part of the ThinAir Server configuration process. Connector modules can be removed and inserted into ThinAir Server without restricting information flow to other devices. Providers Any back-end data-access logic required in a ThinAir Server application can be easily separated into a distributed, load-balanced component known as a Provider. While Providers are optional components of applications, in many cases they offer significant performance and management advantages. A Provider may be loaded with, and run in, the same process as ThinAir Server itself. It can also be configured to run standalone, residing on a different machine, including that of the data-store itself, or even in a different LAN or authentication domain. Once registered with a ThinAir Server, Providers accept requests from Connectors, authenticate them, and retrieve data from various stores using appropriate protocols. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 5
ThinAir Server Device Detection Connector(s) Provider Data Store Device ConnectorAccess session management user profiles Provider proxy User Management Fundamental to ThinAir Server is its ability to manage User Profile information on behalf of applications. These profiles allow applications and administrators to manage user devices, ensuring that the user experience is fully tailored to their particular handheld and that administrators have a convenient, consistent way to control application use. The profile management aspect of the server extends to support different levels of authentication and varying security requirements. ThinAir Server includes a graphical tool, ThinAir Server User Manager, for administering the users, applications, and devices communicating with the server. Security Mechanisms ThinAir Server offers wireless devices a secure gateway into an organization s sensitive internal data stores. In addition to encrypting data as it travels over both wired and wireless public networks the ThinAir Server Platform offers authentication services and ensures the integrity of transmitted data. ThinAirApps leverages an industry-leading SSL 3.0 implementation from RSA Security, Inc. to accomplish this goal. The Secure Sockets Layer (SSL) protocol is a reasonably complex one, and some configuration is required to enable it for ThinAir Server. At the simplest level, SSL requires that a secure server have associated with it a Public Key Certificate and a Private Key. The server manages these through a ThinAir SSL Activation File, a file you generate based on your Certificate and Private Key. Between the Server and Wireless Devices The ThinAir Server manages potentially two SSL connections, one between the server and any Wireless Service Provider s proxy, and one between the server and any distributed Providers running with SSL Mode data connections. In the first case, ThinAir Server acts as a secure server and accepts secure connections from clients. Note that the client is actually not the wireless device in most cases, but a proxy server maintained by the WSP. This means it is important that these proxy servers recognize the Certificate Authority (CA) used to sign the ThinAir Server's Public Key, as it is not typically possible to accept new CAs as one might do in a conventional desktop Web browser such as Microsoft Internet Explorer. This also places restrictions on your ability to use your organization s own CA. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 6
Between the Server and Distributed Providers When using an SSL Mode data connection between the server and distributed Providers, both components act as both server and client, depending on which makes the connection first. The /certs subdirectory of both the server and distributed Provider installations contains Root Certificates for a number of popular Certificate Authorities Root Certificates that are used to verify the validity of a server s certificate when the component is acting as a client. Both components must have a ThinAir SSL Activation File available, though the Certificate on which they are based may come from an internal or other less popular CA. If using a CA for which there is no Root Certificate in the /certs directory, you will need to add the Root Certificate appropriately. Applications, Devices, and User Profiles The ThinAir Server architecture provides three fundamental abstractions underlying both its administrative and application development models: Applications, Devices, and User Profiles. Applications An application is a collection of services that collaborate to provide wireless access to some computation or data store. In the ThinAir architecture, one or more Connectors implement an application. With the ThinAir User Manager tool, administrators can see which Applications have been installed on a server, and for each application, the users who have registered with it. The ThinAir platform provides a security model for applications that governs the conditions under which users of the system can access them, and how they can take advantage of the server s User Profile functionality. Using the User Manager, administrators can add and remove users to applications and modify these security settings to suit their organization s preferences. Devices ThinAir Server currently supports the industry s most popular and powerful wireless devices, and ThinAirApps mission is to keep pace with the latest advances in wireless technology. When a device contacts the server, its properties (such as screen size, resolution, or color depth) are automatically recognized by the server and made available to applications. If one such property is a unique device identifier, the Connector writer may choose to associate that ID directly with the User Profile of the person making the request. Connectors can use this technique to track users by their devices and to format output conditionally depending on the user and/or type of device to which they are responding. With the User Manager, administrators can graphically relate the devices a user possesses to the applications she is working with. User Profiles Applications often require the ability to identify repeat users and record new ones when they first contact the server. To address this common need, ThinAir Server creates a passwordprotected User Profile for each user of the system, identified by a globally unique ID (the user s ThinAir User ID). User Profiles include information about which devices a user possesses, which applications he has accessed, as well as any application-specific data (such as backend server account information) stored in them by Connectors. The ThinAir User Manager manipulates User Profiles directly, allowing an administrator to inspect a user s profile information, and add (or remove) users to the system and to particular applications. Finally, ThinAir Server can persist User Profiles to a flat file, and will recover this information when restarted. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 7
Wireless Application Considerations There are many important steps to successfully building and deploying a wireless application. Each new application will be targeted at different sets of devices, and allow interaction with different sets of data. While the ThinAir Server Platform empowers developers to create wireless applications, there are still a variety of issues to understand and work through. Before you begin planning your code, you will want to make a few important decisions about your application: How will wireless extend your existing application? Not all Web or desktop-based applications will be easily extended to wireless devices. Email, stock trading, and formbased data collection are obvious applications, with fairly straightforward application models. Anything involving a basic push or pull of information can be supported easily. More complicated application models that involve data in various states with a high amount of interaction between the user and server will require more careful planning and consideration. The need for offline queuing and data access will also complicate your application, and its inclusion should be carefully considered. What devices do you want to support? Wireless devices vary widely in price, capabilities, and coverage; if your organization hasn t already standardized on one, it should make this decision very early in the development process. You may find that settling on a single device is impossible because of the diverse needs of your users. The ThinAir Server provides Connector writers with tools to accommodate almost any wireless device, but as the number of devices an application is required to support grows, so will the development effort. Technically, there are several key factors that may affect which device is best suited to your intended application, and thereby influence your design approach: Screen size and resolution. Make sure you ll have enough screen real estate to present a reasonable user interface. Markup language richness. Some devices support a variant of HTML, with an application shell (start screen) and certain resources, such as icons, resident on the device. Other devices use multiple card-based markup languages, allowing for device-side manipulation of data through variables and scripting. Examine the features of the device s markup language, and make sure they can support your intended interaction model. Input mechanism. If your application will require extended text input, be sure that the device provides a keyboard, stylus, or other mechanism that s comfortable to your users. Native application capability. Some wireless devices support only markuplanguage (browser-type) applications, while others are fully programmable. If your application will require complex processing on the device itself, make sure it s of the programmable type. (In many cases, though, processing should be offloaded to the server; the wireless application should be kept as simple as possible.) ThinAirApps, Inc. 1999, 2000. All Rights Reserved 8
Should your application be implemented as a single Connector or as several Connectors? A Connector is capable of servicing requests from one or more types of devices. If your application logic is basically the same for all device types, with minor changes, you ll probably want to implement it as a single Connector and insert some conditional logic to execute any device-specific code. On the other hand, if your implementation varies widely from device to device, your code will be simplified if you implement a separate Connector for each device type, with shared classes encapsulating the application logic. Do you want to implement Providers? If you are developing a simple application that does not require interaction with a back-end data store, or if some interaction is required, but it can be managed without a lot of complex code, then a Provider may not be necessary. However, if communicating with the back-end data store requires significant processing resources, or if it embeds logic that can be repackaged in a form that s more convenient for use by Connectors, then you may want to implement Providers for the data. You ll also want to consider whether your application would realize significant performance advantages by deploying distributed Providers. Distributed Providers permit the server to dynamically load-balance by routing requests in round-robin fashion to Providers running on different machines. The Connector(s) will handle device requests on one node of the network, while the Providers will communicate with the back-end store on others. How do you want to securely access back-end data stores? An application can attempt to access a secure back-end resource in any way the developer chooses it is a combination of administration and development work that ensure a well-behaved, unbreakable application. In this vein, the application development process happens in concert with the system administration of any back-end resource. For example, an administrator may maintain a database of internal customer data that a developer wishes to access in their application. This would typically be most effectively implemented by having the developer write the application using some standard database-access interface, such as JDBC, in coordination with the administrator maintaining user accounts for that database. The security of the application s back-end, then, can leverage the back-end security system with a username and password scheme. The ThinAir Server environment offers applications straightforward ways to store and securely manage this type of sensitive information, or even just to pass it straight through from the user every time. The Groupware Access for ThinAir Server application is an example of a highly secure solution built using a combination of back-end and internal server authentication and verification mechanisms. Each Groupware Access Provider implements a different security mechanism appropriate to the type of back-end store it accesses, though the application in general also optionally stores encrypted information in the User Profile Store. Conclusion Whether you are interested in wireless access to your groupware or messaging server, or you need to develop your own application, the ThinAir Server Platform provides a robust, secure, extensible solution. For the enterprise, the Groupware Access application is a quick and powerful solution for enabling the myriad of consumer wireless devices to become secure terminals into corporate servers. More enterprise-focused applications will also be released in the coming months, adding to the value of your existing server. For developers, the platform provides a real set of tools and services for enabling existing applications, without proposing an infeasible magical, all-in-one type solution. As the wireless device and application market evolves and expands, ThinAirApps modular and component-based technology can be updated and enhanced to support the most cutting-edge needs. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 9
Please visit our Web site at www.thinairapps.com for the latest information on our products, and the developer site at www.thinairapps.com/dev for more information on the Wireless SDK. ThinAirApps, Inc. 1999, 2000. All Rights Reserved 10