There are some areas the AVM model that are left undefined, primarily because because there is not a single solution that fits all. Some of them will be left to implementers and some others may need further development of the AVM model.
The current AVM model does not define any thing about messages except tags. A message may be shared, dedicated, mutable, immutable, or any combination of those characteristics. Actor programmers are responsible for making their decisions. However, an actor should specify these decisions as part of actor specification, which assemblers depend on. When a message goes to another AVM object which is either in a different programming language or in a distributed system, compatibility may be solved by an actor-oriented programming style at actor level. For example, a C# actor requires a message, a native Java object, generated by a Java actor. We create a new Java actor that converts a Java message into a string in the format, say, XML. On the C# side, we create a new C# actor that converts a string XML to a C# message. Then we wire them together by adding rules. We have done this without altering the original two actors. Here we are assuming that a Java AVM object may exchange common data types, like strings, directly with a C# AVM object.
This example demonstrates that the combination of untyped message and actor-oriented programming is much more flexible than the combination of typed parameters and method signature.
AVMcallback. The AVM model chooses the callback method (an OO design that is classic and raw for events and messages) as the communication interface between an AVM object and receivers. The model neither suggest nor assumes how a receiver would handle incoming messages. Receivers are free to choose any preferred communication mechanism (e.g., port, queue, multi-threading, etc.).
The AVM model promises that the callback method will be called with messages in the order they are received by the AVM object. By default, the callback method will be called by concurrent threads.
An AVM object may be forced to use single-thread mode for a particular receiver if the receiver indicates this is the behavior it wants. This special arrangement is based on the fact that some programming languages do not guarantee thread scheduling in a heavy multi-threading environment. In such a case, the ordering of threads would be different from the perspectives of the AVM object and receivers because they are at different points in time.
Synchronous Message Passing. The current AVM model optionally supports synchronous message passing, which requires a reply, as a supplemental interaction between actors.
Missed Binding. The current AVM model discards unwanted messages for which no receivers are found.
Peter Grogono nicely outlined two categories of related work that address concurrency. Research within the current framework aims to extend object-oriented languages with abstractions for concurrency. Research that works directly toward a "paradigm shift" aims to bring concurrent languages -- including his Erasmus process-oriented language -- into the mainstream. Refer to Grogono [Grogono 2008] for details.
Here I am listing work related to the AVM model that related to the inspiration of the actor model and message passing, or that simply share something common in concept. Modern embedded systems are composed of subsystems that communicate and interact in various ways. The Ptolemy approach [Eker 2003] addresses the issues by a hierarchical composition, and a semantic framework called a model of computation (MoC). In the model, the actor is a basic building block that is hierarchically composite. A subsystem, aka MoC, may be modeled and encapsulated by a tree of actors. The composite actor that associates a MoC is called a domain. Because actors are controlled by their parent composite actor in terms of execution, a subsystem is well contained and separated from others.
The Ptolemy model and the AVM model have many characteristics in common: They both use concurrent and independent actors as building blocks, an actor is not forced to have its own thread of control, and actors are composable. Both are coordination languages with visual syntax. However, there are some differences. The Ptolemy model has more control over the hierarchical structure and how an actor executes to best model different domains.
While the AVM model gives actors more freedom in terms of how they are executed, how they handle incoming message, and a flat structure among actors. SEDA [Welsh 2001] is a particular software architecture. It creates a queue associated with a thread pool for a certain task. A thread from the pool reads a request in the queue and performs the task with the request. The AVM model does not completely hide threads from programmers. They are similar in that they share the concept of reducing the scope of threads.
Kilim is an actor framework for Java [Srinivasan 2008] that focuses on high performance and high capacity (e.g., message passing is three times faster than Erlang and a million ultra-lightweight threads). The Kilim approach is obviously different from the AVM model, which emphasizes incremental influence over sequential programming. I do see the possibilities and benefits of using Kilim when the AVM model evolves.
The AVM model is not very concerned with performance in practice. A system containing hundreds of thousands of objects many only have tens or hundreds of actors. Not every object needs to be active and independent as Herb Sutter and James Larus pointed out [Sutter 2005].
The Actor Architecture (AA) is an actor-based agent framework in Java [Jang 2004]. The AA uses a message manager to forward messages between senders and receivers. And it gives each actor a Universal Actor Name (UAN). ACT++ 2.0 is Dennis Kafura's early work on implementing an actor library using C++ [Kafura 1992]. Both the AA and the ACT intend to realize the Actor model. For example, they focus on implementation of primitives (e.g., behaviors, replacement behaviors, etc.) in the Actor model.
Conclusion and Further Work
Some good concurrent models (e.g., message passing) and good programming languages (e.g. Erlang) have been around for a long time, but have never even been in the sight of the mainstream software development. The message is clear. We should not replace established languages because programmers are reluctant to accept new syntax [Lee 2006]. It does not mean that programmers have a negative attitude toward changes, but that they have their own way of changing. Smalltalk was much more OO than C++, but today it has gone and C++ remains in the mainstream simply because of C++'s winning attitude: I add OO features to C, and you use them when you need. On the other hand, Smalltalk made even integers classes: I am pure OO, technically correct, you should use them as I said.
The AVM model takes C++'s approach. First, it clearly stays away from doing computation, which is the part OOP is good at. And it intends to work with any existing OO programming language. Second, it is used on a "as needed" basis and is 100% compatible with OOP. An AVM object is an object. An actor is also an object. An actor may use method invocation with objects and message passing with actors at the same time. A program may consist of 99% objects and 1% actors, or vice versa. Third, the AVM model makes itself familiar to programmers as if it is one of the existing mainstream techniques (e.g. callback method, event-driven programming, enterprise queue, enterprise messaging, publish-and-subscribe, Web Service, Service-Oriented Architecture, enterprise service bus, etc.). Last, it turns the natural features of message passing into desired features to attract programmers. For example, it offers visual syntax and tools for run-time manipulation to achieve adjustable work flow, hot code/host swapping, etc.
I believe the AVM model will gain wide acceptance by mainstream programmers. It will eventually help programmers get ride of sequential thinking and programming in a long run. From there, they would be ready to accept better technologies.
There is a lot of work to be done. The model and visual syntax need fine tuning. Solid reference implementation and tools need to be developed. Specifications that address compatibility over hosting programming languages need to be created. And more important, common design patterns for actor-oriented programming need to be found.
[Agha 1986] Gul Agha. Actors: A Model of Concurrent Computation in Distributed Systems. The MIT Press, 1986.
[Booch 2007] Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J Young, Jim Conallen, and Kelli A. Houston. Object-Oriented Analysis and Design with Applications, Third Edition Addison-Wesley, 2007.
[Eker Johan] Eker, Jorn W. Janneck, Edward A. Lee, Jie Liu, Xiaojun Liu, Jozsef Ludvig, Stephen Neuendorffer, Sonia Sachs, and Yuhong Xiong. Taming Heterogeneity: The Ptolemy Approach. Proceedings of the IEEE, January 2003.
[Faison 2006] Ted Faison. Event-Based Programming: Taking Events to the Limit. Apress, 2006.
[Gelernter 1992 David Gelernter and Nicholas Carriero. Coordination Languages and their Significance. Communications of the ACM, February 1992.
[Grogono 2008] Peter Grogono and Brian Shearing. Concurrent Software Engineering: Preparing for Paradigm Shift. Canadian Conference on Computer Science and Software Engineering, May 2008.
[Jang 2004] Myeong-Wuk Jang. The Actor Architecture Manual. March 2004. http://yangtze.cs.uiuc.edu/aa/AAM.pdf
Kafura 1992] Dennis Kafura, Manibrata Mukherji, and Greg Lavender. ACT++ 2.0: A Class Library for Concurrent Programming in C++ Using Actors. Virginia Polytechnic Institute & State University, January 1992.
[Lee 2006] Edward A. Lee. The Problem with Threads. IEEE Computers, May 2006.
[Srinivasan 2008] Sriram Srinivasan and Alan Mycroft. Kilim: Isolation-Typed Actors for Java (A Million Actors, Safe Zero-Copy Communication). Proceedings of ECOOP, 2008.
[Sutter 2005] Herb Sutter and James Larus. Software and the Concurrency Revolution. ACM Queue. September 2005.
[Van Roy 2004] Peter Van Roy and Seif Haridi. Concepts, Techniques, and Models of Computer Programming. The MIT Press, 2004.
[Welsh 2001] Matt Welsh, David Culler, and Eric Brewer. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services. SOSP-18. October 2001.