Difference between revisions of "Engine RMI Interface"

From RifidiWiki

Jump to: navigation, search
(Using Cajo)
(Class Diagram)
Line 95: Line 95:
 
Another advantage of using RMI and cajo is that it allows for callbacks.  This means that a client can call methods on a server using the method above, and the server can also  invoke methods on the client using a similar method.  This is important for Rifidi in situations with the GUI needs to be updated based on changes in the reader, such as when a TagID changes or when a GPO line goes high.
 
Another advantage of using RMI and cajo is that it allows for callbacks.  This means that a client can call methods on a server using the method above, and the server can also  invoke methods on the client using a similar method.  This is important for Rifidi in situations with the GUI needs to be updated based on changes in the reader, such as when a TagID changes or when a GPO line goes high.
  
==Class Diagram==
+
==RMI Class Diagram==
 
[[Image:RMI_Class_Diagram.png|thumb|1000px|none|A UML Class Diagram depicting the components of the RMI Architecture in Rifidi]]
 
[[Image:RMI_Class_Diagram.png|thumb|1000px|none|A UML Class Diagram depicting the components of the RMI Architecture in Rifidi]]
 +
==RMI Class Diagram Components==
 +
#'''RifidiClient'''
 +
 
==RMI in action: An example==
 
==RMI in action: An example==
 
=Reference Client=
 
=Reference Client=

Revision as of 23:29, 23 November 2007

RMI (Remote Method Invocation) is an architecture that allows clients to invoke methods on remote machines. Rifidi uses this architecture to allow the IDE (and the Tag Streamer) to communicate with the reader. It uses the cajo library to provide the RMI functionality.

Purpose of RMI Architecture

The basic goal of implementing RMI in Rifidi is so that one client (i.e. the IDE or Tag Streamer) can transparently control multiple readers on different machines, if need be. This enables a distributed architecture that will allow rifidi to drive performance testing of edge servers, because multiple machines can run rifidi readers, thus distributing the load across a network of computer. At the same time, however, it should be easy to start up one or two readers on a local machine for compatibility testing or to simply experiment with a reader.

Architecture Diagram

A figure depicting the purpose of RMI in Rifidi

Architecture Components

  1. Client The client (such as the IDE, Tag Streamer, or Designer) runs on a local machine. Its purpose is to allow the user to manipulate readers (i.e. start, stop, add tags, etc).
  2. Reader Server The Reader Server manages one or more readers on a particular machine by creating and destroying readers. There is one instance of a reader manager per machine.
  3. Reader A reader is the program that emulates a particular reader, such as an LLRP Reader. There can be multiple instances of a reader on a single machine.

One important aspect of this architecture is that The client doesn't care if a Reader Server is local or remote. That fact is transparent to the client.

Rifidi RMI Implementation

This section describes how RMI is implemented in Rifidi.

Using Cajo

Cajo is "a small, free library, enabling powerful dynamic multi-machine cooperation; both within and between, both free and proprietary Java applications. It provides a surprisingly easy to use, yet completely understandable framework to dramatically simplify the use of RMI; whilst at the same time harnessing its full potential." (https://cajo.dev.java.net/). If you are not familiar with cajo and/or RMI, you should read through the examples on cajo's website and wiki.

Remote Interfaces

One of the advantages of cajo is that it allows an object to easily expose functionality through an interface that another object can get and use. The advantage to using an interface as opposed to invoking calls using text is that typechecking can be done at compile time.

For example, suppose Object_A looked like this:

public class Object_A implements Serializable{
	
	private static final long serialVersionUID = 1L;
	
	private int value=0;
	
	public void incrementValue(){
		value ++;
	}
	
	public String getValue(){
		return "object A's value is: " +Integer.toString( value);
	}

}

A simple way that a client could access Object_A's functionality is like this:

Object object = Remote.getItem("//serverHost:1198/obj_a");
Remote.invoke(object, "incrementValue", null);
String s = (String)Remote.invoke(object, "getValue", null);

However, another way that the client could access Object_A's functionality is if Object_A implemented an interface that exposed its methods that are available via RMI. For example, suppose there was an interface that looked like this:

public interface Object_A_Interface {

	public abstract void incrementValue();

	public abstract String getValue();

}

Now Object_A looks like this:

public class Object_A implements Serializable, Object_A_Interface{
	
	private static final long serialVersionUID = 1L;
	
	private int value=0;
	
	/* (non-Javadoc)
	 * @see org.rifidi.sandbox.cajo.test.Object_A_Interface#incrementValue()
	 */
	public void incrementValue(){
		value ++;
	}
	
	/* (non-Javadoc)
	 * @see org.rifidi.sandbox.cajo.test.Object_A_Interface#getValue()
	 */
	public String getValue(){
		return "object A's value is: " +Integer.toString( value);
	}

}

A client can now access Object_A's functionality by getting an interface and calling the methods. This enables the compiler to throw errors if something is wrong.

Object_A_Interface obja = (Object_A_Interface) TransparentItemProxy.getItem(
                                               "//serverHost:1198/obj_a",
                                               new Class[] { Object_A_Interface.class });
obja.incrementValue()
String s = obja.getValue();
System.out.println(s);

Callbacks

Another advantage of using RMI and cajo is that it allows for callbacks. This means that a client can call methods on a server using the method above, and the server can also invoke methods on the client using a similar method. This is important for Rifidi in situations with the GUI needs to be updated based on changes in the reader, such as when a TagID changes or when a GPO line goes high.

RMI Class Diagram

A UML Class Diagram depicting the components of the RMI Architecture in Rifidi

RMI Class Diagram Components

  1. RifidiClient

RMI in action: An example

Reference Client