Some significant changes that will happen to CollectionSpace with the rewrite of the UI aren't actually in the UI at all.
You probably know that CollectionSpace is made up of three layers: the services layer, the application layer, and the UI. While working on the prototype of the new UI last year, I considered making a pretty drastic simplification: Could we have a UI that connects directly to the services layer, allowing us to remove the application layer? I concluded that we probably could, without too much trouble. In the intervening year, it's become even more enticing.
I'm taking this opportunity to greatly reduce the application layer, and hopefully to eliminate it completely. To understand what this means, let's examine what the application layer does. I think there are five things:
- Translate service layer XML payloads to JSON for use by the UI
- Provide cookie/session-based authentication to the UI
- Configure the the UI layer
- Configure the services layer
I believe that most of the things the application layer does could be better done elsewhere.
- The services layer could optionally produce and accept JSON payloads, in addition to XML.
- The services layer could provide token-based (bearer) authentication, in addition to the username/password (basic) authentication currently supported.
- Static UI assets could be served by any HTTP server. We could configure the Tomcat server distributed with CollectionSpace to do this, and deployers could optionally use their own web server.
- Configuration of the services layer could be done in the services layer. XML configuration in the application layer is currently used to generate three kinds of artifacts for the services layer: XML schema files (XSD), tenant configuration (aka tenant bindings) files (XML), and Nuxeo doctype bundles (jar files). One option is to retain some kind of XML configuration similar to what currently exists in the application layer, but simplified and with UI-specific configuration removed. Those files could be moved into the services layer. Another possibility is to use XSD files as the primary source of configuration, and generate tenant configuration and Nuxeo doctype bundles from those. That would be nice in that we wouldn't be inventing our own configuration file format, but it's possible that we can't put all the information needed to configure the services layer into valid XSD files. I'll be investigating these options further.
There are a few important advantages to eliminating the application layer.
Currently the application layer has an idea of the state of the system, via its configuration files. The services layer also has an idea of the state of the system, via its databases and Nuxeo. These do not always agree. For example, you might add some fields to the application layer configuration, but forget to run
ant deploy_services_artifacts, so those fields are not known to the services layer. This can result in inscrutable errors when saving records. Once the UI is able to talk directly to the services layer, the services layer becomes the single source of truth for the state of the system, eliminating a class of problems that are difficult to debug.
The application layer is itself a web application (in the Java EE sense), which connects to the services layer application over HTTP. This results in greater memory usage in the JVM vs. a single application, and incurs additional HTTP overhead on each request. The XML to JSON conversion is also very memory and processor intensive, and could be improved. Removing the application layer and rewriting the conversion code should reduce the memory required to run a CollectionSpace server, and make some requests faster.
As it's grown over time, the XML configuration in the application layer has accrued inconsistencies, misnomers, and workarounds that cause confusion for customizers. Fixing these, along with co-locating all UI-related configuration in the UI layer, would improve the developer experience.
What do you think? Let us know at email@example.com. In future posts I'll provide updates on the status of each change I've described here.