Summary
After a long absence, I'm back. With some explanations about why I've been gone so long...

It has been way too long since my last entry. As those of you who have been watching Sun know, I've been living in interesting times. But churn at the corporate level is neither new nor, I find, all that interesting. The real reason that I haven't been writing is that the work I've been doing has turned out to be pretty interesting, so rather than write I've been thinking about it.

As some of you know, my group and I have been working on a distributed system that could be used to collect and analyze medical sensor data. Assume for a moment that sensor technology gets good enough that we are all wearing some number of medical sensors-- keeping track of our heart rate, and blood oxygen, maybe EKG, temperature, and the like. Systems like this are being developed, and some simple ones are already being sold for runners and other athletes.

Now suppose everyone is wearing these-- and I mean everyone. Say 300 million people in the United States. Something like this could lower the cost of medical care, because your doctor wouldn't have to see you to get basic triage information (and might even call you to tell you that it was time to come in). Public health could be done real-time. And the research data might turn medicine into a science.

But how could you store and analyze all of this information? That would require a distributed system (to scale) that would need to be federated (because that is the way doctors and medical systems work) that would need to be highly secure, insure the right kinds of privacy, and last for a long time. And that is the kind of system we have been thinking about building.

The problems that need to be solved are hairy, to say the least. The system, for example, would need to insure the privacy of the information gathered, but also allow medical professionals to have access in an emergency. Researchers and public health officials also need access, but in some way that anonymizes the information sufficiently to preserve privacy but not so much as to cloak important trends.

One of the most interesting of the problems is making the system last as long as it needs to last. We decided that the overall system needs to last as long as the patients whose data is being stored in the system; this means a minimum of 70 to 80 years (and this doesn't count the desire to keep the information around for research purposes). But this means that the system needs to be able to change all of the pieces that make up the system, and all of the information and objects need to be able to move around (at least to a new machine) without breaking the system. It also means that we need to design with the assumption that everything (machines, operating systems, even programming languages) will change. The versioning problem can't be ignored in this one.

We've made some progress already. Tim Blackman's deployment utilities came out of this work (we are basing the current system on Jini, or all things). I'm writing this on a plane taking me to JavaOne, where I'll be talking about some of the early results. We hope to be sharing more in the near future; we are working on everything from making classloading in Java more coherent in the distributed case to environments for Jini-style services to some interesting services themselves. And, of course, on security, privacy, and auditing. Our hope is to publish a lot, and release our code to the Jini community in open source form.

And I will also be talking about what we are doing (among other things) here. I find the reactions of this crowd a good reality check for what I am doing, so I look forward to hearing your opinions, feedback, and questions.

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.