3. System architectural details
- Architectural attributes
- Integration
- Interoperability
- Data description
- Usability
- Performance
- Available tools to implement the Kbase
- Software
- Databases
- Hardware
- Relevant architectural approaches
- Successful open development methodologies
- Existing systems such as IMG, RAST, CAMERA
- Community de facto tools and databases available from organizations
- Gaps in existing tools and hardware
- Data management, modeling, and representation
- Distributed computing model
- Architectural strategies and decisions that affect the overall organization of Kbase. These include things such as:
- Programming languages, database systems, libraries, etc. to be supported
- Reuse of existing software components to implement various parts/features of the system (which tools listed in 3.1.1 and 3.1.2 above)
- Data and software synchronization across sites if a distributed model is embraced. External databases vs. local copies.
- User interface paradigms (web, thin clients, thick clients, others?)
- How the system is divided up into subsystems, what is unique to each subsystem, and which elements of the subsystems are shared
- How will subsequent scientific objectives and scenarios affect the Kbase architecture?
|
ĉ ď Tom Brettin, Mar 15, 2010 3:03 PM ĉ ď Tom Brettin, Mar 8, 2010 7:05 AM ć ď Tom Brettin, Mar 8, 2010 7:05 AM
|
5.1 Not clear on this point--are the technologies to be supported of concern to tool developers, or to KBase implementors? For the former, I would think sufficient flexibility should be available to make the technology transparent. If it can run on someone's local desktop or compute cluster, it should be able to run as part of KBase. May require giving people sandboxed access to a development area on KBase resources, such that primary tools (interpreters, compilers, libraries, etc.) could be installed, tested, and migrated into the main KBase resource body.
Christopher, can you articulate further how a tool that runs on someones desktop would become part of kbase? Are you thinking of distributing the tool executable or enabling a remote desktop capability that runs on kbase hardware? I think you are talking about the latter.
Tom, sorry for the response latency here. As I can recollect, the point I was making is that the runtime environment available on a KBase server should be a superset of a "standard" bioscience desktop environment, or extended beyond standard. So, if someone has developed a Python module that carries out a class of analyses from a command line or a GUI (Tkinter, Qt, whatever), migrating that to KBase should be made simple -- the appropriate Python interpreter is available, the graphics libraries and Pythonized modules are there, etc. On the other hand, if the bullet (I think it's now 6.1, not 5.1 as I wrote earlier) refers to the computing environment for KBase implementors, the decisions don't impact the user community as directly.
I'm not clear on the workflows to be associated with KBase (I suppose this is part of the current planning process). Will applications be server-side through a Web interface? Or will people have login shells to run command-line tools? Or will a consistent data interface be exposed so that client-side apps could access the KBase data "seamlessly"? Will virtualization play a role, such that each user might customize their environment right down to the OS, with "KBase" enabling a consistent interface to data and apps that may or may not be executable in a user's environment?