Welcome to the official site of the fast messenger project.

Fast messenger

The Fast Messenger (FM) project promotes a new programming model that acts as an improvement, supplement, add-on or plug-in to OO programming model. As a proof of concept the FM project also provides reference implementations in popular OOP languages like Java, C# and JavaScript. Thus, allowing developers to immediately do a hands-on experiment.

Because the OO model did not have concurrency in mind as it was being designed. It has been forced to adopt threads and locks in order to take advantage of modern CPUs and OSs. Since they do not naturally fit into the OO model, thread concurrency creates some problems.

First, the ways of programming with threads are inconsistent on different OO languages and platforms. OO languages like Java and C# have built-in support for threads while others like C++ and JavaScript do not have a standardized way of programming with threads. And furthermore, Java and C# utilize multiple threads that share a public memory while each of JavaScript’s threads has its own private memory.

Second, thread context is an invisible design constraint to objects where thread concurrency happens. Thus, these objects are more difficult to be reused and applications built by these objects are less flexible to future changes and extensions.

Even if you chose a specific OO language and did not care about your application’s future maintenance, it is still too hard to program correctly with non-trivial concurrent objects and the difficulties of debugging and testing them.

The FM model addresses the weakness of the OO model on concurrency by hiding explicit use of threads, forbidding direct function invocations, and injecting independent execution into selected objects. These selected objects are called active objects. They are usually filled with business logic and implemented by application developers. The other type of objects introduced by the FM model are called messenger objects and usually provided to application developers by tool vendors who implement the FM model.

An active object must be registered with a messenger object and can only be indirectly invoked by passing it messages via the messenger. Following Java code snippet gives a quick idea how the FM model looks like in source code. (The code snippet is for illustration purpose. Please refer to other sections on the site for API details that tell what you can use, and design patterns that demonstrate how you can organize active objects together to solve typical concurrent problems.)

// run within a single-threaded context
class UserObject {
    void functionA (Object... msgParameters) {
        // business logic
    }
    void functionB (Object... msgParameters) {
        // business logic
    }
}
Messenger messenger = new Messenger();
UserObject objectImpl = new UserObject();
messenger.register(objectImpl, "objectId", "functionA", "functionB");
messenger.send("objectId", "functionA", msgArgs);

Tool vendors will provide a Messenger class. Application developers will implement business functions in a plain UserObject inside of which the messenger guarantees a single-threaded context at runtime. During registration, each active object will be given a name which is unique in the namespace of the messenger.

No objects other than messenger objects are allowed to directly invoke a function on an active object. In order to invoke a function on an active object, a caller object has to invoke messenger.send() instead with the ID of a callee active object, function name, and parameters. Thus, caller and callee objects are also referenced as sending and receiving objects.

Note: Hybrid objects are a combination of regular and active objects that can are accessed by other regular objects and messenger objects. Thus, there is no guarantee of single-threaded context. Hybrid objects are not completely forbidden in the FM model. With care, hybrid objects might be useful in practice.

Although the FM model has borrowed important concepts from the actor model and message passing, it is designed based on following principles, in order to work with the OO model and be used by mainstream OO application developers.

• The OO model is still the foundation and regular objects are still the majority in most of the OO programs.
• The FM model is used to handle concurrency by replacing concurrent objects with active objects.
• Active objects could be as simple as POJOs or POCOs, and their executions are independent to each other.
• Overall gains of performance and concurrency are collectively achieved by a number of active objects.
• The FM model introduces no new syntaxes or annotations, and could be implemented in any language that supports the OO model as an add-on feature.

As a result, the FM model has following ingredients.

• Active object, which is represented by its ID rather than reference.
• Messenger object, which is supplied by tool vendors.
• Any object, either a regular or active object, can indirectly invoke a function with parameters on an active object ID.
• Active object is single-threaded, thus, it handles messages one at a time. Adding more active objects will increase the capacity of handling large number of messages at the same time.
• Multiple ways of addressing receiving active objects.
  • Sending object specifies the ID of receiving active object.
  • Sending object specifies the ID of self, and lets the messenger dynamically determine receiving active objects depend on routing rules at runtime.
• Multiple ways of returning results.
  • By default, all messages are one way. In order to obtain result, two messages are required. A first message carries a request from sending object to receiving object, and a second message carries the result from the receiving object back to the sending object.
  • Optionally, the messenger may support a future token mechanism. The messenger.send() function immediately return a sending object a future token on which the sending object may query the status of result (non-block), or wait for result (block).

[TO-BE-CONTINUED]