Channels ▼
RSS

Parallel

Actor Virtual Machine


Identification

Each actor may have a unique identity, in the scope of the associated AVM object, so that sender may refer to receiver by identity rather than by reference, which breaks the assumption that all actors are in the same address space.

In the AVM model, asynchronous message passing replaces method invocations, which pass data as typed parameters, with messages, which are untyped data. It is difficult for the receiver to find out the data type, format, and semantics of a message. For this reason, each message may have a tag that indicates the data type, format, and semantics of the message. The message tag is designed to identify the type of messages rather than individual messages.


class AVMObject
{
  void registerReceiver(String receiverId, AVMCallback receiver);
  void send(String receiverId, String msgTag, Object message);
}
interface AVMCallback
{
  void onMessage(String msgTag, Object message);
}

A receiver is required to register with AVMObject either by itself, by another actor, or by any other object in the program.

Dynamic Message Binding

The AVM model is designed to be an actor-based coordination model, which requires the actor to be as independent as possible and the message to be bound with the receiver as late as possible to achieve the maximum flexibility of gluing actors together, and maximum human interventions at run time.

For this reason, the AVM model requires the actor to completely focus on its internal computations that map evolving incoming messages (bit pattern) to evolving outgoing messages (bit pattern), which is the basic formulation of many concurrent models [Lee 2006]. This further decouples actors from knowing each other. The AVM model introduces rules for binding message and receiver, which occurs when a message is received by AVMObject.send(). This rule-based dynamic binding provides publish-and-subscribe style of message passing.


class AVMObject
{
  void registerReceiver(String receiverId, AVMCallback receiver,
                        String[] receiverMsgTags);
  void registerRule(String senderId, String senderMsgTag,
                    String receiverId, String receiverMsgTag);
  void send(String senderId, String senderMsgTag, Object message);
}
interface AVMCallback
{
  void onMessage(String receiverMsgTag, Object message);
}

A message tag is meaningful in the scope of the associated actor. It is the assembler's job to determine whether a senderMsgTag and a receiverMsgTag refer to the same data type, format, and semantics. The tags themselves are not necessarily to be the same. Please note that an assembler is a programmer who works in the coordination model to design the relationship of actors and to link and adjust actors by manipulating rules at run time via visual syntax and tools.

Standalone AVM Object

An AVM object may be used beyond a utility toolbox as a fully functional container of actors. This is where the name "actor virtual machine" comes from.

  • First, an AVM object may provide a thread of control for all actors, including both senders and receivers. Receivers gain a thread of control when a message has arrived by the callback method. Senders may gain a thread of control when loaded by an AVM object. An AVM object also provides timer-like service so that an actor may regain a thread of control when a predefined condition is met. Of course, objects and/or actors may always use their own private threads as part of their computations.
  • Second, an AVM object may manage the full lifecycles of individual actors, including loading and unloading actors from classes, passing in and retrieving configuration and state, starting and stopping, etc. When queried by an AVM object, an actor is responsible to tell what message tags it offers to send, and what message tags it is interested in receiving. An actor may be a both sender and receiver. By telling the AVM object two lists of message tags, an actor has just declared its interface: a list of incoming message tags and a list of outgoing message tags.
  • Third, an AVM object may record the current configuration and state of all its child actors to external persistence, and retrieve them to restore to the previous state. Thus all information from human interventions would not be lost when a program crashes and/or restarts.

An AVM object is fully manageable. All of its functions are disclosed as methods divided into two categories: management methods and send methods. An invocation, plus associated parameters, in such a method is called a request to the AVM object. Any object, including actors in the program, may access all methods of an AVM object. Visual syntax and tools may be implemented this way.

Nested AVM Objects

Unlike an object, the actor's interface is not specified by its methods. Actor is object, though, in terms of the physical form. In the AVM model, actor's interface is specified by a list of message tags it is interested in receiving and another list of message tags it offers to send. This makes actors naturally composable. The steps below demonstrate how to composite a group of well-wired actors into a facade actor as the Facade pattern suggests:

  • First, we know that all message tags of the interface of the facade actor must come from actors in the group, so that the first step is to identify these message tags and actors.
  • Second, introduce the new facade actor, and define its interface by message tags identified in the first step.
  • Third, add rules to forward messages in both directions between the facade actor and child actors identified in the first step. As a result the facade actor is built.

An AVM object may turn itself into a facade actor of its child actors by nesting itself as an actor associated with another AVM object. Configuring message forwarding for the nested AVM object is done in the same way as configuring port forwarding for a home network router.

The nested-AVM-object approach has several advantages over the approach that uses a facade actor:

  • First, it is worth providing a standard solution because composition is fundamental in actor-oriented programming.
  • Second, all messages between child actors become internal.
  • Third, this approach provides encapsulation of child actors.
  • And last, AVM object has built-in functions like configuration, persistence, etc. for easy management.

Networked AVM Objects

Connecting multiple AVM objects together forms an enlarged and unified address space for all actors associated with these AVM objects, which may cross distributed systems and/or different hosting programming languages. The only change from the assembler's perspective is to specify an actor using its full format form of identity (e.g., acmObjectId:actorId for actors that are not associated with the same AVM object).

The AVM model defines two types of connections: direct and indirect. When two AVM objects get connected, they exchange information about existing connections they have and update every AVM object connected with the information about new connections. So that every AVM object is aware of other AVM objects, and is able to find a direct connection that will lead to a given AVM object. The same process repeats until the given AVM object is reached as a direct connection.

The AVM model requires each AVM object to be proxy for all other connected AVM objects. When AVM object X receives a request, aka as method invocation plus parameters, specified as applied to Y, it finds a direct connection at Z, which leads to Y, and forwards the request, in the form of an internal message, to Z. The same process repeats until the request reaches Y.

Between two remote actors, message binding takes an extra step -- AVM object binding. The AVM model introduces management of message binding and routing at AVM object level for networked AVM objects. For example, an assembler may tell all AVM objects to substitute "AVM A" with "AVM B." As a result, all messages that are supposed to be sent to actors in "AVM A" will actually be sent to actors, with the same ids, in "AVM B".

Visual Syntax

Figure 1 is inspired by the "Signal Wiring Diagrams" found in [Faison 2006]. It consists of two major notations for actor and message flow:

Figure 1: Actor diagram of a temperature monitoring system .

The actor notation is a rectangle with actor id at the top. Message tags as actor's interface are listed in the lower part. There is a tag name and directional pin to represent a message tag. The message-flow notation is a line linked to a sender and a receiver at proper message tags. This notation indicates that messages flow from the outgoing pin to the incoming pin. It also implies a message-binding rule underneath. The actor diagram is designed to be used at both design and run time.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video