...
- Deploying the DSpace backend is easier, as it's a single web application within Tomcat
- Server resource usage is minimized, as all modules share the same Java classes/libraries
- Only one initialization of Hibernate (instead of one per webapp)
- Only one initialization of Flyway (instead of one per webapp)
- Arguably, enabling/disabling various "modules" (SWORD, OAI, RDF) is clearer, as it's all based on configuration (and modules you want enabled can be specified in your local.cfg file).
- Only one initialization of Hibernate (instead of one per webapp)
- Only one initialization of Flyway (instead of one per webapp)KEEP IN MIND, this same "module" concept could be extended to DSpace third-party modules. In this case, all DSpace "modules" are JARs (that optionally use Spring annotations/APIs to add subpaths/behavior) backed by DSpace configuration (which can be used to easily enable/disable/configure the module). So, installing a new module could be simply dropping in a new JAR (or adding a new dependency) and adding configuration to your local.cfg.
- (In the future, post-7.0) We also could consider using Spring Boot's capability to embed Tomcat directly, so that deployment is as simple as running the application.
- However, this would not be available in DSpace 7.0, and would require more discussion on whether it's the right direction for DSpace.
Other questions to consider
...