mChaRM

Questions and issues to Walter Cazzola.

This project should be considered as closed, it was part of the research for my PhD and for this I'm fond of it. Even if it the project is quite old it still propose some interesting ideas that I hope you could appreciate and use in your research.

The multi-channel reification model is a reflective model which allows the system to reify multi-point communications instead of objects. Each method invocation can be reified into a multi-channel performing meta-computations about it before the real activation. In this way it is possible to enrich the classic communication semantics with new behaviors and properties.

mChaRM is a reflective middleware thats allows compile-time reification (and adaptation) of each remote method invocation both single and multi-point.The conversion from mChaRM to standard Java is carried out by a preprocessor developed using OpenJava. The basic idea consists of providing a mechanism to open up the Java RMI package. To open up the remote communication mechanism of Java we adopt the ideas provided by the multi-channel reification model.

Java does not support multi-point communications. Hence, mChaRM provides its (naïve) multi-point communications mechanism based on the standard Java RMI mechanism.

multiRMI(String[] {receiversName}, String methodName, Object[] actualArgs)

Only communications performed through this method are reified, but this one is not a limit because we can use it also for realizing point-to-point communications (specifying only a receiver).

Through the keywords kinds it is possible to specify which meta-behavior to associate with each method that an instance of such a class could invoke (see the examples for the usage).

The mCharM framework consists of the following packages:

• MOP contains the OpenJava MOP handling the base-level extensions. It translates the mChaRM code in pure Java code. It also adds the code to support the multi-channel reification model and multi-point communications. This package is used as a preprocessor, users cannot interact with it.
• PREmChaRM contains the OpenJava MOP handling the multi-channel syntax. Such a new syntax allows the meta-programmer to write a multi-channel as a single and uniform class achieving a global view of the whole communication. This package is used as a preprocessor, users cannot interact with it.
• multichannel contains the basic classes used to build new multi-channels.
• mChaRMCollection a collection of multi-channels.

Currently, the multi-channel collection contains only few examples, i.e., verbose, RMP, validation channels and it should be considered as a bundle of examples for the middleware potentiality.

Each package is provided with a makefile, hence to compile, install, and produce the related documentation is enough to run: make all.

Note: Since version 1.4 mChaRM uses KaRMI so you also have to download and install this library.

Before executing a mChaRM system you have to activate an instance of the rmiregistry on each host in the system, as follows:

java -Dde.uka.karmi.config=karmi-socket.properties uka.karmi.rmi.RunRegistry

then, you can activate each component of your system, respecting the dependence graph of the components (servers at first, then channels, clients at last).

Note: the multiRMI lookup looks for objects into hosts listed in the file .mChaRM_hosts.

The mChaRM reflective middleware has been considered in the popular survey on reflective middleware:

• Fabio Kon, Fábio Costa, Gordon Blair and Roy H. Campbell. The Case for Reflective Middleware. Communication of the ACM, 45(6):33–38, June 2002. ACM Press. [link1]

and Max Goff's in his book

• Max Goff. Network Distributed Computing: Fitscapes and Fallacies. Prentice Hall PTR, April 2004. [link2]

has described mChaRM philosophy as an alternative to traditional distributed systems.

The interested developers can consult the javadoc packages documentation on-line; whereas those more interested in the scientific aspects of mChaRM can look at the references section.

mChaRM v1.5 (the last released version) has been developed and tested on a Linux Box based on pII@350Mhz and Mandrake 7.1 with Java 2 (jdk v1.3.1) and OpenJava V1.0 (05 September 2000) and does not support Java 5+. You can also download some examples.

The main limitation of mChaRM is tied to the fact it is based on an outdated version of Java, so:

• no support for boxing/unboxing of primitive typers;
• no support for enums;
• no support for wildcards and so on.

Apart from this, the following implementation issues are the known limitations:

• Due to implementation choices it is possible to reify only methods whose arguments are Objects. This means that instead of int or char you have to use Integer and Character.
• multiRMI only works in conjunction to a multi-channel, we didn't realize the case in which you want to use it for your applications.

1. Walter Cazzola, "Remote Method Invocation as a First-Class Citizen, Distributed Computing, vol. 16, no. 4, pp. 287–306, December 2003. [PDF1].
2. Walter Cazzola, “mChaRM: Reflective Middleware with a Global View of Communications”, IEEE Distributed System On-Line, vol. 3, no. 2, February 2002. [HTML1].
3. Walter Cazzola, Communication-Oriented Reflection: a Way to Open Up the RMI Mechanism, PhD thesis, Università degli Studi di Milano, Milano, Italy, February 2001. [PDF2].
4. Massimo Ancona, Walter Cazzola, and Eduardo B. Fernandez, “A History-Dependent Access Control Mechanism Using Reflection”, in Proceedings of 5th ECOOP Workshop on Mobile Object Systems (EWMOS'99), Peter Sewell and Jan Vitek, Eds., Lisbon, Portugal, June 1999. [PDF3].
5. Massimo Ancona, Walter Cazzola, and Eduardo B. Fernandez, “Reflective Authorization Systems: Possibilities, Benefits and Drawbacks”, in Secure Internet Programming: Security Issues for Mobile and Distributed Objects, Jan Vitek and Christian Jensen, Eds., Lecture Notes in Computer Science 1603, pp. 35–49. Springer-Verlag, July 1999. [PDF4].