Actor model

Ken Webb 2010-04-12T21:18:27Z

The Actor Model is "a mathematical model of concurrent computation that treats 'actors' as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received".

Xholon can be thought of as an implementation of the basic concepts of the Actor Model, as described in the Actor literature. Although Xholon does not attempt to be a mathematical model and is not defined formally, it does provide a light-weight framework for concurrent execution of xholons (objects) without the use of threads. A xholon is an equivalent "universal primitive", that is inherently able to exchange asynchronous messages with other xholons.

The Fundamental concepts section in the wikipedia article can be paraphrased as the following correct but incomplete description of Xholon.

Actor Model paraphrased as a description of Xholon

The Xholon model adopts the philosophy that everything is a xholon. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Xholon model is inherently concurrent.

A xholon is a computational entity that, in response to a message it receives, can concurrently:

There is no assumed sequence to the above actions and they could be carried out in parallel.

Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages.

Recipients of messages are identified by address, sometimes called "mailing address". Thus a xholon can only communicate with xholons whose addresses it has. It can obtain those from a message it receives, or if the address is for a xholon it has itself created.

The Xholon model is characterized by inherent concurrency of computation within and among xholons, dynamic creation of xholons, inclusion of xholon addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.

Discussion of the paraphrase

In a Xholon application, all Java objects must implement the IXholon interface. Everything is a xholon.

In a traditional sequential Java application, instances of one class call methods on instances of other classes. Xholon instances can also directly call methods of other xholons. But more typically, xholons send asynchronous messages, that are placed in a message queue, and asynchronously delivered to the receiving xholon for processing.

Xholon designates future behavior by using state machines. A received message may change the state of the xholon, and cause a different behavior when processing the next received message.

Xholon doesn't use the term "address" or "mailing address". The Xholon equivalent is "port" which directly specifies some other xholon. The xholon that is the target of a port can be determined at runtime by various means. It can be specified in an XPath expression, or the xholon can directly navigate the composite structure tree, or a xholon can send a message to a xholon that has sent it a message, or it might receive a reference to a xholon as part of a received message from some other xholon.

Unlike the Actor Model, Xholon does not restrict itself to using only asynchronous messages. However, synchronous messages and direct method calls must be actioned in a timely manner so as not to block further processing. In a Xholon application, an arbitrarily large number of xholons can all run on the same thread.

Xholon and the Actor Model

There is a large literature on the Actor Model, and on related formalisms. This wiki article has only made an initial start in investigating how Xholon is similar and how it is different.

Xholon aspires to have no arbitrary restrictions, while the Actor model specifies certain well-defined restrictions. The Actor model could possibly be defined as a set of restrictions on Xholon, restrictions which can be beneficial in certain domains. One such domain is the area of security as described by Mark Miller in his PhD dissertation entitled Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.

return to main page