[kepler-dev] [kepler-users] question about kepler
Paul Allen
pea1 at cornell.edu
Mon Jul 21 09:34:36 PDT 2008
Here are the major architectural components for the web-based GUI that
we are working on. Our ultimate model calls for only handling workflows
created in our web-based workflow editor, so we haven't worried about
the kind of Actor replacements that Hydrant does.
* *Spring-based MVC controllers*
* *Rich web client*
for authoring workflows using a custom/limited set of actors that
use I/O appropriate to their web environment
* *Workflow Repository*
Stores housekeeping information about a workflow (e.g., name,
owner, description) and references MoML in one of the following ways:
1. inline - internal to the workflow DB record itself
2. URL
3. URL to Fedora Commons digital object
* *Job Repository*
Repository of requests for workflow executions. Acts as a queue
for workflow jobs to be executed.
* *Parameter Repository*
Repository of workflow parameters and values. Supports two kinds
of parameter values:
1. *standard parameters* that are applied at each execution of
a workflow
2. *job parameters* that override standard parameters for a
particular job
* *Job Engine*
A generic framework for executing jobs, based on Quartz. This uses
a large-grained workflow execution model where a workflow executes
within a single thread. It is not a fine-grained execution model
where a single workflow is executed on multiple CPUs or multiple
threads. The idea is that job engines are started on multiple
servers, and they interact with the job repository to pull jobs
off the job repository queue and execute them. Each job engine can
be provided with a pool of threads to use in executing jobs; this
pool can be customized to match the resources of the hardware on
which it runs.
* *Engine Registry*
A job engine uses the central engine registry to provide
information about itself and its status. This is used for
monitoring, but could be expanded to use for controlling remote
job engines.
Here is the short presentation I have at the Kepler Stakeholders meeting:
https://code.kepler-project.org/code/kepler-docs/trunk/meetings/2008_05_13_Stakeholders_mtg/presentations/allen-bap-stakeholders-mtg-2008.pdf
Paul Allen wrote:
> Dawid, Tristan, and kepler-dev people:
>
> I'll try to give you a combined status of this effort. I hope to have
> a coherent version to release in a couple of months. This version
> would be similar in functionality to Hydrant. At this point, the
> implementation is Spring, Hibernate, MySQL, and WebSphere based. I
> know that WebSphere is of limited utility to others, but we typically
> don't take advantage of WebSphere-specific functionality, so it should
> run on any modern Java app server.
>
> I wouldn't mind contributing this software to the kepler project
> (making it open source), but I not sure how that would be handled (a
> separate "product"?). It's also quite messy right now, and I'd want to
> make sure that it is cleaned up at least a little before exposing it.
>
> - Paul
>
> dejw wrote:
>> Hi Paul,
>>
>> it will be open-source? can I download the current code (svn, cvs?)
>> install it and evaluate or something like this? when exectly do you
>> plan to finish it?
>>
>> Dawid
>>
>> Paul Allen wrote:
>>> Yes, we are working on two things that might be of general interest
>>> to the Kepler community:
>>>
>>> 1) a web-based front-end to a myexperiment.org like into which you
>>> can upload and execute workflows
>>> 2) a scalable back-end workflow execution framework to run workflows
>>> at the request of web site users
>>>
>>> We are half-way through a development cycle at the end of which I
>>> expect to have a stable demo site.
>>>
>>> -Paul
>>>
>>> Matthew Jones wrote:
>>>> Hi,
>>>>
>>>> The actor repository allows you to upload an actor along with its
>>>> MoML document and documentation. The actor is stored in a Metacat
>>>> server (http://knb.ecoinformatics.org/software/metacat) and the
>>>> documentation is indexed to enable searching the repository through
>>>> a web-based interface. The repository can also be searched from
>>>> within the Kepler application to locate remote actors of interest.
>>>> Metacat uses LDAP as its directory server to authenticate users.
>>>> Metacat supports fine grained, role-based access control of the
>>>> objects it stores, but we currently are only supporting
>>>> public/private access levels to simplify the process of uploading
>>>> actors. This could be reconsidered if there is a use case for more
>>>> access levels.
>>>>
>>>> Kepler communicates with Metacat using the EarthGrid web services
>>>> interface. Any server that supports the appropriate web services
>>>> interface could technically be used as an actor repository within
>>>> Kepler. Metacat is one such server, and there may be others that
>>>> would be candidates.
>>>>
>>>> You can indeed deploy a version of metacat at your institution and
>>>> use it for your actor repository by configuring the Kepler client
>>>> to point at the new repository.
>>>>
>>>> Kepler automatically prompts a person to login when they attempt to
>>>> perform an operation requiring authentication, such as uploading an
>>>> actor to the repository. There is also a Login menu that allows
>>>> someone to login at any time.
>>>>
>>>> In terms of web-based UIs, there are several efforts. Hydrant is
>>>> indeed an excellent example, but others are also developing
>>>> systems. The GEON project has been running Kepler in the GEON
>>>> portal successfully for several years, and Paul Allen at the
>>>> Cornell Laboratory of Ornithology is developing an interface for
>>>> biodiversity research. The interest in this topic is significant,
>>>> and so we will probably be forming a working group to improve
>>>> Kepler's ability to be run in a portal environment.
>>>>
>>>> Regards,
>>>>
>>>> Matt
>>>>
>>>> P.S. Please do not cross-post to kepler-dev and kepler-users --
>>>> pick the appropriate list for your question -- most developers are
>>>> on both lists.
>>>>
>>>> dejw wrote:
>>>>> 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
>>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-users
>>>>>
>>>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080721/f154d4fc/attachment.html>
More information about the Kepler-dev
mailing list