[kepler-dev] Adding a list property to a relation .....

jagan Jagan.Kommineni at infotech.monash.edu.au
Wed Apr 26 20:37:01 PDT 2006

Hi Edward,

The motive behind the creation of a list property to a relation is as 

1. In GriddLeS (Grid Enabling Legacy Software) we create actors for 
representing real applications.

2. Each griddles actor consists of number of input and output ports each 
represents either input file or output file depending on the type of port.

3. The griddles actor has the knowledge of application to deploy the 
application to the appropriate remote location for execution (eith with 
with globus or nimrod or web service mechanism)

4. Upon submition different applications to the different remote nodes 
the communication cation between applications is taking place by using 
GriddLeS communication mechanism.
(It is similar to thrid part data transfer but by using GriddLeS runtime 
environment). GriddLeS mechanism also takes care of synchronization 
between applications.

5. GriddLeS communication mechanism needs some configuration information 
to select appropriate data transfer mode between applications.
I think, it is more appropriate to make as a property to the relation 
between two actors.

6. GriddLeS runtime environment uses the workflow model defnition to 
generate its configuration.

7.  So far I am generating configuration manually by parsing workflow 
definition's xml file by a seperate script before running workflow.

8. Now I want to make some automation so that before executing workflow 
I want to update GriddLeS configuration.

9  I want to hide all this configuration updates from the application 
user.  Any advise is appriciated.

10. Otherwise I may put GriddLeS config actor  before  a  Composite 
Actor  with SDF director, the configuration is updated before 
executiong  the Composite Actor.

11. In this instance all the GriddLeS application actors (workflow) will 
be placed inside the composite actor. 

12. The relation properties and director specified inside the composite 
actor produces a number IO modes between the applications.

13. IO modes are as follows
                                 a. Data transfer to local files
                                 b. Data transfer to remote files
                                 c. Data transfer to replicated 
catalogues (SRB, GLOBUS REPLICA or GFORM etc)
                                 d. Pipe between applications  ( inter 
process communication  between application components that run on 
different  compute nodes)

14. Some of the IO modes allow stream based data transfer and the rest 
will perfom file based data transfer.

I hope this clarifies our motive in adding a list property to the relation.

with regards,

Jagan Kommineni

Edward A. Lee wrote:

> I'm not sure I understand the objective here, but I would strongly
> discourage modifying TypedCompositeActor in this way.  At a minimum,
> you should subclass TypedCompositeActor and replace the instance
> of TypedCompositeActor in the kepler library with your subclass.
> But unless you want this parameter to appear in all relations,
> this is not a good idea either...
> One possibility would be to put the parameter itself in the kepler
> library and then drag and drop it onto a relation when you want it
> in the relation...  This will currently only work if the relation
> is visible as a diamond, but it could probably be made to work
> even for relations that are just rendered as wires between ports.
> Edward
> At 06:54 PM 4/25/2006, jagan wrote:
>> Hi Chad,
>> I would like to add a list property to a relation. Currently I have 
>> modified
>> ptolemy II ( ptolemy.actor.TypedCompositeActor)
>> The changes are as follows:
>> -----------------------------------------------------------------------
>>   public ComponentRelation newRelation(String name)
>>           throws NameDuplicationException {
>>       try {
>>           workspace().getWriteAccess();
>>           TypedIORelation relation = new TypedIORelation(this, name);
>>  StringParameter param = new StringParameter(relation, name);
>>     param.addChoice("Default");
>>     param.addChoice("webServiceStream");
>>     param.addChoice("webServiceFileCopy");
>>     param.addChoice("srbStream");
>>     param.addChoice("srbFileCopy");
>>     param.addChoice("gridFtpFileCopy");
>>           return relation;
>>       } catch (IllegalActionException ex) {
>>           // This exception should not occur, so we throw a runtime
>>           // exception.
>>           throw new InternalErrorException(this, ex, null);
>>       } finally {
>>           workspace().doneWriting();
>>       }
>>   }
>> ------------------------------------------------------------------------
>> with this change when I join two actors with a relation I can see a 
>> property attached with the relation same name as the relation.
>> This makes a global change, I want this to happen only to specific 
>> relations or workflows.
>> --------------------------------------------------------------------------------------------------- 
>> In using Kepler with GriddLeS I need to put some configuration 
>> information which is obtained by parsing workflow definition file.
>> So far I am doing this activity manually that means after storing the 
>> workflow definition,
>> I use seperate script to parse xml scipt and load data into the 
>> appropriate configuration file.
>> I want to incorporate this into the workflow execution, ideally the 
>> director before starting griddles workflow
>> execution should need to update configuration file. I think in this 
>> case I need to make changes to Director or manager.
>> Alternatively I can put config actor and Composite Actor in the 
>> workflow with SDF director. The griddles
>> workflow actors inside the Composite Actor with either SDF or PN 
>> directors.
>> In this senario the config actor needs name of the current workflow 
>> to parse current workflow definition.
>> Could you mind to tell me how to get the current name of the current 
>> workflow programmatically
>> (after saving the workflow definition)?
>> Or is there any way I can get current workflow definition before 
>> storing into the file at runtime during the creation of workflow.
>> with regards,
>> Jagan Kommineni
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal 

More information about the Kepler-dev mailing list