Goals & Criteria
- Broadly approachable
- Hit the ground running
- Scalable and forward-looking
- Fits the approach of the Fluid community: functional, declarative, Web-oriented
A broadly approachable services layer technology lets us reach out to a large number of Web developers, allowing them to get involved in the Engage community and technology using skills and languages they may already be familiar with. Similarly, the Fluid community itself needs to hit the ground running with Engage, building the services layer in technologies that are familiar and will get us coding with minimum ramp-up time.
Interoperability is a primary goal of Engage, ensuring that our technologies will work with a wide range of existing authoring tools, content management systems, and other tools commonly found in museums and on the Web. The Engage services layer needs to fit in well and leverage open standards wherever possible.
At the same time, our choice for server-side technology needs to be scalable and forward-looking, allowing museums to invest in Engage over long run, without fear that our services will slow down impossibly when confronted with large collections, and that they won't quickly go obsolete.
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.
Some Quick Background Information
Our aim was to find a language and accompanying framework that fit both the technological needs of our users and the culture of our development community. Throughout the process, we carefully examined both features and the wider context: the associated community, documentation, and support.
In-depth information about our approach to evaluating technologies, along with our observations, is available at the Fluid Engage Server-side Technology Notes page.
CouchDB and Lucene
Data Feeds and CouchDB
There is an incredible amount of diversity among museums in terms of how they each organize their collections and structure their data. Each museum's collection is different, and it is a daunting and risky task to attempt to force all types of collections into a single schema. Engage will need to embrace this diversity; rather than creating a "one size fits all" approach at the database level, we'll take a flexible approach to schemas in Engage.
Given that we can't pre-bake the data model completely, a standard SQL-based relational database in 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.
Data in Couch is queried and persisted using a RESTful API: fetching data requires a standard HTTP GET request, while adding or updating documents is just a PUT or POST operation. This means that Couch can be used with any programming language without required native database drivers. It's also an excellent fit for a RESTful service-oriented architecture. For museums that already have their own databases or CMS systems, Couch can be replaced with a custom service that provides the same RESTful operations and feeds as provides by the Couch Views that will ship out of the box with Engage.
Written in Erlang, Couch is extremely scalable and can meet the requirements of massive, complex collections and exhibit data.
Free Text Searching With Lucene
We'll also need to support free text searches. The most viable open source technology for this is Apache's Lucene and its associated Solr project. Solr is a standalone packaging of the underlying Lucene search engine. Whilst this is also capable of searching semi-structured data as for CouchDB, it excels particular at supporting free-text searches amongst larger document sets. Solr defines a standard wire protocol (with both XML and JSON APIs) for search and update, and so whilst dependent on Java hosting, need not commit to a Java-based core engine.
Portability and JSGI
Next Generation Runtimes
Rhino and the JVM
Tying it all Together