Workflow as a Portal Actor

[jspenger]

In our original vision we outlined a Workflow to also function as a Portal Actor [1]. That is, besides being able to have Tasks as Portal Actors, it would also be interesting to have an entire workflow correspond to a Portal actor. I will call these Portal Actors for now, but they may also be called Entities, or Askers/Repliers in other documentation.

The correspondence between a Portal Actor and a Workflow, in this case, is the following:

• The Portal Actor has a set of inputs (references it receives from), and a set of outputs (references it may send to). The Portal Actor owns its inputs references (single owner), the outputs are owned by the corresponding receiving Portal Actors.
• The Workflow corresponding to this, has a set of incoming streams (it consumes from streams from which it is the only consumer), and has a set of outgoing streams (the outgoing streams are connected to the sequencers of the receiving actors). Internally, the processing is data-parallel, and also task-parallel, as the entire actor may internally form a dataflow graph. A message receive corresponds to receiving a message on one of the incoming stream sources. A messag send corresponds to emitting a message on one of the sinks.

This would be an interesting extension for our follow-up release. It may rely on the existence of Ports. It is not suitable for the first release 0.1.0.

Ask @jonasspenger for more information.

[1] Jonas Spenger, Paris Carbone, and Philipp Haller. 2022. Portals: An Extension of Dataflow Streaming for Stateful Serverless. In Proceedings of the 2022 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! 2022). Association for Computing Machinery, New York, NY, USA, 153–171. https://doi.org/10.1145/3563835.3567664