OK, school is over and my last paper turned in, so now I can get back to serious blogging.
My device is still bricked, but I will be developing in the interim using the VMWare approach described in Teemu's blog. Before I start coding (and while I am studying up on Python) I will be writing about the requirements for a 770-based case report form application for use in the clinic exam room or hospital bedside setting.
The first requirement is for what I call intermittent connectivity. Any wireless device will eventually lose contact with the Mother Ship, and in a medical setting the device needs to press on regardless. Very few applications are currently set up to handle that turn of events, or at least not to handle it well.
Here's what I wrote back in 2002 about the requirement:
In the opinion of the writer, this architectural feature holds the most promise for groundbreaking applications in the early 21st Century. If intermittent connectivity is to be provided, the client must provide its own implementation of some subset of server functionality while disconnected, hence it requires some implementation effort. The subset typically includes data storage and retrieval and message queuing. A synchronization activity occurs whenever the intermittent connection is re-established. Complex reconciliation logic is required to support serializable database transactions in an intermittently connected architecture.
Intermittent connectivity architectures are a requirement for wireless applications, and immensely useful as a basis for telecommuting and remote workforce automation applications such as sales force and field service applications.
As used in this document, intermittent connectivity refers to the inability of the encompassing system to guarantee the possibility of connection, for example in the case of a laptop computer that must dial into an ISP to join a WAN, or a Web-enabled cell phone that may go in and out of the service area. However, intermittent connectivity architectures can be advantageous even where continuous connectivity is presumed to be available.
For example, in applications in which users are sporadically involved in heavily interactive sessions interspersed with periods of inactivity, intermittent connectivity can help maximize UI responsiveness, synchronizing during idle times. Moreover, the greater complexity of intermittent connectivity architectures can sometimes be justified simply because the cost of downtime is too great in a particular application. An ATM might be networked to its bank via a highly reliable well-shielded leased line connection, but in the relatively rare case that the WAN goes down, the ATM still must not lose any deposit transaction it has already accepted.
Furthermore, when considered in conjunction with device heterogeneity, we can see that intermittent connectivity transcends the assumption that the user will reconnect with the same client device as before—hence the state of the user’s data is maintained on the network in a form that can be served to any device of the user’s choice.
As hinted at in the last paragraph of the excerpt, there are two sides to intermittent connectivity.
The first is the client side, where data and functionality must persist with or without access to the net. The other side of the coin is exemplified by Web applications like del.icio.us and Technorati. Necessary data access and application functionality must be available at any time from whatever device is at hand.
Intermittent connectivity is a high-level requirement that has a number of implications for design. I have to get back to my oar for the moment, but in my next post I will try to go into these implications in more detail.
In the meantime, if you're bored and looking for something fun to read, ;-) you can look deeper into the future of application architectures as I saw it in 2002, you can find the full report in AppArchFutures.pdf (416.6K).
