What is Data Abstract?

In todays connected world, where customers have multiple devices across multiple platforms, it has become more important than ever to have a users data available to them where-ever they are in the world, regardless of the platform they happen to be using. They want to be able to interact with their data where-ever they are, be it on a mobile phone sitting at an Airport or working on a laptop at home. They want to use your application on their favorite devices, and they expect it work the same regardless of the device its on.

With that in mind, you have a lot of things to start considering when designing your app:

  • How you will handle communication between the tiers & platforms, and are you going to take a synchronous or asynchronous approach (or indeed both)?
  • How you will handle security?
  • Which database will you use, and how general you have to design so that you can change databases should your needs change?
  • On what platform you will stage your server tier?
  • Where will your main app logic reside; do you put it all on the client side, all in the middle tier, or a mixture of both?

Suddenly your exciting idea seems much more complicated and gets a bit lost in all of the mechanics you'll need to add to make it possible.

The Data Abstract framework helps you solve those and other problems that you haven't even considered yet. Data Abstract makes it easy to create multi-teir, database driven applications, allowing you spend more time focusing on the more important details of what makes your app so special rather than having to worry about communications protocols, data access or the database backend.

What exactly is Data Abstract?

In short, Data Abstract is a multi-platform framework that takes a multi-tier approach to data access. It is built a-top of Remoting SDK which we will explore more in a moment. The goal of the Data Abstract framework is to remove the development steps or headaches that you would encounter if you were creating a multi-tier application from scratch.

Looking at the list above, here are some of the ways that using Data Abstract would help you:

  • Communication - Data Abstract is available on 5 platforms and is written from scratch on each of those platforms. This allows us to easily ensure that each platform can communicate with the other. We provide a number of different channels which pass messages which can be particularly efficent in terms of speed and bandwidth. Lastly Data Abstract supports both Synchronous and Asynchronous communication.
  • Security - You have control over the channels, so you are able to create them as either SSL protected or AES encrypted channels. You also control the messages, so for testing you might pass completely reading plain text messages for ease of debugging.
  • Database Agnostic - Data Abstract is database agnostic. You can use whichever database you want and it will make no difference to the client applications. Using Relativity Server, supplied with Data Abstract, you can quickly select the Database you want to use, specify the schema and get working. Should you later decide that a better Database is more approriate, you can swap it out without any changes to the server or client code.
  • Wide Platform Support - As noted Data Abstract is available for 5 platforms covering .NET, Delphi, Cocoa, Java and JavaScript in terms of desktop and mobile development. Each version which comes with Relativity Server which can be run on Windows (.NET 3.5SP1 or greater), Linux or Mac OS X (using Mono 2.6 or greater).
  • Logic - Often in a client / server setup you would have the logic hard coded in each of the client platforms. This increases complexity in terms of development and testing. With Data Abstract we recommend having minimal logic in the client and instead move the business logic into the middle tier. There you can use our JavaScript feature that allows you to define business rules on a live server without the need to stop/start or compile and code.

Looking a little deeper

As mentioned above, Data Abstract is built on top of Remoting SDK communication framework. Indeed a Data Abstract server application is a Remoting SDK based server with database connection management, an efficient data exchange protocol and declaratively (i.e not in the program code) defined mapping between the database schema and the data structure exposed to the client applications. On the client side, Data Abstract provides components to simplify data access so there is no need to manually compose calls to the server or work directly with SQL.

Lets have a look at how this looks like:

As you can see the core Data Abstract components are:

  • The Data Adapter is a client-side component that encapsulates the calls needed to communicate with the server, be it remote or local.
  • The DataStreamer component, that is used on the client and server sides, serializes data requests, results and data update requests. Data Abstract provides a few Data Streamers, the most important of which are Bin2DataStreamer which exposes data using a highly efficient binary formant and JsonDataStreamer that uses the JSON format to exchange data. The JsonDataStreamer is particularly useful as it allows the exchange of data with platforms that we don't provide a Data Abstract client library for, for example PHP or Ruby server code.
  • The DataService is a predefined Remoting SDK service that exists in the middle tier and provides access to the database tables and handles the interaction between the Connection Manager, the Schema and the DataStreamer. In general there is no need to add any code to this service's definition.
  • The Schema describes the mapping1 between the underlying database tables and the data structures that are exposed to the server (which are called data tables). Any client applications you develop will only have access to the data exposed via the Schema tables, they never have direct access to the underlying database. To edit a schema you can use the Schema Modeler that is supplied with Data Abstract.
  • The ConnectionManager manages connections to the underlying database(s). It allows database connections to be pooled if the database's ADO.NET driver doesn't provide this feature, or when more precise control over the connection pool is needed.

See Also


  1. Note that Schema data table mappings are not necessarily a straight 1-to-1 mapping to the database tables. For example, it is possible to expose the result of an SQL SELECT statement as a Schema table and to handle any data updates applied to this Schema table using stored procedures. This approach allows data to be filtered on data access, do additional data integrity checks on data updates, etc., in a fashion that is completely transparent to the client application. Also, some database tables are not suited to be exposed as Schema tables.