Access to SNF version of Remote Coral:

John Shott shott at snf.stanford.edu
Fri Feb 16 14:09:13 PST 2001


Katalin, Todd, Bob, Vicky, Tom, Duane, Lynn, Karlis, Guy, Bill, Greg, Steve
and Ernie:

We are pleased to announce that we have a remote version of the Coral lab
management system that, we believe, you will be able to run from your desktop
to access the "production" version of the Coral application ... at least the
version that is currently running here in the Stanford Nanofabrication
Facility.  We hope that this will give you a first-hand look at the current
status of the Coral system.

In a following message, I will provide instructions as to how to get this
operational on a local machine ... we believe that it will run on Windows
95/98/NT/2000/ME and on Solaris and Linux boxes.  We fear that it will not run
on Macs (with the possible exception of Macs running OS X) because it appears
that Apple is far behind the curve in terms of their support of recent
releases of the Java Virtual Machine.

The version of Remote Coral that you will be able to download is the exact
version that we are running in production in our lab ... and is identical in
method of deployment to what we are doing on our staff desktops, other lab
members on campus, and SNF members from other universities and local industry.

We are using a recently announced (but free) product from Sun called Java Web
Start (information: java.sun.com/products/javawebstart).

Virtues of this approach include:

1. The full Coral client application is downloaded onto your local machine in
the form of a JAR file and runs on your machine ... this means that things
like screen re-draw happens quickly because it is running on your local
machine.  The comparatively terse messages that flow between client and server
mean that performance is acceptable even over a low-bandwidth network
connection ... and only slightly degraded from what we see in the lab for a
more reasonable network connection.  I've successfully run our client over a
modem! Finally, unless the Client changes (with improvements, for example ...
see item #2) it only needs to be downloaded once ... not everytime you want to
run the application.

2. Each time you fire up this application, Java Web Start checks to see if a
more recent version of our client software is available ... it there is, it
will automatically download that for you the next time it runs.  This greatly
simplifies the problem of deploying upgrades or worrying about folks who may
be running a sadly-out-of-date version of our application.

3. With the exception of a slightly different authentication method (which we
have already taken care of) the in-lab and the remote client are identical. 
This means that as we add enhancements to the local Coral application, they
will be automatically be ready to go for the remote clients as well ... we
don't have separate development paths for remote vs. in-lab applications.

The only  negative that we have found thus far to this approach would be if
you are operating from behind a firewall ... a tightly locked firewall will
not likely allow the CORBA traffic to pass (which is the underlying
communication mechanism between clients and servers).  It is our belief that
in the not-too-distant-future more firewalls will be able to selectively pass
CORBA (IIOP) cummunication traffic. (At the moment ORBIX, a CORBA vendor,
supplies and sells WonderWall that is a CORBA-aware firewall ... but that
costs money!)

Enough about Java Web Start ... but we think that it a good way for us to
deploy the Coral application remotely.  Now let me tell you about the current
status of Coral and how we have set up things for you:

The current version of Coral is fully functional and has what we believe to be
the core elements to run in laboratories such as ours.  Specifically, people
can make/delete reservations on equipment, enable/disable equipment when they
use it, and be added to the authorized list of users for each piece of
equipment.  Additionally, they can report problem/shutdown conditions
affecting equipment, quickly see the problem/shutdown status of each piece of
equipment, and look at the history of their equipment usage.  Finally, staff
members can charge other lab members either for equipment usage or thier staff
time ... or charge staff time to a variety of other projects set up in the
database for their use.

For each of you, if you didn't already have an account with us, I have set up
an account that uses your e-mail login name as your Coral login name.  I have
also set up a password for each of you that I can communicate either via phone
or alternative method. Note: at the moment we require members to set their
remote password (which may be different from their "normal" password) locally
(using a local Coral client) ... this allows us to limit the population who
can access our system remotely to those people who are already authorized to
access our system locally.  Of course, you folks are all special ... we want
you to be able to access our system remotely as a demonstration vehicle!  We
think that this approach, coupled with the fact that we are using RSA
encryption/decryption of both login name and password, minimize the security
risks associated with remote Coral.  In fact, when you are running Coral
remotely, you are not actually logged in to a Unix machine in the normal sense
...

So that you may exercise the system, you have each been given "engineer"
privileges on a machine named "bottlewash" ... you will find this machine as
the first name listed under "Wet Benches" in our equipment hiearchy.  As
"engineers" of that machine, you may do all of the things that normal users
can do: make reservations, enable/disable it, write up a problem or shutdown
condition, etc.  Additionally, you can also clear a problem or shutdown ...
which is something that, normally, only maintenance staff or enginners are
allowed to do.  Note: "bottlewash" is a real piece of equipment ... but it
isn't normally enabled/disabled by real users.  I've instructed our staff to
ignore any problem/shutdown conditions.  Additionally, you will notice that
you have all been assigned to work on a project "Demo Only" that charges to
account "Demo Only" ... in that way, you can use and reserve the bottlewash
without impacting our monthly billing or equipment usage statistics.
Note: normally all problem/shutdown submissions or problem/shutdown clear
events will send out e-mail to the maintenance/engineers of that piece of
equipment ... a mailing list named bottlewash-pcs at snf.stanford.edu (the -pcs
stands for problems/comments/shutdowns).  As this list does not exist, you
will receive a notification that that e-mail bounced if you do any
problem/shutdown activities.  We felt that it was less of a nuisance to the
person who submitted the event to get a single "bounced mail" message ...
rather than all of you getting an e-mail message each time one of us was
exercising the system.  Since you are only authorized to "use" bottlewash, you
won't be able to actually make/delete reservations or enable/disable any other
pieces of equipment in our laboratory ... you will, however, be able to look
at reservations and equipment usage history on all pieces of equipment.  This
is all "live" data ... this is the real production database that you are
connected to.

I will shortly send a follow-on message with instructions as to how do
download and run Remote Coral.  If I remember correctly, I had previously sent
each of you a Word document that describes Coral functionality and how to use
the system.  If I didn't send you one, or you would like another, please let
me know.

Thanks for your attention.  If you have any comments, suggestions, or feedback
related to what you see when you exercise Remote Coral, you may contact us by
sending e-mail to coral at snf.stanford.edu.

Contact me direclty with any questions, to get your remote password, etc.

Thanks,

John
shott at snf.stanford.edu
650 725-3715



More information about the coral mailing list