Jan K. Labanowski: Computational Portals for Chemistry  

Design Goals

We wanted to create an environment which would have the following characteristics:
  • Specify problems in science language, not in shell instructions. Provide Advanced Track (extended control) and User Track (take defaults from the black box).
  • Hierarchy of contexts: User -> Problem -> Session -> Application:
    • Problem -- scientific requirements for some calculations
    • Session -- particular run
    • Application -- computational component (applications could be chained to create multi-step computation scenario. Glue needed to connect different software packages).

  • Transform scientific requirements to specific software and hardware requests
  • Pay attention to the security, authentication, and accounting (DoD)
  • We assumed that jobs submission and resource discovery will be done eventually by computational grid, so rather than devise some sophisticated authentication schemes we were using a simple model for testing (ssh) knowing that it will be eventually replaced with some generally accepted service (e.g., GIS of Globus).
  • Provide hooks for collaborative environments, searching, journaling, indexing. Users have profiles (in XML) and hierarchical directory tree with XML files describing actions and results.
  • If you want people to use this thing, it needs to offer advantages to working/login directly with shell.
  • Make it extensible, so adding new tools and analysis modules is easy. Use Object Oriented approach (Java) and use XML files (and corresponding DTDs -- the XML Schemas/XSD or Resource Description Framework/RDF was not there yet) to describe actions, results, necessary parameters, available resources, etc. This would allow using commodity components, and allow to describe functionality and requirements of software packages. If this had reached the community level participation, we would have a way to describe and annotate the computational tasks.