Case Studies:  

A Wireless PalmOS Enterprise Application

One of our clients needed to develop and deploy an enterprise application onto wireless PalmOS devices, including PalmV, PalmVII, and Handspring Visor. They suspected that some portions of the PalmOS would need extension, but they also needed rock-solid data integrity and the ability to extend the system beyond Palm devices to RIM 950s and PocketPCs. They anticipated that new capabilities would be developed and deployed in subsets.

Through it all, they wanted an integrated backend that wouldn't fracture with the addition of unique wireless client capabilities, and that would allow their application development staff on the hardwired side to operate reasonably independently of the clients as they evolved.

The Unusual Technical Requirement

The twist to this problem lay in which PalmOS services needed extension - the INet and Net Shared Libraries. PalmOS has built in facilities for extending some of its features, through a mechanism called Traps. However, shared libraries are not part of those facilities, and to make the problem harder, these particular libraries are in ROM: simply patching them like other traps (given the needed information) was not possible.

PalmOS INetLib and NetLib Trapping

SilkSpeed set about the task of meeting the client's needs. Characteristically, the business needs were flexible to the difficulty of the problem, but also evolving with the business they were in. We worked with the client to first make sure such invasive efforts within PalmOS were needed to meet the business requirements. They were.

By focusing on the business requirements, and not the perceived technical issues, SilkSpeed was able to establish the value chain of technical capability to revenue producing activity. This approach clarified, hastened and streamlined the decision process, saving time and effort. In nearly real time, we were able to build the decision tree for the business needs as we tackled the technical issues.

Meanwhile, in the Real World

Of course, all of the PalmOS work was less than half of the problem: the Palm application is expected to be deployed to thousands of clients, to have an indefinite life cycle, to support new features and capabilities, and to be migrated to new wireless devices, including handsets, in the future.

While the Palm device work was underway, we had a second team working in parallel on the wireless-device to backend server data exchange. Data integrity, efficient data management, and support for the migration and evolution of the capabilities of the deployed wireless client were key.

SilkSpeed's attention wasn't drawn to the basic transport issues: they were almost trivial from our point of view. We understood that over the life span of the product, there would be many different clients, each of them with their own capabilities, each evolving. We also anticipated (correctly, it turned out) that the backend data modeling was incomplete, and so the terminal database schema would evolve as well.

Our client needed a solution where both ends of the information chain, the client and the backend server system, would independently evolve, yet remain interoperable: i.e., the first client, deployed on the first day of the system's operation would still be processed correctly with the final backend throughout the system's lifetime.

SilkSpeed built a multi-tiered server architecture that decoupled the ends of the system, permitting the operations DBA staff (as opposed to software developers) specify the transformations of the data. We even provided for database product independence: Teradata, Oracle, and Postgres are each valid targets for the backend.