[kepler-dev] question about kepler

dejw dejw at man.poznan.pl
Sun Jul 20 23:20:18 PDT 2008

Hi Tristan,

thanks for this! :) it is more clear for me now.

Thanks again,


Tristan King wrote:
> Hi Dawid,
> The purpose of the replacement actors is to capture output that is 
> usually just displayed in a swing gui window and store it on the 
> server. All the replacement actors are in:
> http://www.hpc.jcu.edu.au/git/?p=jc124742/hydrant.git;a=tree;f=src/main/java/au/edu/jcu/kepler/hydrant;h=d31cebde81cf645abdb9251bc5188ddb7d75ec5e;hb=master
> The file ReplacementManager.java contains the class which the 
> replacement actors use to send their data to to get stored. An 
> instance of this class is added to the kepler workspace before execution.
> Currently it is built to work specifically with Hydrant (i.e. it 
> translates the java hashmap into a python dictionary), but can easily 
> be modified to work in pure java, and i know Jianwu has already done 
> this for his work (although i don't think his code is available online 
> yet).
> The file ReplacementUtils.java contains a static function which 
> replacement actors use to find the ReplacementManager in the workspace.
> in the 
> file: http://www.hpc.jcu.edu.au/git/?p=jc124742/hydrant.git;a=blob;f=src/main/jython/hydrant/job/helpers.py;h=9e29499a32412e7a1b5f353a5f3f6ed7f6697972;hb=master 
> the class DefaultReplacementManager (starting line 36) extends the 
> ReplacementManager class (jython allows python code to interact with 
> java code). The __init__ function (line 37) is the equivalent of a 
> java constructor. line 38 is equivalent to the java "super(container, 
> name)". Lines 40-44 set up a directory on the server to store all 
> the received data in. The abstract function writePythonData is 
> implemented starting line 45. It simply takes the data that a 
> replacement actor sends to it, writes the data to a file, and makes a 
> database entry to keep track of the file.
> the 
> file http://www.hpc.jcu.edu.au/git/?p=jc124742/hydrant.git;a=blob;f=src/main/jython/hydrant/job/__init__.py;h=9c06eb4d64fcdfdddec62763ac309c5addf0d76b;hb=master 
> has the function queue_new_job. At line 26 is where the 
> DefaultReplacementManager is created and added to the workspace.
> I hope this helps. I know my use of jython can make things hard to 
> understand, but it made building the system much simpler (Hydrant took 
> approximately 6 months, with one person developing and no prior 
> knowledge of python)!
> If you want a more detailed description of the functions in any part 
> of hydrant feel free to ask me. I'm very happy to help.
> Another note about my replacement actors method. Each replacement 
> actor is almost an exact copy of the actor it is replacing. This means 
> that there is a lot of code duplication, and if the original actors 
> code changes, the replacement actor needs to be changed as well. Thus 
> this isn't very scalable. I've been trying to push for an MVC approach 
> to building actors in kepler which would allow different execution 
> platforms to handle the view of actors (i have built a prototype using 
> spring but it hasn't sparked any interest yet), but until then, apart 
> from building new actors for your web portal this is the only solution.
> Cheers
> -Tristan
> 2008/7/18 dejw <dejw at man.poznan.pl <mailto:dejw at man.poznan.pl>>:
>     Hi Tristan,
>     thanks for replay, we are now in the phase of requirements
>     gathering and later we will work on desired architecture. I can't
>     say at the moment if we are going to use web services at all. We
>     have now quite nice frame work with all kind of services
>     (http://vinetoolkit.org/) and we will think add another service to it.
>     Our target is possibility to run quite complicated kepler
>     workflows on different grids below and use different data storage
>     management systems to store all generated data, we need also very
>     detailed info about every step of execution of it.
>     If we have such service (we use spring for our services) then it
>     is no problem to make a web service from it later. So it would be
>     actually straight way to do it :) At the moment we have to get
>     known the kepler much better and gain some experience in it. So I
>     think we will be in touch then.
>     PS,
>     I saw the code of your replacement classes for some actors in
>     python. Would it be possible for you to write shortly about them
>     in few sentences? What every of it changes vs the original actors?
>     I would be grateful. (it's always good to hear such thing from the
>     author of code ;)
>     Cheers,
>     Dawid
>     Tristan King wrote:
>>     Hi Dawid,
>>     Hydrant was developed with python purely for prototyping reasons.
>>     It would be maybe 2 weeks work to translate all the python
>>     backend code into java, and I would be happy to collaborate with
>>     you to do this. The only problem would be the interface. You
>>     would have to write a new one using your java web-framework of
>>     choice.
>>     However, I don't plan to build any more on top of Hydrant in it's
>>     current state. What I want to do is separate the backend
>>     execution out from Hydrant and have it run as it's own service.
>>     This service could then be accessed using some form of web
>>     services (i.e. SOAP) by Hydrant or any other front-end portal. I
>>     hope to get the community involved in building something like
>>     this, as there seems to be a lot of people interested in it, and
>>     there has already been a lot of work done in separate instances
>>     towards such technology, it would be great if we can work
>>     together to build something that everyone can use rather then a
>>     whole number of different solutions. Unfortunately there has not
>>     been a lot of response to my initial attempts to get such a
>>     project going, and i've since been distracted working on the
>>     other various things i want to see put into ptolemy/kepler.
>>     I will try and get back onto this next week and perhaps get some
>>     requirements and such up on the wiki.
>>     Cheers
>>     -Tristan
>>     2008/7/17 dejw <dejw at man.poznan.pl <mailto:dejw at man.poznan.pl>>:
>>         Hi Jianwu again,
>>         I want to ask more about this below:
>>>>         3. Actor repository - I understand that it is possible to
>>>>         have one common actor repository for some organization?
>>>>         Kepler uses LDAP for it? Are there some access rights for
>>>>         actors or something like this? Is it possible to grant some
>>>>         roles to users when LDAP authentication is used? Is it
>>>>         possible to require login while starting Kepler?
>>>              You can find the current actor repository at
>>>         http://library.kepler-project.org/kepler/. Yet it is not
>>>         widely used currently. We are trying implement more
>>>         comprehensive actor repository mechanism.
>>         1. So you use LDAP server to store actors? or something else?
>>         2. How about access rights and user roles as regard access to
>>         actors in such repository?
>>         3. I understand I can deploy such repository inside some
>>         organization and configure kepler to use it?
>>         4. Can I set kepler to require login before start editor? to
>>         recognize user somehow?
>>         Dawid
>>         _______________________________________________
>>         Kepler-users mailing list
>>         Kepler-users at ecoinformatics.org
>>         <mailto:Kepler-users at ecoinformatics.org>
>>         http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-users
>>     -- 
>>     Tristan King
>>     Research Officer,
>>     eResearch Centre
>>     James Cook University, Townsville Qld 4811
>>     Australia
>>     Phone: +61747816902
>>     E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au>
>>     www: http://eresearch.jcu.edu.au
>     _______________________________________________
>     Kepler-dev mailing list
>     Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> -- 
> Tristan King
> Research Officer,
> eResearch Centre
> James Cook University, Townsville Qld 4811
> Australia
> Phone: +61747816902
> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au> www: 
> http://eresearch.jcu.edu.au

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080721/17d2704c/attachment.html>

More information about the Kepler-dev mailing list