Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS The AVM Model Elements of the AVM Model Related and Future Work

Rex Young can be reached at rex@fastmessenger.com. His blog is at http://www.java.net/blogs/rexyoung/.

Object-oriented programming has been at the center of mainstream software development since the early 1990s. Although OOP languages have evolved, the OO model foundation hasn't changed much. OOP is still deeply rooted in sequential programming within a single address space in the following ways:

• Objects are related and linked by references. This tightly coupled relationship is based on the assumption that all objects are in the same address space.
• Objects interact with each other by synchronous method invocations. The caller's thread of control always steps inside the callee. Although the OO model says that an object encapsulates data and behaviors, the object does not have any control over who would execute a behavior and when. Thus objects actually encapsulate the definition of the behaviors rather than behaviors themselves. This makes an object just a stop for a thread to reach into, do something, then get out of in a sequential route through which the thread executes.
• OOP uses threads as its concurrent model. Multiple threads are used to execute the different parts of an OO program concurrently. Such a program may be abstracted as multiple sequential thread routes over collections of objects. This concurrent model adds extra semantics for a programmer to handle. On the one hand, at design level this model adds a new dependence of the design of thread routes to objects besides their own data and behaviors. On the other hand, at programming level it adds handling interleavings to the programming of the objects when they sit on a route where multiple threads cross. This kind of programming in non-trivial programs is incomprehensible to humans and cannot and should not be trusted, as Edward Lee concluded [Lee 2006].
• The OO model suggests modeling live, real-world entities using active objects [Booch 2007]. In this approach an active object is defined as an object with its own thread of control. Unfortunately, active objects do not change the abstraction that programs may be viewed as multiple, sequential thread routes over collections of objects. Non-active objects remain passive, and even active objects are forced to be passive when they are on the thread routes of other active objects.

Currently, several forces are pushing OOP and its foundations to overcome their limitations and be ready for highly concurrent and distributed systems. These forces include evolving hardware (e.g., multicore processors), increasing complexity of programming languages, and increasing level of expectation of new and growable software [Grogono 2008].

Despite the limitation, the OO model has proven to be a unifying concept in computer science [Booch 2007]. For this reason, I decided to leave the OO model untouched for computations (at which it is good) and add a component-based coordination model called the "Actor Virtual Machine" (AVM) as a new extension. A coordination model is the glue that binds separate computations into an ensemble [Gelernter 1992].

The AVM model brings to the OO model message-passing concurrency, which is the basic framework for multi-agent systems, the natural style for a distributed systems, and lends itself well to building reliable systems [Van Roy 2004]. Moreover, AVM customizes the message passing with a dynamic message-binding mechanism that encourages human interventions (e.g., hot code swapping, adjustable workflow) via visual syntax and tools at run time.

The AVM Model

The core idea behind the AVM model is to introduce an object, called the "AVM object", that forwards messages for objects. Sender objects synchronously invoke methods on the AVM object. The AVM object also synchronously invokes methods on receiver objects, but using its own threads. As a result, sender objects' thread of control never step into the inside of receiver objects. Thus asynchronous message passing is achieved between senders and receivers.

Sender and receiver objects are called actors for the sole reason that they are aware of an AVM object and use it for sending and/or receiving messages. Objects that work with an AVM object other than sending and/or receiving messages are not called actors. The name of actor is borrowed from the Actor Model, but AVM actors do not comply with the Actor Model. For example, AVM actors may carry out computations without receiving an incoming message, are not required to support become command for change of behaviors, etc. [Agha 1986].

The AVM model employs several techniques and elements, from basic to advanced. Code fragments use Java-like syntax for demonstration only. These techniques and elements are designed to be used individually as a utility toolbox or combined as a coordination language, which is based on message-passing concurrency, up to user's choices, where applicable.

Asynchronous Message Passing

Actors interact with each other by asynchronous message passing, which effectively breaks the abstraction that OO programs may be viewed as multiple sequential-thread routes over collections of objects, as asynchronous interaction separates the thread of control among actors.

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

The AVM model introduces an AVM object between a sender and a receiver. First, the sender invokes the AVMObject.send() method, and AVMObject immediately lets the sender's thread return. Then the AVMObject uses its own thread to invoke the receiver. onMessage() method. As a result, the sender successfully sends an asynchronous message to the receiver.

The AVM model requires that messages between a certain pair of sender and receiver arrive at the receiver's callback method in the order they are received by the AVMObject. A sender is required to know the references of the AVMObject and a receiver. The receiver is required to implement the AVMCallback.onMessage().

1 The AVM Model | 2 Elements of the AVM Model | 3 Related and Future Work Next Page

RELATED ARTICLES Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance SEI, Army Team Up on Software Testing Nozzle: Counteracting Memory Exploits		TOP 5 ARTICLES No Top Articles.