Incapture Technologies

Inside the Cloud

Incapture Technologies Blog


General overview of Rapture

October 13, 2014

In this series of posts I’ll be describing our platform product “Rapture” in great detail. This post is intended to set the scene and define the roadmap of the future posts you can expect to see.

At its core Rapture is a common platform for building applications in a distributed environment. The goal of Rapture is to allow the users who build applications to remain independent of the underlying infrastructure used to host the application environment. If (for non-functional reasons such as performance) an application needs to use something like Cassandra to store data instead of a relational database then the goal of Rapture is to allow that to happen with little to no changes in Application code.

A further goal of Rapture is to take care of a lot of the common application aspects that are commodity or boilerplate – entitlements, audit trails, devops, release management and deployment should be consistent and common between all applications that run on a Rapture platform.

Rapture in Financial Services

Rapture at its core has no “bindings” to financial services – although it was designed to be used to explicitly build Financial Services applications. Nevertheless Rapture has a very open extensible architecture and through these entry points Incapture has built a suite of extensions that connect a Rapture platform to common financial end points and data sources such as Bloomberg, Reuters and State Street along with a data model and an analytics framework for pricing and analyzing complex financial assets.

Incapture Technologies’ sister company, Incapture Investments, uses this Financial Services based Rapture platform to help manage their AlphaCapture fund.

Rapture in Detail

Over the next few months a series of blog posts (in this “Rapture Series”) will take you on a journey that will cover nearly all aspects of Rapture in some detail. The diagram below shows the general architecture of Rapture:

Rapture Diagram

Our journey will begin with a series of posts on repositories – places in Rapture that you can store or reference information that your application needs. We split repositories in Rapture into four different flavors (or types) and we’ll cover each type in a different post. The next post will be based on Document Repositories and then we’ll cover Series, Blob and Sheets.

An important part of the “glue” in a Rapture system can involve scripting of small programs that perform relatively simple activities on the platform. A description of the Rapture scripting language (called Reflex) will follow the repository posts.

Although you can create quite sophisticated applications using the simple scripting language most users will want to build (or adapt) applications that need to connect to Rapture through an API. Rapture’s API can be called from nearly any client side language and we’ll discuss how this works and how you can create your own custom APIs.

As we move beyond applications calling into Rapture we’ll start describing how Rapture applications can talk to each other in a controlled way. Rapture has facilities such as pipelines (messaging) and workflows that help coordinate this activity. There is also a part of the platform that gives application builders the ability to invoke their client side application from a workflow (ExecServer) and we’ll cover that in a later post. Our sister company Incapture Investments uses this technique to invoke their Python based research models in a controlled way in production.

The cloud based deployment paradigm of Rapture also encourages more use of web based applications. A post will be dedicated to describing how a combination of the Rapture API and the scripting language can be used to create a clear division of responsibility between that of the web browser application and the server side application services. These techniques are used within Rapture itself to provide the developer operations consoles for managing a Rapture environment.

Finally, towards the end of this series, a set of blog posts will cover the more operational side of running a Rapture environment. These posts will cover how to get data into Rapture, how to release and deploy applications in the environment, how to manage audit trails and the “provenance” of data and how to manage entitlements. We’ll also describe how to extend Rapture across many different dimensions.

I hope you’ll enjoy finding out more about Rapture over the next couple of months of blog posts. If you want to find out more early you can either email me directly (Alan Moore) or make a general enquiry through the Contact page of this web site.


Subscribe for updates