2003 ESMF Components Workshop

The goal of this meeting was to provide a forum for discussion for people who are actively involved in the ongoing efforts to bring component technologies to computational Earth science. There are a range of groups currently pursuing research and development efforts in this area. In some aspects these efforts follow quite similar strategies, in other aspects the approaches being taken are more diverse. A list of questions, available below, was provided to encourage participants to begin to identify where common solutions are emerging to address common problems. These may represent best practices we can all learn from.

Focus Questions

1. What system requirements do you have - e.g. Unix/Linux, CORBA, MPI, Windows,...
2. Can components spawn other components? What sort of relationships are allowed? directory structure model, parent child process model, flat model, peer-to-peer model, client-server etc....
3. What programming language restrictions do you have currently? What programming languages do you foresee using in the next 5 years. (not just current restrictions.) What programming languages do your target users want now and in the next 5 years.
4. Are you designing to be programming language neutral?
5. What sort of component abstraction do you present to an end user? Atmosphere component, Ocean component, an Analysis component, a generic component etc...To what extent is the data being passed between components self-describing?
6. How is "self-describing" being achieved?
7. Do the data structures passed between components have an design that is meant to make them extensible?
8. Does data always have to be copied between components or are there facilities for sharing references to common structures across component boundaries? When, how and why is this needed?
9. Is there a registry concept for components?
10. Are the components truly block structured? e.g a procedure call like interface, or can components have side effects on other component
11. Do you think of your components as all of some generic type, are their several basic component types, is every component its own unique type? What levels and "styles" of parallelism/concurrency or serialization are permitted/excluded. e.g. can components be internally parallel, can multiple components run concurrently, can components run in parallel?
12. What levels and "styles" of parallelism/concurrency or serialization are permitted/excluded. e.g. can components be internally parallel, can multiple components run concurrently, can components run in parallel
13. Do components always have certain specific functions/methods?
14. What, if any, virtualization of process, thread and physical CPU do you use?
15. Can components come and go arbitrarily throughout execution?
16. Can compute resources be acquired/released throughout execution?
17. Does you system have an initialization phase?
18. Is the high-level control syntax the same in different circumstances? e.g. serial component to serial component, versus parallel M component to parallel N component.
19. What standards must components adhere to - languages, standard functions/API's, standard semantics etc...
20. What is it appropriate to standardize for component interfaces.
21. What is it inappropriate to standardize for component interfaces.
22. What is your approach to saving and restoring system state?
23. What are the issues with bringing an existing component or stand-alone application into a particular system.
24. Who are your target users
25. Who are your target component authors.