# Presentation: 281038

## LQCD Workflow Project

- L. Piccoli
- October 23, 2006

- Kepler slides of Kun Xiao (kxiao3@iit.edu)

## Actor-Oriented (A-O) Design in SWF

- Borrowed from the *.ppt slides by
- Edward A. Lee (See References)

-   Object orientation:

-    Actor orientation:

- actor name

- data (state)

- ports

- Input data

- parameters

-          Output data

- What flows through an object is streams of data

- October 2 2006

**Notes:**
A-O is closer to the real world.

## Model of Computation (MoC)

- Semantic interpretations of the abstract syntax
- Different models <=> Different semantics <=> Different execution

-  Are actors active? passive? reactive?
-  Are communications timed? synchronized? buffered?

- Borrowed from the *.ppt slides by
- Edward A. Lee (See References)

- _Models of Computation:_
-  continuous-time
-  dataflow
-  rendezvous
-  discrete events
-  synchronous
-  time-driven
-  publish/subscribe
- ...

- October 2 2006

## An Actor-Oriented Workflow

- October 2 2006

**Notes:**
A wf is abstracted to an actor, an actor is refined to a wf.

## What is Kepler

- An open source project
- Build on Ptolemy II
- Kepler is a software application for the analysis and modeling of scientific data.
- Create executable scientific workflows by simply dragging and dropping components.

- October 2 2006

## Strength of Kepler

- Concurrency and communication between components
- Separates two modeling concerns: component *communication *(dataflow) and overall workflow *coordination *(orchestration).

- October 2 2006

**Notes:**
A-O is for concurrency.
This hugely improves the reusability of actor designs.

## Basic Components in Kepler

- Directors
- Actors
- Parameters
- Ports
- Relations

- October 2 2006

## Software Architecture of Ptolemy II

- October 2 2006

**Notes:**
The kernel defines a small set of Java classes that implement a data structure supporting a general
form of uninterpreted clustered graphs, plus methods for accessing and manipulating such graphs.

## Anatomy of an actor in Kepler

- public class ***ActorClassName*** extends BaseClass implements MarkerInterface {
- 	public ***ActorClassName ***(CompositeEntity container, String name) throws
- 	NameDuplicationException, IllegalActionException {
- 	  super(container, name);
- 	  // Create and configure ports, e.g. ...
- 	  portName = new TypedIOPort(this, " portName ", true, false);
- 	  // Create and configure parameters, e.g. ...
- 	  parameterName = new Parameter(this, " parameterName ");
- 	  parameterName.setTypeEquals(BaseType.DOUBLE);
- 	}
- 	//// ports and parameters ////
- 	public ***TypedIOPort*** portName;
- 	public ***Parameter*** parameterName;
- 	...

- October 2 2006

**Notes:**
1.When a director starts a workflow execution, it invokes the preinitialize method of all actors. 
2.possible actions during execution of initialize are: Web service actors can “ping” the web services
   they represent and signal failure-to-initialize if the corresponding service is not alive.
3. A workflow execution will often consist only of one run, but if a workflow is re-run, initialize is called again. A run
   usually includes multiple iterations, each of which includes a call to prefire, fire, and a call to postfire.
   The main actor operation finally happens in the fire method, e.g., a web service actor will make the actual remote service call here.
4. The Executable interface, shown in figure 2.12, is implemented by the Director class, and is extended by the Actor interface. An actor is an   executable entity.
5. An iteration is defined to be one invocation of prefire(), any number of invocations of fire(), and one invocation of postfire().
6. the fire() method of the director selects an actor, invokes its prefire() method, and if that
returns true, invokes its fire() method some number of times (domain dependent) followed by its postfire()
method. In figure 2.15, the fire() method of the director invokes the prefire() method of all the
actors before invoking any of their fire() methods.

## Anatomy of an actor in Kepler

- 	//// public methods ////
- 	public void ***fire***() {
- 	  ...read inputs and produce outputs...
- 	}
- 	public void ***initialize***() {
- 	  ...initialize local variables...
- 	}
- 	public boolean ***prefire***() {
- 	  ...determine whether firing should proceed and return false if not...
- 	}
- 	public void ***preinitialize***() {
- 	  ...set port types and/or scheduling information...
- 	}
- 	public boolean ***postfire***() {
- 	  ...update persistent state...
- 	  ...determine whether firing should continue to
- 		next iteration and return false if not...
- 	}
- 	public void ***wrapup***() {
- 	  ...display final results...
- 	}
- }

- October 2 2006

**Notes:**
1.When a director starts a workflow execution, it invokes the preinitialize method of all actors. 
2.possible actions during execution of initialize are: Web service actors can “ping” the web services
   they represent and signal failure-to-initialize if the corresponding service is not alive.
3. A workflow execution will often consist only of one run, but if a workflow is re-run, initialize is called again. A run
   usually includes multiple iterations, each of which includes a call to prefire, fire, and a call to postfire.
   The main actor operation finally happens in the fire method, e.g., a web service actor will make the actual remote service call here.
4. The Executable interface, shown in figure 2.12, is implemented by the Director class, and is extended by the Actor interface. An actor is an   executable entity.
5. An iteration is defined to be one invocation of prefire(), any number of invocations of fire(), and one invocation of postfire().
6. the fire() method of the director selects an actor, invokes its prefire() method, and if that
returns true, invokes its fire() method some number of times (domain dependent) followed by its postfire()
method. In figure 2.15, the fire() method of the director invokes the prefire() method of all the
actors before invoking any of their fire() methods.

## Kepler

| Language | Java |
| --- | --- |
| GUI | Yes (Vergil ) |
| WF Representation | MoML (modeling markup language–an XML description of a Kepler workflow) |
| Concurrency control | Yes (e.g. in PN MoC) |
| Web services | Yes |
| Fault Tolerance | No |
| QoS constrains | No |
| Grid-based services | Yes |
| Job scheduling
 | Yes (using external applications, which are wrapped as commandline actors) |
| Data/Control dependency | Yes |

- October 2 2006

**Notes:**
Ptolemy can deal with actors scheduling. Job scheduling aims to balance load here.