          RRM -- Remote Resource Monitor for RTEMS


1. INTRODUCTION


This document describes RRM - Remote Resources Monitor for RTEMS.
It is a client/server application based on CORBA. 
The server side is a C++ CORBA object that collects resource 
information of a RTEMS target. The client is a java swing 
based application that show the reosurces information from
any host that supports java 1.2 or higher.

The main reason for writing this application is to show how to integrate
your RTEMS target with other enterprise computers using CORBA. 

It is not a goal of this application to teach you how to use CORBA,
Java or any other technology used here. 

Also, do not use it as a way to learn CORBA/Java/Swing/etc. There are
many resources on the internet covering all these technologies.
Be warned, the technologies used here are complex, and setting
them up can be a pain.

    + RTEMS: 	omniORB C++ based ORB
    + Host:  	Sun JDK 1.3's ORB.


2. DESIGN


Monitoring a remote system involve a lot of messages being requested to the 
remote target, and any design of such a system should take this
requirement seriously, otherwise performance would be poor.

A first design consideration taken was about minimizing "round trips".
This is accomplished replacing interfaces with simple data structures 
on the client side. This technique is called "Coarse Object Models". 
More details about it, can be found here:

    Advanced CORBA Programming with C++.
    by Mitch Henning & Steve Vinoski.


Advantages of using it:


   + Reduced number of CORBA objects in the system. This results in smaller
server code( running on RTEMS ) and data at runtime, so it is likely to 
scale better for a larger number of objects.

   + Turning objects into datam acts as a primitive form of caching. The data is
always available on the client side, so repeated access to a particular
value does not require a remote message.



Another design tip is to isolate the "CORBA" specific interfaces from the 
domain specific aspects of the application. This is done through an adapter
pattern linking the RTEMS specific code and the CORBA interface implementation.
( see module rtems_rrm_i.cc/h ).


The basic idea driving the design of this system relies on two types of 
information that will be available on the client:

   + Counters: information that is usually associated with a RTEMS manager.
The data in a counter will contain configuration parameters, the current number
of instances per manager, and any other peace of data in use by that 
particular manager.

  + Instances: information that is associated with each RTEMS resource, such as 
a task ( thread ) for the Task Manager. Each instance will have the most current 
updated information about itself. 

CORBA wise there will be a "Monitor interface with methods to allow clients to 
request counters and instances information at any given time.
As mentioned earlier, this approach uses "Coarse Object Models" where the Counters
and Instances  are defined as data to minimize the number of "round-trips" 
messages when clients are monitoring the system.

The IDL interface, , does have a complete description of the fields for 
each Counter/Instance.


On RTEMS side, the "Monitor interface" implemenetation acts as an adapter to 
the services provided by RTEMS. This adapter is implemented in rtems_rrm_i.cc/h.

A class hierarchy to provide RTEMS resource information has been written.
They're implemented in resources.cc/h. These clases are "domain specific", 
and they'll be available for others RTEMS programs. They are totally unaware 
of CORBA. It can be used with any other type of middleware, if one decide 
that CORBA is not a good match for some types of applications.


3. SETUP


This assumes that you are familar with RTEMS and omniORB. 
CORBA setup is not trivial, and this assumes that you have 
a working naming service and an RTEMS target able to talk
TCP/IP. 

The archive ( rtems_rrm-0.01.tar.gz ) should be extracted
to overlay the omniORB tree.

   cd <your omniORB tree )
   tar xcvf rtems_rrm-0.01.tar.gz

See file "readme.txt" under src/examples/rtems_rrm for more details.


4. TODO


   + Finish the implementation of some functions.

   + Add support for iTRON

   + Memory Information requires changes to malloc()


5. CREDITS




