[kepler-dev] Kepler Alpha8

Dan Higgins higgins at nceas.ucsb.edu
Thu Dec 22 09:28:04 PST 2005


Bertram,
    Thanks for the comments!

In response to your comments:

#1) Some method for knowing who is responsible for a workflow is a good 
idea. A partial solution that is now being used in some cases is the 
addition of author name and data as part of the annotations for a 
workflow. In many cases the topic can identify the organization (e.g. I 
know to contact Efrat about GEON workflows.) I know when SEEK workflows 
are broken, but I don't follow all the other workflows, so I often do 
not check them.
    It would certainly be easy to slightly change the directory 
structure under the workflows directory to have demos and experimental 
workflows. And if the workflows do not have any actors not in the Kepler 
distribution, they could be opened directly from a web site (using Open 
URL).

#2) The ENM/GARP workflows are examples of your suggestion. There are 
many workflows which are just simpler pieces of the entire complex 
workflow (and they are certainly less fragile than the overall one).

#3) The current cache system allows just what you suggest (at least for 
Ecogrid datasources). The first time a datasource is used in a workflow, 
the data is saved in the cache. From then on, it is just pulled from the 
local cache. This speeds up things a lot and should allow operation of 
demos without net access. [A bunch of ecogrid code and sources has been 
under development./change lately, so I not sure this currently works 
with no net connection, but I have used this for demos in the past. 
Unfortunately, I have had to keep deleting my cache as we work on the 
system, so I have downloaded data many time that I would have preferred 
to have locally!]

Dan

Bertram Ludaescher wrote:

>>>>On Mon, 19 Dec 2005 12:44:14 -0800
>>>>Dan Higgins <higgins at nceas.ucsb.edu> wrote: 
>>>>        
>>>>
>DH> 
>DH> Hi All,
>DH>     There is a zipped version of the potential alpha8 Kepler release at
>DH> http://www.kepler-project.org/dist
>DH> under the name 'kepler-alpha8_test1.zip'
>DH> 
>DH> You may well want to take a look. Windows users should be able to run 
>DH> the code using 'kepler.bat' (and Linux/Mac users using kepler.sh). Note 
>DH> that the zipped version does not use or require preset environment 
>DH> variables, so you should be able to unzip anywhere. Also note that the 
>DH> PTII directory is not needed since compile PTII classes are in the 
>DH> kepler.jar file.
>DH> 
>DH> We have several unresolved problems. First, any of the 'IPCC' data 
>DH> sources cannot be dragged onto the work area (SRB problem?)
>DH> 
>DH> Is the PIW workflow working?
>DH> 
>DH> Are the GEON workflows working? (web services - are they working?)
>DH> 
>DH> It looks to me like the ORB example workflows do not work.
>DH> 
>DH> Any comments?
>
>Two comments:
>
>(1) Can we assign an "owner" to each demo-workflow? Then the owner
>would be in charge of making sure everything runs, and if it doesn't
>the workflow could be move from the "demo collection" (part of the
>package) to the "experimental collection" (probably not part of the
>package, but dynamically installable.. via "the Kepler repository")
>
>(2) Inherently, complex workflows using many non-local resources (web
>services, data sets etc) are more fragile than simple ones (or complex
>ones with few non-local resources). Thus, we might want to think about
>refactoring some of the complex ones into smaller pieces -- for demo
>purposes. Demos should demonstrate features, not be complex
>"production workflows".
>
>(3) Not sure whether caching could be used for demos in Kepler. I've
>been involved in two other systems (Florid and the early BIRN
>mediator) whihc had a result caching mechanism. So you could prepare a
>demo while online, then show it offline, i.e., running from the
>cache. If the current caching system allows such a use (or misuse some
>might say ;-) then this is another way to make demos more resilient.. 
>This mechanism could also double for automatically checking
>(deterministic!) workflows in nightly test suites..
>
>Bertram
>
>DH> 
>DH> Dan
>DH> 
>DH> 
>DH> 
>DH> 
>DH> -- 
>DH> *******************************************************************
>DH> Dan Higgins                                  higgins at nceas.ucsb.edu
>DH> http://www.nceas.ucsb.edu/    Ph: 805-893-5127
>DH> National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
>DH> Santa Barbara, CA 93195
>DH> *******************************************************************
>DH> 
>DH> 
>DH> _______________________________________________
>DH> Kepler-dev mailing list
>DH> Kepler-dev at ecoinformatics.org
>DH> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>  
>


-- 
*******************************************************************
Dan Higgins                                  higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************




More information about the Kepler-dev mailing list