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

Edward A. Lee eal at eecs.berkeley.edu
Thu Apr 27 17:28:01 PDT 2006


I guess a problem I would have with this is that every relation would
get these properties, but only some of them would need it.  Right?

Why not use an actor to mediate the communication?  The wireless domain,
for example, does this routinely.

In any case, hard-wiring this into TypedCompositeActor won't do,
because then every use of Ptolemy would have these (mostly meaningless)
parameters...

Edward


At 08:37 PM 4/26/2006, jagan wrote:
>Hi Edward,
>
>The motive behind the creation of a list property to a relation is as
>follows:
>
>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
>
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------
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