XData with Aurelius TObjectManager

BIZ TMS XData
1

Hi,

I'm an active user of TMS Aurelius and currently investigating TMS XData. I tested some service operations with XData and that is working quite well. I have a little difficulty to understand the differences and similarities of the products XData, XData Service Operations and RemoteDB in relation to Aurelius.

My assumptions: (are they correct?)

1. RemoteDB is used to expose an SQL database and it does not use Aurelius (objects).
2. XData is used to expose Aurelius objects.
3. XData Service Operations is used to expose custom-made objects and behavior.

My question is about the 'normal' XData implementation (2). In the manual I see json filtering options described. Is this the only (and preferred) way to query for Aurelius objects via XData? I thought that XData was a remote and transparent interface to an Aurelius object model (manager). Instead it seems that XData is "just" another way to retrieve Aurelius objects, remotely.

Is the TObjectManager exposed through the XData interface? What I would like to do is to run Aurelius criteria remotely as if they are locally executed. That way it would be easy to migrate a local Aurelius project to a client/server XData solution.

For example:

Client := TXDataClient.Create;

Client.Uri := 'http://server:2001/tms/xdata';
Client.Manager.Find<TCustomer>

  .Add(TExpression.Eq('Country', 'US'))

  .Add(TExpression.Eq('Age', 30))

  .List;

I did not try this and I do not have source code available at the moment. Just trying to understand the different solutions provided by XData beforehand.

Any insight on this?
Thanks.

2

Your assumptions are almost correct. 

When you say in 3 that service operations are used to expose "custom-made objects", it's a little bit wrong. Because you use the same objects/classes of the item 2. The difference is only "behavior", but the objects and entities managed by both (2) and (3) are the same.

About your second question, it's our goal to reach that point. XData for now is "just" a way to publish Aurelius objects through Json/Rest. But this already is powerful since you have instant access from multi-platform clients in a standard way, including full query API.
The next step would indeed create a kind of TObjectManager that perform queries in this rest/json server instead of the database, and indeed use same Aurelius code for both client/server and multi-tier scenarios. But it's not implemented yet.
However, you have two very straightforward options so far:

1) XData offers the TXDataClient, which is a kind of TObjectManager. It's a high-level, strong-types interface to the XData server. It just doesn't behave like TObjectManager.
2) RemoteDB is your friend for quick and dirty switch between client/server - > multi-tier. That's its purpose, actually. As you said, it doesn't relate to Aurelius and is useful to migrate non-Aurelius client-server appliactions to the cloud. However, in the end it's just a way to access a database. So you can use RemoteDB as the database-access layer for Aurelius. Thus, the same Aurelius code using FireDac to access an SQL Server database in local network can use RemoteDB to access a database in the cloud without changing any line of code.

3

Thanks for your elaboration. But what I understand is that XData Service Operations does not rely on Aurelius objects. I can have service operation (remotable) objects without an existing Aurelius object-model / data-model, right? So with the exception of the (memory) database for authentication there is no need for a database connection or object-model.

This raises a new question. If I intent to only implement service operations with XData but i also have a Aurelius object/data model in my server implementation for internal operations only, does this model become automatically "exposed" to the json/rest connection?

I agree that RemoteDB is only a quick and dirty (but smart) solution for bringing legacy projects to client/server or the cloud. I already decided not to use RemoteDB for new projects. (It should be called RemoteLegacyDB by the way ;-)

XData querying via json/rest is indeed very powerful and I can understand your road-map decisions. There are no limitations on the kind of clients being used. However, coming from a Delphi client that already uses Aurelius criteria queries, it would be a huge improvement if there was a IObjectManager interface that could point to a local Aurelius object-manager implementation or a remote one. I'm looking forward to see this functionality in the future.

For now I will go for your option 1 and use the TXDataClient. I guess it will be very straightforward to rewrite the json queries to Aurelius object-manager queries when this becomes available.

4

In theory for XData Service Operations you could use it without any Aurelius object, but only with scalar types. But it's not the purpose. The idea IS to use Aurelius objects because it's amazingly easy and straightforward to receive/send Aurelius objects through it. All the threading, pooling, serializing, memory management is all automatically so you just receive a TCustomer and that's it.

Note that there ARE users using it without a real database connection. But the paradigm is still Aurelius: users create a new specific mapping model for those XData service operations (you can easily do it with [Model] attributes) and then create an in-memory SQLite database connection. So you have a "no-database" server but it's still benefits from Aurelius mapping/setup and its querying capabilities.

You can choose exactly what classes goes to each model and define which Aurelius model you want to use in each server.

RemoteDB is quick and dirty but note legacy. It's perfectly usable and fits needs. To give you an example my wife runs a pet store (but has another daily job) and I did a very simple application with Aurelius for her two years ago. Single computer, but I had to go there to get some reports. Now I took the time to move it to the cloud in an afternoon with RemoteDB, and now I can use the software from home, he can check from her other job, and it's easy to maintain, etc.. I have no need for XData or super-JSON-pure-Rest stuff. I will stay with RemoteDB, it fits perfectly.

Yes, idea is to have the IObjectManager and the switch will be straightforward. Note that as I say, that's what RemoteDB already does in a very easy way. It will just "feel better" (and be much more complicated). Unless of course you have strong corporate needs like many simultaneous users or need to access from other platforms.


5

"Yes, idea is to have the IObjectManager and the switch will be
straightforward. Note that as I say, that's what RemoteDB already does
in a very easy way. It will just "feel better" (and be much more
complicated). Unless of course you have strong corporate needs like many
simultaneous users or need to access from other platforms."

Are you saying that RemoteDB is suitable for cloud solutions with a few (say 10-15 simultaneous) users and XData is more suitable for cloud solution with 100+ users? Does this depend on the server-side implementation (XData versus RemoteDB) or purely on the client-side implementation (i.e. many inefficient table/query operations)?

Is RemoteDB with a Aurelius-based client suited for many concurrent users?

I meant to say that RemoteDB is great for bringing legacy database applications to todays (cloud) requirements. I know that RemoteDB is not legacy by itself. I did not think about the option to use RemoteDB for a modern Aurelius-bases application. That can be a solution but for the project that I am currently working on this might be too "heavy".

Lets say for example that  I need to implement a public newsreader solution with an free app / windows application and a cloud server with a FireBird server on Windows Server 2008. Would you recommend to use RemoteDB or XData and/or XData Service Operations.
 

6

For your example, I would recommend XData, especially because it's public and you might want to leverage other clients/platforms as well.

RemoteDB is well suited for many users as well, we have a customer that is using it in a place with 300 users, almost 100 simultaneous (note that they are not 100 simultaneous connections to the server, but just 100 desktop workstations working with the software - they might be in idle state).
What I mean is that RemoteDB can be used witih modern Aurelius applications as well. If you have some in-house software, that super high-level security is not a big issue, that will not scale to 5000 users, etc., then you might benefit to have it working right now with RemoteDB (note that RemoteDB is in theory also faster than XData because the traffic is just low-level, binary database data).
7

Hi to all,

firstly, thanks both of you because you have answered
some basic questions that I believe is for all new
aurelius/xdata/remotedb programmers.

I am at the design of a web
application and till know I selected the xdata/aurelius solution.
Moreover that last post of Wagner take me in deep thoughts if it is
worth it and should use remotedb.

But correct if I am wrong, if
someones uses RemoteDB will still have a heavy client because all the
logic will be at the client application?

Also scalability cannot be done...?

Thanks

8

Yes, in RemoteDB there is no server-side logic besides anything you might have in database server itself (triggers, stored procedures, etc.).

Again, XData and RemoteDB are very different things. With RemoteDB you are sill in the "client/server" paradigm. The only difference is that instead your client application sending the SQL statements directly to the database server, it sends it to RemoteDB which in turn forwards to the database server. RemoteDB is "just" a proxy that forwards the SQL statements to the database server and sends the dataset results back to the client. The big purpose and nice thing is you can easily make your application save data in the cloud in a way that works, given the accessing a database server directly in the cloud has a lot of drawbacks.

The scalability is a little bit harder because to keep the behavior of existing client/server application, RemoteDB needs to handle transactions so when the client begins a transaction, the transaction is kept open in the server, so in that case (and only that case) the server is stateful and the more clients connected with open transactions the more resources it take. But only in that case, if transactions are not active, the server is stateless.