Introduction to the Exam App Reference Implementation

Examinator is an application reference implementation in the form of a test-proctoring application. It is used to illustrate the use case in which adding Terracotta to a clustered user-session application also incorporates some valuable and desirable cluster characteristics:

• High-availability – Significant reduction in cluster downtime
• Scale-out – Ability to adapt to growing load
• Database offload – Substantial gains in speed and efficiency

At its core, Examinator is an example implementation of what we call the user session pattern whereby conversational state across multiple requests is made transparently durable using simple Java data structures and an intuitive and natural application programming model. In the process, we also implemented a few other patterns including application session and data caching. The application architecture is an example of a "stateful" programming model that scales as well or better than a more complex and less intuitive "stateless" programming model. This exam application is the first of many such implementations that we plan to deliver in the coming months.

To learn about these patterns in Terracotta solutions, see the solutions page.

Why Did We Build It?

We developed the exam application reference implementation for a few reasons. The most obvious reason was to provide an example of a reasonably full-fledged application that uses Terracotta for high availability and scale. There's nothing like real code to explain how things work. From this example, we expect application developers with similar applications to get a very clear picture of how Terracotta fits into their use case.

We also wanted to document the process of building an application with Terracotta. Because Terracotta is such a unique and powerful way of delivering distributed computing capabilities, it may not be well understood how to go about planning for and living with Terracotta. You can think of the process sections of this reference implementation documentation as a documentary of sorts about life with Terracotta. From this process, we have gleaned recommendations, how-to guides, and best practices for integrating Terracotta into your software development process.

Another benefit of developing a reference implementation of an application with Terracotta is to "take our own medicine," so to speak. There's nothing like using the technology you build to speed up the cycle of improving that technology. By living day to day with our own Terracotta-enabled application, we expect to bring accelerated improvements to all aspects of Terracotta from which all of our users can benefit.

Implementation

In our planning stages, we sought out the best technologies for the task of building the application, including development frameworks, containers, and build and test tools. We believe that a major benefit of Terracotta is as a distributed computing service that is as unintrusive as possible so that you, the developer, can get on with the business of coding the features of your application rather than burn precious project time on scale and high availability. Therefore, we strove to assemble these technologies in a way that maximizes developer productivity, code testability and maintainability, and fit them together so that Terracotta finds a natural place in the developer toolset and the software development lifecycle.

We believe strongly that an application isn't done unless it has an accompanying suite of automated tests that can be easily run, maintained, and augmented to ensure the ongoing integrity of the code. In keeping with our convictions, we developed a test suite and a build and test system in tandem with the application.

Automated functionality testing, however, isn't good enough. In order to know whether an application is truly production ready, performance testing and destructive testing must be performed. We have also built such tests and documented our procedures so that you might apply those same methodologies to make your application crazy fast and resilient.

Of course, we don't consider ourselves to have the last word in good development and testing practices. As always, we are open to feedback and suggestions on improving the processes and tools that you find here. Please don't hesitate to share your ideas with the Terracotta community.

How To Use And Derive Benefit From The Reference Implementation

First and foremost, we expect the reference implementation to be an example of a good approach to building this kind of application in the presence of Terracotta. By providing a toolset, a suggested technology stack, architecture patterns, and best practices documentation, we believe this reference implementation serves as an excellent example for using Terracotta in your own application.

If you are starting your application from scratch, you can use the reference implementation code as a starting point and modify it to your specific needs. If you have an existing application, you can use it as a guide for building Terracotta best practices into your project, taking just parts you need.

Next Steps

In the next section, we introduce the technology stack components to give you an immediate sense of how the reference implementation is put together.