Everything is Relative

Today i want to talk a bit about “Relativity”, a new feature we’re shipping with Data Abstract this month (and which is actually available as “tech preview”in the current Winter 2009 releases).

“Relativity” is, simply put, a standalone server application that can be used to host Data Abstract schemas and serve data. In essence, it provides the complete Data Abstract middle tier, in a precompiled box and ready run. This offers several benefits, not the least of which are:

  1. No need to build your own. Relativity provides all the power and abstraction of a true Data Abstract middle tier server, without you actually having to create, build, and deploy your own executable. This allows you to concentrate on the client development. It also is really handy for prototyping, if you just want to have database server to talk to, without much work, even if you plan to eventually implementing your own custom server.
  2. Build on Data Abstract for .NET. .NET is platform with the most advanced version of DA – it supports our powerful DA SQL execution engine, and other features not available on all platforms. “Relativity” is being made available to all users of Data Abstract, so whether you’re a developer using .NET, Delphi, or Xcode, you can now write clients against Relativity that take full advantage of these features.

But let’s go and take a more detailed technical look at Relativity.

Relativity is a server application, so it does not provide any user interface. You can deploy a Relativity server in several ways, including:

  • Running it as a regular user application, on Windows.
  • Installing it as a Windows service.
  • Running it as a Unix daemon with the mono-service2 tool, on Mac and Linux.
  • Running it as a menubar item, on Mac.

Regardless of how you deploy and run it, Relativity will start making it’s Data Abstract services available on (by default) port 7099. But of course before it can start serving actual data, it will need to be configured with what data to serve. That is done thru the Relativity Server Admin tool, which is currently available for Windows (but versions for both Mac and iPhone are in the works).

When you first start it, the Admin tool will look something like this:

Screen shot 2010-02-03 at 2.24.03 PM.png

On the left hand side, you will see a tree view with all known instances of “Relativity” servers. This includes any servers (local or remote) that you connected to in the past, as well as any servers discovered on the local network using ROZeroConf.

Select any of the servers (here, “VEMMY” is the one instance running in my Windows VM), to connect and get more options.

Screen shot 2010-02-03 at 2.30.01 PM.png

The first two nodes allow you to configure how this “Relativity” server is accessed. This includes options such as what ports to listen on, what RemObjects SDK channels and messages to use, etc. Here you have the full choice of all the options provided by RO, you can choose the familiar HTTP, TCP, Super HTTP or other channels, BinMessage, SOAP Message, and so on.

Where it gets more interesting is the third node – Domains. This is where you configure the meat of the services Relativity is providing.

Each Domain corresponds to what typically would be a separate Data Abstract middle tier server. Domains are completely abstracted from one another and Relativity allows you to host as many separate domains as needed. With that, a single Relativity server can replace multiple DA servers, be it for related to completely independent applications or projects.

As you can see, i have three domains set up in my server, one for “BC7″, our new bug tracking system (using a PostgreSQL database running on our Xserve build server), one for “RemObjectsCom”, the database that drives our website (Microsoft SQL Server, running on the Windows server that hosts our website), and finally “OneSpace”, the database for a personal iPad project i am working on.

As we drill into a specific domain, you start seeing more things that will be familiar to you as a Data Abstract developer. Each domain can contain one or more Schemas – which correspond directly to .daSchema files or TDASchema components as you know them. You can manage schemas right there in the Admin tool, or directly launch Schema Modeler to edit the schema in question:

Screen shot 2010-02-03 at 2.39.38 PM.png

The domain also maintains a list of Connections to back-end databases available to it’s schemas. Once again, this directly corresponds to the .daConnections file or TDAConnectionManager component. Since Relativity is based on DA/.NET, these connections are based on the available DA/.NET drivers – regardless of whether your regular development platform is .NET, Delphi or Cocoa.

Another interesting part is the Login node. Relativity provides several options for handling authentication from client applications for data access (something you would normally need to manually implement, in a standalone DA server): in addition to relying on a static list of allowed username/password combinations, you can also choose to use a data table or command defined in one of the domain’s schemas to verify users (as i do in the example shown below) or query an external LDAP server for login.

The LDAP option is very handy if you are running a variety of services – some using Relativity, and some not – that you want to share user data among. We recently switched to LDAP for all our employee resources, and it has made administration so much easier.

The LDAP support in Relativity is based on a new 100% managed LDAP client implementation we’ve added to Internet Pack for this upcoming release. Carlo will blog more about this, soon.

Screen shot 2010-02-03 at 3.05.53 PM.png

The Login Provider architecture is extensible, so you can implement your own providers, for example if you need to do user authentication with a different method.

Client Access

Once you have Relativity set up to serve your data, your client application(s) can access it like any other Data Abstract server.

The only slight difference is that, since a Relativity server can host more than one domain, you need to tell the server which domain to access, by simply passing an additional Domain parameter as your login string, as in

User=foo;Password=bar;Domain=DomainName

You will also want to select which Schema to query. in regular DA applications, each schema usually has its own DataService, so keeping in line with that, Relativity allows you to append a schema name to the ServiceName property of your Remote Service. Instead of using DataService, simply use DataService.DomainName. (Alternatively, you can also pass a Schema to LoginEx).

In Closing…

So, this has been a brief introduction to Relativity – i hope you found it useful.

We think of Relativity as a strategic piece of Data Abstract, and it will play an increasing part in what we do for DA. We have lots of things planned for the future that will make Relativity even more powerful, such as our upcoming JavaScript Business Rules Scripting based on Carlo’s RemObjects Script for .NET.

You can try out the tech preview of Relativity now, and the official release will be part of what we ship at the end of this month. I’m looking forward to your thoughts and feedback!

marc

by marc hoffman, February 3rd, 2010

8 Responses to “Everything is Relative”

  1. Bjarte says:

    Relativity looks very interesting. In our current project we need to filter DataTables in addition to business rules so Relativity was not an option. But I think we will use it for other readonly services.

    Is filtering on DataTables something you may support through business rules?

    • marc hoffman says:

      Yes, this is definitely something you’ll be able to do with Business Rules Scripting when that ships in the Summer.

      The easies option probably being to add a DynamicWhere to your tables in code. That’s how we solve per-user issue access in or internal bug tracking system (which is not using Relativity, but will provide one of the baselines for what we’ll expect DA Scripting to be able to do)

  2. Robert Giesecke says:

    Hi,

    doesn’t that mean, that one cannot use any non-trivial business logic whatsoever, except for what I put into my selects or DML?

    I’m a bit out of touch wrt DA, so pardon my probably ignorant questions…
    Are there roles that can be used in the schema and then, in Relative, mapped onto whatever security setting is chosen?
    I am thinking about e.g. ActiveDirectory for role membership (Map role X from the Schema to AD role Y) and Kerberos/SSPI for authentication.
    Are multiple authentication methods supported? Like username/password over LDAP for external access and SSPI for painless(=password-less) intranet access?
    Thus allowing the client’s IT department to integrate it into their corporate role/security scheme.

    Or did I get it completely wrong and is the security tab just for authentication and there’s no authorization? But how could that be used in real world scenarios?

    • marc hoffman says:

      Business Logic: for the Spring release, this will mean limited business logic only, yes. in May, we’re panning to ship Scripting support for DA/.NET, which means you will be able to write javaScript business rules for the client and inside the Schema, which Relativity will be able to run.

      Roles support is another thing on the list. We added Roles to RO last year (ie on service level), and we wanna expand that to DA later this year. Again, this will be all Schema driven, and of course accessible from your business logic scripts as well.

      Currently, relativity does LDAP for authentication (in addition to DB and static set of users), but the APi is pluggable. you could write tour own login module using, say AD, and we might provide others out of the box in the future. LDAP and AD roles could integrate with the RO/DA roles system, of course.

      Multiple logins and SSPI would be something we need to look into. i’d appreciate if you could report his as a feature request on the beta groups.

      hth,
      marc

  3. Greg says:

    Is the relativity server capable of handling server side methods like we use with RO in conjunction with DA.  Meaning sometimes we have a server side method that does a fair amount of db work and then returns either a simple result or sometimes more complex result. 
    Should we look at relativity server is really just a data access provider with some business rules capability… but no method calling?

    Thanks

    • marc hoffman says:

      yes, Relativity as it stands now will host database schemas (starting May, including Business Rules Scripts) only, no custom code. If you want/need custom code and RO services, a custom server is the right choice.

      • Greg says:

        Good deal… definitely plenty of room for non-custom servers! Will do some testing in the near future.

        Thanks

  4. [...] server in Delphi, access that from a Delphi Client and we additionally show you how to create a Relativity-hosted DA server, access this via REST from a browser and at the same time from a native Mac [...]

Leave a Reply