| | 1 | Status: this is under development for MOLGENIS 4.0 Don't expect this if you use MOLGENIS 3.x! |
| | 2 | |
| | 3 | = Architectural overview = |
| | 4 | MOLGENIS is organized as a set of modules which we call plugins. Each plugin adds a combination of |
| | 5 | |
| | 6 | * MolgenisModels - models that use the domain specific language to define functionality compactly |
| | 7 | * MolgenisGenerators - templates that expand the models into working software |
| | 8 | * MolgenisComponents - |
| | 9 | |
| | 10 | and/or handwritten code. Other plugins may extend other plugins to yet add more functionality. The first plugin where all others build upon is the MOLGENIS database core. The last plugin is typically a fully functional application that assembles other plugins |
| | 11 | |
| | 12 | TODO core architectural picture. |
| | 13 | |
| | 14 | TODO directory structure |
| | 15 | |
| | 16 | TODO concept of extension points |
| | 17 | |
| | 18 | = Extension mechanism = |
| | 19 | Each building block may add framework code, model extensions, generators and/or models. In this last case the module may regeneration against the last versions before it can be used (which we can do automatically?). After that we could use a osgi drop in mechanism to add the produce funtionality into a running system. |
| | 20 | |
| | 21 | Design 0: simply link to projects In this procedure the model files are puth on classpath and can be simply imported. The code has to be generated by the imported projects themselves. This is ideal for development (as long as re-generation is a one push on a button event and checks if generators are changed (hash or something)). |
| | 22 | |
| | 23 | Design 1: linking in code We imagine a procedure where when a user runs the generator (ant script, nothing else) |
| | 24 | |
| | 25 | * downloads the core molgenis and starts the model parser/generator |
| | 26 | * when <import="db" .../> is in your local model dependencies are automatically checked out from svn to /generated/java (incl libs!) |
| | 27 | * each of these dependencies is regenerated in dependency order |
| | 28 | * tests run to verify that the modules are sanitized (no compile errors, test cases work) |
| | 29 | * and then produced as osgi modules that are simply loaded by the current project during the rest of development |
| | 30 | |
| | 31 | And have a 'clean' action to redo the procedure. |
| | 32 | |
| | 33 | Design 2: downloading maven/osgi modules. We imagine a procedure where when a user runs the generator from maven (maven pom + molgenis core as plugin, nothing else) |
| | 34 | |
| | 35 | * downloads all depedencies using maven model (all MOLGENIS settings should be in this model as well to keep it simple?) |
| | 36 | * add generate tasks to maven to get all stuff done |
| | 37 | |
| | 38 | Complicating factor here is that the maven repos should be rebuild now and then. |
| | 39 | |
| | 40 | We could allow both design 1 and 2 in order to speed up development? |
| | 41 | |
| | 42 | i.e. organize maven compatible but still allow ant.xml type of interactions to do this low-tech. Or use maven in the back and don't necessarily bother the user with it. |
| | 43 | |
| | 44 | = Core modules = |
| | 45 | These are the foundational building blocks that can be reused between all MOLGENIS applications. Package org.molgenis.* |
| | 46 | |
| | 47 | Core: |
| | 48 | |
| | 49 | * [wiki:Plugins/OrgMolgenis core] - core platform of model (parsers), generators and util packages |
| | 50 | * [wiki:Plugins/OrgMolgenisDb db] - database interface framework on top of MySQL, PostgreSQL and HypersonicSQL (extends core) |
| | 51 | * [wiki:Plugins/OrgMolgenisExchange exchange] - file import/export mechanisms from and to csv, tab, excel, (xml), etc (extends db) |
| | 52 | * [wiki:Plugins/OrgMolgenisApi api] - application programming interfaces to Java, R, REST, SOAP, RDF, etc on top of Db (extends exchange) |
| | 53 | * [wiki:Plugins/OrgMolgenisUi ui] - web user interface framework with forms, menus and plugins (extends api) |
| | 54 | * [wiki:Plugins/OrgMolgenisCompute compute] - compute interface framework for short, long and parallel running computations (extends ui?) |
| | 55 | |
| | 56 | Discussion: ui could be moved to depend on core only, and then have other packages extend on that to add particular UI components for db, compute, etc. Or have separate ui extensions like ui.db, ui.compute, etc. |
| | 57 | |
| | 58 | = Components = |
| | 59 | These are the semi-finished building blocks that can be shared between different applications to reuse common work. These components typically provide data model (modules) that need to be generated before a plugin is ready to use. Hence, there is a need to regenerate on the first installation of the plugin. package org.molgenis.* |
| | 60 | |
| | 61 | Cross cutting: |
| | 62 | |
| | 63 | * [wiki:Component/OrgXgapAuth auth] - secure authentication and sharing framework (extends ui) |
| | 64 | * [wiki:Component/OrgXgapVersionable versionable] - mechanism to have versioned data elements by simply extending an interface |
| | 65 | |
| | 66 | Discussion: need ability to weave this in later, like a special decorator that is applied everywhere? Or should we just make these core features and move it into db package? |
| | 67 | |
| | 68 | Generic: |
| | 69 | |
| | 70 | * [wiki:Component/OrgXgapOnto molgenisdata.onto] - for using ontologies including tree based browser, search box (extends ui) |
| | 71 | * [wiki:Component/OrgXgapMatrix molgenisdata.matrix] - for working with matrix like data having 'dimensionelements' and 'dataelements' |
| | 72 | * [wiki:Component/OrgXgapProtocol molgenisdata.protocol] - for track and tracing of materials/data, protocols, protocolapplications (compatible with MAGE-TAB SDRF) |
| | 73 | * [wiki:Component/OrgXgapTool tool] - for integrating R scripts onto the application (extends protocol, compute) |
| | 74 | * [wiki:Component/OrgXgapMaterialTracker tool] - for integrating R scripts onto the application (extends protocol) |
| | 75 | |
| | 76 | Domain: |
| | 77 | |
| | 78 | * [wiki:Component/OrgXgapLocus locus] - tools for managing and browsing genomic sequence annotations |
| | 79 | * [wiki:Component/OrgXgapPheno pheno] - for representing deep phenotypic data collected in clinics and the field (extends onto, tracker, matrix) |
| | 80 | * [wiki:Component/OrgXgapMutation muta] - for working with mutating data conforming to HGVS nomenclature (extends pheno) |
| | 81 | |
| | 82 | More ideas: pedigree, comments |
| | 83 | |
| | 84 | = Applications = |
| | 85 | Systems are ready to use and download. Ideally end users would be able to choose from these online. |
| | 86 | |
| | 87 | * [wiki:Apps/PhenoTrackerMolgenis PhenoTracker] - for storing phenotypics annotations on individuals and panels |
| | 88 | * [wiki:Apps/GwasMolgenis GwasPlatform] - for GWAS studies like in EU-GEN2PHN, LifeLines and BBMRI-NL |
| | 89 | * [wiki:Apps/QtlMolgenis QtlPlatform] - for QTL studies in model organisms like EU-Panacea |
| | 90 | * [wiki:Apps/MutationMolgenis MutationTracker] - for locus specific annotations (extends pheno, muta) |
| | 91 | * [wiki:Apps/ShortReadMolgenis SequenceArchive] - for storing, QC-ing and releasing short read data from NGS |
| | 92 | * |
| | 93 | |
| | 94 | = Ideas for more enhancements = |
| | 95 | == Core == |
| | 96 | * [wiki:Plugins/OrgMolgenisUi/Theme ui.theme] - catalog of UI web themes for MOLGENIS applications the use can choose from (extends ui) |
| | 97 | * [wiki:Plugins/OrgMolgenisUi/Iphone ui.iphone] - iphone user interface (extends ui) |
| | 98 | * [wiki:Plugins/OrgMOlgenisDb/Versionable db.versionable] - to allow versionable data entry |
| | 99 | * [wiki:Plugins/OrgMolgenisApi/Observer api.observer] - mechanism to observe and log activity for tracking and tracing |
| | 100 | * [wiki:Plugins/OrgMolgenisApi/Feeds api.feed] - atom feeds + command in UI to observe data, queries and/or transactions (extends api, ui) ui |
| | 101 | * [wiki:Plugins/OrgMolgenisUi/EclipeR ui.gwt] - rich client application generator based on GWT |
