The title of this page can be quite misleading. It does not show the design of the system, as each subsystem explains its own design on its own, as well as the interactions with any other subsystem. What it does is to shown the very general features affecting the design and the implementation of Sensei.

• Sensei supports (or is built on top of) the virtual synchrony model developed by Ken Birman in the '80s. All the reliable group communication systems existing currently (that we are aware of) use this model.

• The access to Sensei and its subsystems is exclusively done through the IDL interfaces (for CORBA, in case of JavaRMI, through the remote interfaces). The interface is therefore object oriented.

• Sensei supports CORBA and JavaRMI, through two different interfaces. These interfaces are different because they are specified in different languages, but they're intended to support the same functionality. In fact, the implementation is the same for both cases.

To understand how is possible to share the same implementation, using different interfaces, we'll make use of an example. The type Message is defined in SenseiGMS, and has the following specification in IDL:

module sensei
{
	module middleware
	{
		module gms
		{
			valuetype Message {};
		};
	};
};

That is, when the IDL compiler processes this file, it will generate the classes related to the Message type under the package

sensei.middleware.gms

The same type is defined in JavaRMI as:

package sensei.middleware.gms;
public class Message implements java.io.Serializable {}

Therefore, both, the CORBA and the JavaRMI specification, share the same package, although they are placed in different directories.

In fact, the source distribution of Sensei defines the following directory structure:

sensei
|-------corba
|        |-------sensei
|                 |-------middleware
|                          |-------gms(1)
|-------rmi
|        |-------sensei
|                 |-------middleware
|                          |-------gms(2)
|-------gms (3)

• The directory (1) contains the bytecode compiled from the IDL specification.
• The directory (2) contains the bytecode compiled from the JavaRMI interfaces, as well as the RMI stubs and skeletons.
• The directory (3) contains the shared implementation. It depends on sensei.middleware.gms, and it depends on the correct CLASSPATH to choose the middleware.

For example, to use CORBA, the classpath must point out to sensei/corba (it is needed to recompile sensei/gms, it is not possible to compiler it using a classpath and try to execute it with a different one).

Directories (1) and (2) must share as well some common definitions. For example, the package sensei.middleware.gms defines an interface called GroupMember. Using CORBA, the implementation for this interface must inherit (although other possibilities are also possible) from a class called GroupMemberPOA. Using JavaRMI, the implementation must inherit from java.rmi.server.UnicastRemoteObject and implement the interface GroupMember. To avoid this inconsistency, a class is defined in the package sensei.middleware.gms, called GroupMemberImpl, hiding the middleware dependencies, and the real implementation in the package sensei.gms just inherit from this last class.