Skip to end of metadata
Go to start of metadata

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:

  1. Translate service layer XML payloads to JSON for use by the UI
  2. Provide cookie/session-based authentication to the UI
  3. Serve static UI assets (JavaScript, CSS, HTML, icon images, etc.)
  4. Configure the the UI layer
  5. Configure the services layer

The Proposal

I believe that most of the things the application layer does could be better done elsewhere.

  1. The services layer could optionally produce and accept JSON payloads, in addition to XML.
  2. The services layer could provide token-based (bearer) authentication, in addition to the username/password (basic) authentication currently supported.
  3. 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.
  4. Configuration of the UI could be done in the UI layer. The configuration currently done in the application layer is already tightly coupled to HTML templates, JavaScript, JSON configuration, and message keys in the UI layer, so most of the time you have to modify both layers anyway. It's difficult for implementers to figure out that what appears to be a UI-only change (for example, adding a field to the advanced search screen) actually also requires a change to the application layer.
  5. 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.

Why?

There are a few important advantages to eliminating the application layer.

Improved Reliability

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.

Better Performance

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.

Simpler Configuration

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 talk@lists.collectionspace.org. In future posts I'll provide updates on the status of each change I've described here.

2 Comments

  1. Great review of the Application layer's functionality Ray.  Some of the current UI's requests to the Application layer require it to aggregate calls to the Services -what it calls "composite" requests, I think.  We could shift the aggregation to the Services layer, new UI, or both if needed.  What's your current thinking on this?

    1. Ray Lee AUTHOR

      I think this will be case-by-case. I'll probably start by having the UI make multiple requests to the services API, and then think about adding aggregation to the services layer where there's real value in terms of performance and/or simplification. I actually can't even think of where the app layer is doing aggregation now, though I know it exists. Maybe they're somewhat obscure use cases?