Subject: Jini presentations

From: Jim Waldo - SMI Software Development <[email-masked]>
Date: Thu, 8 Apr 1999 13:43:20 -0400

Saleh--

Your request to James Gosling for Jini presentations finally made its way to
me. I've attached a zip file with four powerpoint (erg) presentations that
cover the core of Jini:

	architecture.ppt -- the overall architecture and programming model
	rmi-hqbriefing.ppt -- overview of RMI, the communication base
	lookup.ppt -- the lookup service
	JavaSpaces.ppt -- JavaSpaces, a Jini service.

Hope that this helps...

Jim Waldo

---

From: Jim Waldo - SMI Software Development <[email-masked]>
Date: Thu, 8 Apr 1999 15:22:23 -0400

Glad they help. Feel free to do with them what you will for purposes of your
class. If it comes to publishing, of course, then we have to get some other
agreement...

And feel free to ask me questions. I can't promise to always answer, but I'll
try.

Jim

Saleh Elmohamed writes:
 > Hi Jim,
 > 
 > Many thanks. They look really nice. Quite well done. 
 > I hope you don't mind us using them, modifying them, etc.
 > to fit into our lectures.
 > 
 > I really appreciate it.
 > 
 > ps/ now I know your email so I guess if we have any questions
 > will email you.
 > 
 > best regards,
 > Saleh
 > 
 > 
 > 
 > 
 > On Thu, 8 Apr 1999, Jim Waldo - SMI Software Development wrote:
 > 
 > > Saleh--
 > >

---

From: Saleh Elmohamed <[email-masked]>
Date: Wed, 19 May 1999 10:22:51 -0400

Hi Jim,

Many thanks for those Jini slides; they really came quite handy
for the lectures.

After a conversation with some colleagues at the informatique
section of the medical school, an idea came to mind. It
probably an old hat but would like to read your thoughts on 
how it might fit in the Jini model. I think it will fit quite
nicely ...

Here is a condensed summary:

It is about intelligent devices to monitor insulin
flow for diabatices, monitor the level of cholesterol in th blood, and
others that monitor the overall condition (heart beats, etc.) of the
heart. 

I'm sure such portable devices currently exist in the market but I don't
think they are small enough, or have enough comm/computational
power and smart software to be quite effective. Let's elaborate a 
little more here. Take those heart monitoring devices. They will
consist of two or perhaps three communicating devices. One (A) will be
small enough and light enough to be easily strapped around one of 
the arms or legs of the patient without causing any discomfort whatsoever.
The second (B) will be a hand-held (e.g. PamPilot-like) device that will
be in constant communication with A, at short as well as a reasonablely
long distance. Since both A and B will accompany the patient where s/he
goes, this aspect of communication and the protocol involved should not be
a problem. 

Ideally, through device B, the patient will be able to determine the
condition, adjust A to obtain different kind of diagnosis, blood flow
in and out, the degree of abnormality, etc. B needs to able to control A
with minimal interference from the patient, since s/he usually won't
have the necessary medical training to do the task. So, in addition to
displaying life data/information about the condition of the heart, B will
also have the capability to communicate with a third (C) remote device. 
C will be stationary and at some distance from A and B. Also, C will
possess perhaps more knowledge and computional power than A and B. Since
B usually will be with the patient, it will make use of its power and
knowledge to not only advice A but also the patient in what to do in any
potential emergency case. Now, if it determines that it really doesn't
have enough info to make a judgement one way or another, it will
communicate the info it has to C. This information will include spatial or
rather geographical information on where the patient is currently. Again,
the comm protocol between B and C could be similar to that of A and B, or
may be different. Perhaps, C might be located far away from the patient,
but really distance should not be a major factor in the future. 

The job of C is to rapidly analyze the incoming data, and using the data
in it memory or DB, to come up with a decision/advice that will be
communicated back to B, simultaneously also be sent to the patient's
doctor, the nearest hospital to the patient, and perhaps to the nearest
emergency transportation services. All this has to occur within a very
short period of time. If the situation is not quite critical (a judgement
also made  by A, B, or C) then an advice on what to do next will either
originate from B, or from C and sent to B, or from other sources directly 
communicating with C, such as the hospital, etc. 

It is possible to make do without C, just have A and B. In this case B
not only needs to have a higher computation/comm ability but also
more functionalities. In this case, B will operate without any 
interference from the patient, displaying info when desired and also
accepting input.
These type of devices may have to have:
1. CPU with high clock rate, a 32-bit inst. set will do but 64-bit
   is preferrable. Large on-chip cache (L1) and L2.
2. Fairly large main memory.
3. Quite efficient computational/search/retrieve processes (based on
   efficient time/space algorithms).
4. High emphasis on locality, that is, very low communication between one
   side of the chip to the other so not to affect performance. 
5. Intelligent software to not only tackle the medical situation at hand 
   but also based on the current information is to decide on whether to
   communicate or not to communicate and just deal with it locally. 
6. Interface to the outside for I/O, etc.
7. If we are dealing with many devices then better if each cluster operate
   in a somewhat fedareted fashion. 
8. ...

In a nutshell, that is pretty condensed version of it. 
I sent it to a Sun engineer based here in NY but didn't get much from him.
I don't think he is knowledgeable about Jini.

Any insightful comments on how this might connect/work/operate in/directly
within the Jini programming model, are quite appreciated.

best regards,
Saleh

---

From: Jim Waldo - SMI Software Development <[email-masked]>
Date: Mon, 24 May 1999 15:30:29 -0400

Hi Saleh--

Glad the presentations were of use.

Your idea about the use of distributed devices in medical settings is not old
hat, although we have given it some thought here. I think that it is actually
one of the more interesting and important ways in which small, networked
devices could be used to really change the quality of life.

A person who has been doing a lot of thinking about this is Mike Hawley, one
of the investigators of the Things That Think group in the MIT media lab. You
might want to get in touch with him about some of these ideas...I think he is
further along (having actually done some of these kinds of sensors). Me, I'm
just and infrastructure designer :-).

Jim Waldo

---

From: Jim Waldo - SMI Software Development <[email-masked]>
Date: Mon, 24 May 1999 15:50:53 -0400

Mike can be reached at

	[email-masked]

His group is certainly looking at Jini as part of the infrastructure.

Jim