Triquetrum/Actor Oriented Classes

Implementing and using Actor Oriented Classes in Triquetrum

Ptolemy II [1] models define actor assemblies that can be executed in different Models of Computation.

Actors can be implemented in different ways. Most Ptolemy II actors are implemented in Java, but other languages like JavaScript, Python, C have also been used. A different approach is to implement actors as composites of contained actor assemblies, or as "submodels". These are called "Actor Oriented Classes" [2].

In Ptolemy II's Vergil model editor, existing AOC implementations can be handled in a similar way as "programmed" actors. Ptolemy II is able to load both Java-based actor classes and MoML-based AOCs from the classpath, show them in the actor palette/library, let users drag-n-drop them on a graphical model canvas, connect ports, configure parameters etc.

AOCs can also be created using Vergil and can then be shared between "consumer models", either via the concept of a "User library" or by adding them to the classpath (e.g. by adding them in the Ptolemy II build or by copying them on the root installation folder). There is no explicit tool support to share models between multiple users.

With issue #78, the goal is to implement support for AOCs in Triquetrum.

This requires some reflection on different levels :

1. How can we create AOC models? E.g. first designing a plain model and then mark it somehow as a "reusable AOC"? Or should this be a specific wizard/workflow in the editor upfront?
2. Where do we store AOCs so they can be used for designing and running "consumer models"? Linked to this, how can we share them easily between models and with other users?
3. How to represent AOCs within parent/consumer models? Vergil shows a customizable actor icon and via an "Open actor" action the user can see the internal details of the AOC model in a separate editor window.In Graphiti it's not straightforward to navigate between diagrams/windows from a parent model. This is related to the tight integration between diagram editors and underlying EMF resources. Kieler/ELK use another paradigm where they expand/collapse the contents of a submodel within the same diagram (minimizing the remainder of the surrounding model).
4. Do we want to support the difference between AOC classes and instances, similarly to Ptolemy II? And if so, also subclassing and other advanced features related to using AOCs in Ptolemy II?

The work will be done in several steps :

1. Add support for using existing AOCs in the Triquetrum editor. At this stage we depend on using Vergil to implement AOCs.
   1. include AOCs in the editor palette configuration
   2. define a common approach for storing/loading AOC classes for the editor and for a headless workflow runtime
   3. always use instances when adding AOCs to a model (similar to Java-based actors picked from the palette)
   4. simple representation of an AOC in a model with similar configuration options as for a Java-based actor
   5. figure out a way to dynamically add AOCs to an existing Triquetrum installation
   6. extend this to allow opening the AOC model details in a readonly view
2. Add support for creating AOC models in Triquetrum
   1. graphical models and DSLs?
   2. AOCs defined within a parent model or only as separate models, meant to be used as "reusable submodels"?
   3. classes, subclasses, instances?

Using existing AOCs in Triquetrum

Ptolemy II has been prepared for using it in an OSGi context (such as Triquetrum). This already provides an API and implementation to load AOCs in a similar way as Java actor classes, by plugging in the org.ptolemy.classloading.osgi.OSGiClassLoadingStrategy as the implementation of org.ptolemy.classloading.ClassLoadingStrategy.

Both Ptolemy's ptolemy.moml.MoMLParser and Triquetrum's editor utilities use the ClassLoadingStrategy approach to find actor classes.

The OSGiClassLoadingStrategy implementation tracks all registered OSGi services that implement one of two interfaces :

• org.ptolemy.classloading.ModelElementClassProvider : provides Java actor classes from OSGi bundles. Implementations are already available and used for providing the default actor library and to allow easy addition of new actors to a Triquetrum editor/runtime (see also https://wiki.eclipse.org/Triquetrum/Extending_Triquetrum)
• org.ptolemy.classloading.ActorOrientedClassProvider : no implementation yet. This needs to be done to get a first level of AOC support working in Triquetrum.

The first step for supporting AOCs in Triquetrum involves :

• implementing an ActorOrientedClassProvider that is capable of loading existing AOC implementations
• making these AOCs available to the Triquetrum editor via the palette configuration
• ensuring that a model designer can use AOCs in the same way as Java-based actors
• ensuring that such models also execute correctly

The first AOCProvider implementation is based on finding AOCs via the WorkflowRepositoryService. We'll integrate the org.eclipse.triquetrum.workflow.repository.impl.filesystem.WorkflowRepositoryServiceImpl that uses the local filesystem to store/load models for this first implementation.

Integrating this file-based repository in the editor is a good trigger to provide a first preferences page, to be able to configure the root folder of the repository (cfr issue #183). We've followed the clean approach described by Philip Wenig on the OpenChrom blog (thanks!) to work with preferences in a consistent manner [3].

[1] http://ptolemy.eecs.berkeley.edu/ptolemyII/

[2] http://ptolemy.eecs.berkeley.edu/publications/papers/04/Classes/Lee_Classes.pdf

[3] https://openchrom.wordpress.com/2014/01/11/how-to-handle-preferences-consistently/