Basics

As noted in the Relativity getting started to get started with an instance of the Relativity server locally, you can just run Relativity.exe (Windows) or Relativity.app (Mac OS X) as it was installed with your copy of Data Abstract. Once run it will be available on port 7099 and serving both the PCTrade2 and Simple sample databases.

The samples are available so you can quickly get started with learning how to use Data Abstract and writing clients for it. One you are familiar with Data Abstract and using & configuring Relativity, you can learn more about deploying Relativity to your server(s) or in the cloud.

As mentioned in the Relativity introduction, Relativity is the "shell" for a server that becomes useful only when you populate it with your own middle-tier configuration — much like a database server is not of much use without an actual database that contains data. Let's see what this looks like.

Domains

Just like a database server, or a web server, an instance of Relativity can host multiple, completely independent, middle-tier services. This allows you, for example, to host a single server to provide services for different projects, applications, or different customers. In essence, each instance of Relativity can be many servers at once.

In Relativity, each of these independent units is called a Domain which can be configured on its own — with its own connections to one or more databases and its own schemas and business logic scripts. By default, a new instance of the Relativity server starts out with two domains, the PCTrade sample domain that is used by many of the sample projects that ship with Data Abstract and the domain needed for the Simple samples.

Admin Login

But let's not get ahead of ourselves. Your first interaction when working with Relativity Server will be the Admin Login. This is the login you need to authenticate yourself with the server before you can view, change or create domains, or indeed do anything much with the server (aside from retrieving data — more on that below).

The default login for a fresh Relativity Server will be the username "Administrator" and the password "Relativity". (The password might differ if you are hosting Relativity in the Cloud, please refer to the detailed setup instructions for more information.)

There are two main places where you can use this login:

Once you connected and logged into Relativity Server, you can (and should) change the login, and optionally create additional logins for other members of your team. You can even change how login is handled by selecting a different Login Provider, if needed.

Remember that the Admin Login will give you and your team members full access to the entire server (much like a "root" user on an operating system, or the "sa" user on an SQL Server database system) though depending on how you configure things it may not be able to read the data in the Schemas.

Domains, Again

One of the main tasks you will perform as Admin is create new domains. On your development machine, you might create separate domains for each project you are working on; on production systems, you might just have a single domain for the entire server (or even across multiple servers), or you might host several domains for different customers.

What's important is that each domain is its own entity and completely segregated from the other domains, and aside from the admin, no login has access to more than one domain.

Which brings us to the per-domain logins. After you created a new domain, the first thing you will want to change or set is the domain's Developer Login.

The Developer Login

The developer login is what gives full access to configuring and creating the middle-tier logic (Schemas, Connection Strings, Business Rules Scripts, etc) that makes up the domain. You and your developers can use it to connect to Relativity Server from your development tools (including the IDEs, Schema Modeler and Server Explorer) to work with the domain.

The default developer login is the username "Developer" and the password "Relativity". Like the admin password, you will want to change this password after you create the domain, and you might also want to set up additional login names for your teammates, or any developers that should have access to this domain.

(Users who log in with the developer login will only have access to the set for this one domain; they cannot access other domains, nor can they delete the domain or add new ones. This makes it safe to host multiple domains on the same server, even if not every developer on your team should have access to all domains.)

Each domain also comes with a second set of logins, the Data Login.

The Data Login

The data login is what will be used by your client applications – in essence, your application's end users – to access the data. This login lets applications query, retrieve and update data (all within the rules you set forth, of course), but it does not allow access to the configuration of the domain, nor direct access to the back end database.

Because the Data Login often represents real end-users of your application(s), Relativity Server provides a lot of flexibility for how data access is authenticated, via its Login Providers.

By default, the data login is also set to a static login, with username "Data" and password – you guessed it – "Relativity", but in most cases you will not simply change this password, but instead choose a more dynamic login provider, such as one that reads users from the database.

It is important to realize the distinction between these two sets of logins:

  • Developer (and Admin) Login: Gives access to the configuration of your domain (or the full server), to you, your team and your sysadmins.
  • Data Login: Gives access to the data your middle tier is serving to your application's users.

But enough about logins, let's look at what make up a domain, which is essentially two things: Connection Strings and Schemas.

Connection Strings

A database middle tier is not much good without a database of course, and that is where connection strings come in. A connection string connects the domain to a back-end database – this can be a local database server run on the same machine as Relativity, or a database on a remote server or even in a cloud hosting system such as Amazon's RDS or Microsoft Azure.

A connection string is made up of two parts – a Driver name that identifies the type of database you're connecting to, and a list of parameters that depend on the database type, but usually include information such as a host name, a database name, a username and password.

Every domain needs at least one connection string (to be useful), but you can configure multiple ones, if the data for the domain comes from different databases.

Note: Because connection strings provide all the information that gives full access to the database, they are treated very privately, and once configured, cannot be accessed by users with a data login.

Read read more about Connection Strings and Drivers.

Schemas

More important than the connection are the schemas. Schemas, discussed in more depth here, are the heart and soul of a Data Abstract middle tier, as they define what data is vended by the server, how it is presented, and who can access and modify it, and with which restrictions.

Each domain can contain as many schemas as needed, and how your data is distributed between them is largely a matter of taste and an architectural decision. Smaller projects might just contain one schema that has all the tables; larger projects might group tables into separate schemas based on their function or origin. For example, a warehouse system might have one schema with customer and order information and another schema for inventory management.

You can create and manage schemas for your domain as you please, and you can launch into the Schema Modeler (Windows) or Server Explorer applications for editing and maintaining the schemas themselves. In fact, once Relativity is set up, Schema Modeler / Server Explorer will be the main tools you work with, aside form your IDE, when working with Data Abstract.

Read more on Schemas