Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


This document outlines the specific technologies we propose to use in the Fluid Engage services layer. More details about the overall architecture of Engage can be found on the Engage Architecture page.

The Engage services layer aims to weave together the various resources and sources of information required to create a compelling and interactive exhibit experience. We'll talk to content and collections management systems, image stores and asset systems, as well as social networking services on the Web such as YouTube, Wikipedia, and Twitter. Engage will share these resources back out throughout the system ensuring that it's easy to create great user interfaces for both the Web and mobile devices using these services.

For database persistence and searching, we'll use Apache's CouchDB and Lucene products. CouchDB provides us with a Web-friendly, document-oriented database solution that won't force strict schema requirements on our users and implementers.

For services development, we'll create a new server-side JavaScript Web environment by assembling existing technologies into a lightweight framework called Kettle. This framework will initially be hosted inside the Java Virtual Machine using Rhino, and will eventually migrate to a fast next-generation rutime such as Google's V8 engine.

Goals & Criteria

  • Broadly approachable
  • Hit the ground running
  • Interoperable
  • Scalable and forward-looking
  • Fits the approach of the Fluid community: functional, declarative, Web-oriented


At the same time, our choice for server-side technology needs to be scalable and forward-looking, allowing museums to invest in Engage over the long run, without fear that our services will slow down impossibly when confronted with large collections. Engage services also need to be future-proof enough to not quickly become obsolete as the technology landscape evolves.

Lastly, the Fluid community has built up, over the years, a set of techniques and philosophies for writing software: accessibility, the Open Web, functional programming, and markup agnosticism are common themes throughout our technologies. As a community, we embrace diversity and a wide range of styles; shared patterns and techniques in code help make our solutions more coherent and consistent to develop with.


Given that we can't pre-bake the data model completely, a standard SQL-based relational database in is inappropriate for Engage. A new crop of document-oriented databases has emerged that are well-suited to handling dynamic schemas. Foremost among these is CouchDB, a highly scalable and Web-friendly database written in Erlang.

Couch specifically addresses the schema problem we face in Engage. Data is stored as documents in JSON format, making it particularly useful in client-side applications that make heavy use of JavaScript. CouchDB Views, which provide a means for filtering, aggregating, and retrieving data from documents in the database, are written in JavaScript and can be used to provide various data feeds from a collection of documents. This fits neatly within Engage's open Web architectural approach, and is approachable to a wide range of developers.


At the same time, JavaScript is probably the most widely used and understood programming language today. Regardless of what technologies are used on the server-side, the majority of Web developers also write client-side code in JavaScript. In terms of the ubiquity angle, JavaScript is overwhelming overwhelmingly familiar and accessible to programmers coming from diverse background and technology camps.

That said, Web development on the server with JavaScript is still largely uncharted territory. There are few production-grade environments available for writing JavaScript Web applications on the server. A multitude of lesser-known projects exist, but few have picked up the momentum and community of more popular environments such as Ruby or Python.

As more richer and more complex application code is built in JavaScript on the client side, there is an increasing need to share code and development tools between the client and server. The Fluid community has built up an extremely productive toolset for developing usable and accessible interfaces with Infusion, our JavaScript application framework. As we extend our development efforts to Web services and server-side applications, a goal is to be able reuse as much of the infrastructure we've already got, lowering the cost and improving our productivity.

JavaScript on the server, while still on the bleeding edge, will provide us with an a broadly approachable environment for writing server-side code using many of the existing tools offered by Fluid Infusion.


With this plan to build first on Rhino and the JVM, and then move to a next-generation runtime as soon as they're ready, the obvious problem is portability. If we commit to Rhino now, will be able to move to V8 or Tracemonkey-based environment later?

The JSGI spec provides a solution to the portability issue. Modeled after Python's WSGI and Ruby's Rack, JSGI provides a simple contract for Web containers, specifying how requests and responses should be handled. JSGI is well-suited to JavaScript's functional style, and is relatively straightforward to implement. Several server-side JavaScript environments, including v8cgi, already support JSGI today, and it's expected that others will adopt it. By coding to JSGI, the Engage server-side technology can be trivially ported from Rhino + Servlets to v8cgi or another next-generative generation runtime.

Env.js for Browser Compatibility

One of the goals of JavaScript on the server is to provide a natural and easy-to-learn environment for developers who are familiar with client-side JavaScript programming in browsers. We'll also With this, we want to be able to reuse the existing Infusion components and framework without having to modify the code to run on the server.

John Resig's Env.js provides us with the ability to support common JavaScript browser features that are typically missing on the server, including the DOM, local and remote AJAX, and the use of libraries such as jQuery. Inevitably, only a subset of these tools will remain features are relevant on the server, but Env.js ensures maximal we can heavily reuse of existing code, making it easy to start developing in this new server-side environment quickly.

Tying it all Together: Kettle

The Engage services layer will weave together a variety handful of existing technologies to create a new server-side Web development framework called Kettle:

  • Rhino + Servlets for the Web container
  • JSGI for portability
  • Env.js for standard library features and browser compatibiltiy.
  • Infusion for application development

Using Rhino and Servlets, we can easily establish a JavaScript-based Web container, and we'll follow the JSGI spec to ensure its portability to v8cgi and other environments. Env.js will provide us with an interface for standard tasks such as making HTTP requests and file manipulation on the server, all wrapped in a browser-like API familiar to most JavaScript developers. Fluid Infusion will provide us with a framework for most common application framework features such as data binding and events.

The only substantial new code we'll need write is a URL routing scheme, most likely inspired by CherryPy's approach. With this, Kettle will offer a full-featured framework for server-side development.