Item Subject: Re: Java-supported access via intrinsics to TurboIMAGE info
Alfredo wrote:
>I wrote:
>>Ok, so, like, do you have a spec or something yet?
>
>I know what I want ("to put a man on the moon in x years and to bring him
>back alive" or words to that effect).  Defining the exact detailed specs
>for implementing the ADBC technology is our first step.
 
Ok, then my first question before we start is "why".  I don't question
that being able to get to Image databases from Java would be an
interesting thing, but there are a lot of difficult things to overcome to
do it, and I'm not sure that this is the best thing to be done to provide
web access to 3000s.  Since any system that is able to execute a Java
program is probably going to have a web browser on it too, I think you
might get more mileage out of a good CGI scripting language for the 3000
that has built in Image access.  For example it would probably only take a
day or two to provide an Image extension module for Python, and it already
has all the support for CGI forms processing etc.  With this you could
whip out just about any html forms based application in an hour or two.
All the application would be running on the 3000 under your tight control,
with no danger at all of the user accessing data you don't want him to
have.  No downloading tons of Java classes to the client either.
 
Assuming people want to go ahead with a Java to Image link, here are some
thoughts on the subject.
 
You need to have a separate server on the 3000.  The client will need to
communicate with this server through a communications path other than
http, which means allocating a socket number to this service and dealing
with the firewalling issues that raises (a problem CGI would not have).
 
You need to pick a language to write the server in, and a process model
for it (one server process per client connection, one to many, one to all,
etc.)  There will need to be facilities on the 3000 for starting,
stopping, getting status from the server, etc.  It will probably need to
run as yet another batch job on the system.  Do you want the server to be
stateless (able to be restarted without clients noticing), or be able to
retain chains and current record numbers between calls?
 
You have to decide how the Java client will communicate with the server.
Do you want to talk over a raw TCP socket, or do you want to try to use
one of the distributed object models, etc.
 
The server will need to break apart image records into fields and convert
the data types into types that are compatible with the client.  With Java
this probably means sending all data back and forth in displayable
ASCII format.
 
Locking is a very big issue.  I would recommend a transaction oriented
design where locks are never held from the client.  All requests to the
server would be atomic, getting locks, performing some operation(s), and
then releasing the locks before returning to the client.  Otherwise you
have the problem that the client will crash (or worse he may just scroll
off the web page with your applet on it and it will stop running) and the
server will not find out about it for a relatively *long* time (this is a
standard problem with TCP) and *all* the users of the database may freeze
waiting on the lock to go away.
 
Security is the other big issue, as if any Java application can call the
Image API, then even controlling what data *authorised* users can access
becomes a big deal.  If you have to write as much security definition on
the server as you do Java code on the client for each application then I
don't know that it's worth doing.
 
>You have been talking with Eric Schubert of Notre Dame, I see :-)
 
No, it's just that if you provide a remote API based directly on the
Image intrinsic API then you are giving all the clients the equivalent
access to your database as if you let them use QUERY.  Certainly there
are some customers who have some users who are allowed to use QUERY to
access databases, but I think these are a minority.  Java security is one
way.  It protects the user from a malicious applet, but it doesn't really
do anything to protect your poor applet from a malicious user.  Do you
really want every PC in the world to be able to call Image intrinsics on
your system?
 
>DCE (or acronyms to that effect) would be nice.  But we can't wait for HP
>to implement it (or anything else, for that matter) on the HP3000.  Any
>suggestions for things we can do NOW?
 
I'm not concerned so much with the authentication of the user or with
encryption of the communications channel as I am with controlling what
data the user has access to, so I don't know that DCE would do us that
much good in this area anyway.
 
>We can always leave the 12,000-student issue for the second release :-)
 
Not if it is going to affect the design in a fundamental way.
 
These are most of the *hard* problems.  The actual classes that implement
the object oriented view of Image from the client shouldn't be that hard
to do and rather interesting/fun.
 
G.