[kepler-dev] VNC for 'detached execution' of Kepler?

[Christopher Brooks]

Edward has been talking about migrating code for years.
Security is definitely the hard part.

Just a reminder, Ptolemy II does have a sandbox, try 
vergil -sandbox
See also $PTII/doc/sandbox.htm

Also, ptolemy II can open models that are urls, the network demo does
this.

http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII4.0/ptII4.0.1/ptolemy/moml/demo/Networked/Networked.htm

The sandbox could be adjusted to allow access to remote models.

Having the sandbox have access to remote .class files would be
trickier.  Really, we should use code signed jar files for this.
I think the sandbox can be set up to handle this as well.

Once signed jar files are involved, using the sandbox from a
standalone vergil window and using the sandbox within web start start
to merge.  One issue is that the sandbox in web start is harder to
control.

One tricky part would be to handle reloading .class files.  There 
are various reasons we have not done this, Steve has posted details.
I can see that for long running processes, we might want to
be able to reload .class files.

Also, Steve and I have hacked around with treeshaking, where we run
a model with java -verbose, determine which class files are 
used and then create a jar file with just those class files.

ptII/util/testsuite/treeshake is a nasty script that does some of
this.  When combined with code obfuscation, it is possible to get
fairly small jar files, which is what we used it for with code
generation.


-Christopher


--------
    
    Hi,
    
    Tobin Fricke wrote:
    > 
    > A more ambitious (but cleaner) scheme would be to define a network
    > interface between vergil and ptexecute, so that you could
    > connect/disconnect instances of the GUI (vergil) to running instances of
    > Ptolemy (ptexecute)  on the fly.
    
    And personally I think this is the right way to go, although the VNC 
    trick would work in a limited way now, so might have some benefits over 
    the short term.
    
    In SEEK we've been talking about running various computations as part of 
    a grid, and I've been thinking that we should have ptexecute on each of 
    those nodes (this fits into our REAP proposal too).  Then, a vergil 
    interface on a client machine could be used to design an abstract 
    workflow.  That abstract model would then be analyzed by a scheduler 
    that has knowledge of the nodes on which ptexecute is available to 
    determine which parts of the model should be run on which nodes 
    (optimizing the data transfer/computational power tradeoff).  This 
    produces a concrete model that is to be executed.  The vergil client 
    would somehow need to mediate message passing among the directors 
    running at each ptexecute node, and we would defiitely want to handle 
    direct data flow from one ptexecute node to another without passig the 
    data through the vergil client (we've been referring to this as '3rd 
    party' data transfer).
    
    It could even be extended to allow code migration, by having part of the 
    vergil/ptexecute interface include the ability to transfer jar files 
    that contain all of the code needed to execute a given actor or model -- 
    this jar could then be loaded at runtime by the ptexecute engine.  Of 
    course, this would then imply the need for a strong sandbox and 
    appropriate access controls, but presumably this would be needed in any 
    grid environment.
    
    Matt
    
    
    -- 
    -------------------------------------------------------------------
    Matt Jones                                     jones at nceas.ucsb.edu
    http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
    National Center for Ecological Analysis and Synthesis (NCEAS)
    University of California Santa Barbara
    Interested in ecological informatics? http://www.ecoinformatics.org
    -------------------------------------------------------------------