Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

PTP/designs/rm framework/new model structure

< PTP‎ | designs‎ | rm framework
Revision as of 12:09, 10 January 2011 by (Talk | contribs) (New Model-Structure)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

New Model-Structure

On this page we will discuss the structure of the new model in the Eclipse-Plugin PTP and the integration of LML (LLView (LML)) which should be part of the new model. This discussion should help to analyze the specification and issues of the suggested new model.

First, there is an overview over the suggested new model shown, followed by the description of the different parts of the model.



It was already discussed and decided to keep the ResourceManager and the Universe in the new model, therefore it has to be customized. The ResourceManager is divided into a controlling and a monitoring part. The controlling part is responsible for starting and controlling the jobs within PTP. The monitoring part shows the current state of the system. Interaction between both is possible. For example, the controlling part could query information about the jobs from the monitoring part or push new information about started jobs in PTP into the monitoring part.

The monitoring part is also divided into two parts. The first part is the description of the whole system (LML). The second part has to contain special information for the Nodedisplay view or other views.


The first part of the monitoring part of the model is the LML-data structure which describes in a nearly redundance-free and compact form the state of the whole system. This structure is generated by a JAXB-component. The JAXB-component gets the current LML-file from the server-side as input. When a new LML-data structure is generated, an update of the ExpandedNodedisplay and after that a refresh of the views in the Parallel Runtime perspective has to occur.


Objects are jobs or nodes with specials parameters. They are needed as a mapping between the different views in the Parallel Runtime perspective, like Nodedisplay view, Job view or a view for further information.


This part of the model has further information for the objects.


There can be different tables, for example a job table or a table for waiting jobs. With this data structure different kinds of tables can be described. Therefore every information of a job is saved in its own cell.


This tree describes the state of the whole system. The description is redundance-free.



This tree describes only a part of the system. The description is not redundance-free because the whole tree for a certain part of the system (not the whole system) is spanned.


For example, it should not be possible to have all nodes of the system in tree of ExpandedNodedisplay. If the user is interested into another part of the tree, Eclipse spans a new tree with the desired information. Eclipse get that information from CompactNodedisplay in the LML-tree.

Data flow and updates

It was mentioned that after a new LML-data structure was generated, an update of the ExpandedNodedisplay has to take place. The update of the ExpandedNodedisplay involves a traversing the tree of the new generated CompactNodedisplay and a spanning of a new tree. The new tree shows only a part of the state of the system.

Back to the top