[kepler-dev] Kepler Alpha2 Installer Problems

Edward A Lee eal at eecs.berkeley.edu
Mon Sep 20 20:28:18 PDT 2004


At 09:52 AM 9/20/2004 -0700, Dan Higgins wrote:
>    Shawn's comment and some other discussions bring up some questions 
> that I thought I would post for comments/discussion.
>
>    Ptolemy has an example workflow (Network Integration) where the 
> workflow is a URL rather than a local file. This allows one to post 
> workflows anywhere on a network. But as I understand MOML, this only 
> works for composite workflows; i.e. XML/MOML descriptions. Each workflow, 
> when executed, is ultimately broken down  into atomic actors, written in 
> Java and executed by calling the LOCAL class loader. In other words, 
> there is no mechanism for using remote atomic actors. Is that correct?
>
>    So, do we want to have a remote classloader for Kepler (load a remote 
> atomic actor to the local system), or do we want to execute actors 
> remotely and just transfer input and output tokens? (both?/neither?).

We've thought about doing this, but there several alternatives
that offer real advantages from a security perspective.  Under
the current mechanism, all the Java code executed is locally defined.
In principle, locally defined code can be trusted (modulo bugs).
Thus, it is really easy to create a Ptolemy II configuration that
grants only very specialized authority to models that you execute
from the web...  This may not be as much of an issue in a closed
circle with authenticated and signed access, but to open things up
more, it becomes really big issue.

Also, it seems that the advantages of remotely loading Java code
are not that great.  Installing a signed jar in your classpath
is pretty easy (and could be made pretty transparent using WebStart),
so it seems that weakening the whole security model to provide only
very marginal improvement in capability is questionable...

Yang and I have been working on a very interesting scheme that
involves replicating models on distributed machines, with what
seem to be very strong security guarantees. You could, for example,
export a service that provided very well-defined, limited access
to a database, where access to the database would appear to the user
as if carried out by a locally executing actor. But the means by which
the database is accessed could be entirely hidden from the end user.
The design is still very raw, but if someone is interested in
working with us on this, it would be great to get more bandwidth
and ideas.

Edward


------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal




More information about the Kepler-dev mailing list