N-Tier Model

Roberto Schneiders · 2013-01-29 15:48:43

Thinking of a n-tier structure, where the layers would Presentation, Application, Domain Model, Data Persistence, Cross-Cutting. As shown on page 58 of the documentation (1.18).

Is possible to run each tier on different computers? Of course the presentation layer runs on client machines. I refer to the server-side layers.

At first I thought of separating these layers in modules (BPL Packages) on my server. But what if the computer where the server is running does not have the resources to support all modules, I could put, for example, the data persistence layer (ORM) on another machine?

How would I do that?

The diagram in the documentation makes perfect sense to me. But I do not know how to organize the software modules in this way, could you give me an example?

In the software you maintain Arnaud, how you divide the application? You use BPL packages?

ab · 2013-01-29 16:32:07

You are right: N-Tier can be seen in two ways:
- Logical separation;
- Physical separation.

Physical separation may make sense - even if I doubt you would reach the CPU limits of a good server for most common apps, since mORMot is somewhat optimized.

Search for "Hosting" in the index, and you will find out that you can do almost what you want with mORMot.
You have to play with the TSQLRest classes, and create your servers on purpose.

Personally, I never use BPL packages, and always prefer plain executables.
mORMot creates small executables, which is much easier to work with.
If you separate your modules in several physical machines, you need several executables, by definition.
But since all is done at class initialization level, you can even use the very same executable, and run it on several machines, with proper parameters to instantiate the class you need.
That is, you can have the same executable be stand-alone, client, full server, services server, db server...

Roberto Schneiders · 2013-01-29 16:47:41

Thanks Arnaud.

I also do not like packages . But our project is really big, I need to evaluate this option .

That is, you can have the same executable be stand-alone, client, full server, services server, db server...

It was exactly what I was talking about.

Roberto Schneiders · 2013-02-01 10:03:58

Can I have two executables running ORM (server) on different computers?

ab · 2013-02-01 10:42:36

Roberto Schneiders wrote:

Can I have two executables running ORM (server) on different computers?

What do you mean exactly?
You can have even several executables running several ORM servers on the same or different computers.
You can even have several servers running in the same process/executable, e.g. to implement some gateways and balancing.
You can have several TSQLModel using the same tables, but used with several context, without any problem.

The only restriction is that the URI they have to use is registered and not used by another process (this is an obvious per-design limitation of sockets).
With http.sys server, you can define sub-URI, that is you can share the same base URI, if the TSQLModel.Root is unique per process.

Roberto Schneiders · 2013-02-01 10:50:18

It may be necessary have more than one machine providing access to ORM.

In that case I would have to enable the property EngineAddUseSelectMaxID? Or the servers communicate with each other?

Do you have any examples of how to implement this?

Is there any mechanism for load balancing?

ab · 2013-02-01 11:05:56

Now I get your question.

For the ORM part of it, you should better centralize the whole process on one server, just as you have one DB server.
It will make it more easy to work with.

You can then use gateways to access the main ORM server from any other remote servers, and/or expose your main server process with multiple protocols (e.g. HTTP for remote access, and named pipes for local communication between servers).
Take a look at the TSQLRestServerRemoteDB class:

  /// a REST server using a TSQLRestClient for all its ORM process
  // - this server will use an internal TSQLRestClient instance to handle
  // all ORM operations (i.e. access to objects)
  // - it can be used e.g. to host some services on a stand-alone server, with
  // all ORM and data access retrieved from another server: it will allow to
  // easily implement a proxy architecture (for instance, as a DMZ for
  // publishing services, but letting ORM process stay out of scope)
  TSQLRestServerRemoteDB = class(TSQLRestServer)
   (...)
  public
    /// initialize a REST server associated to a given TSQLRestClient instance
    // - the specified TSQLRestClient will be used for all ORM and data process
    // - the supplied TSQLRestClient.Model will be used for TSQLRestServerRemoteDB
    // - note that the TSQLRestClient instance won't be freed - caller shall
    // manage its life time
    constructor Create(aRemoteClient: TSQLRestClient;
      aHandleUserAuthentication: boolean=false); reintroduce; virtual;

What I like very much is not to expose the ORM itself, but expose some interface-based services to your clients with a dedicated HTTP server, then communicate with the ORM server in your "DMZ".

Roberto Schneiders · 2013-02-01 11:30:52

Now it's a bit clearer to me.

I will try to implement an example.

Thank you.

mORMot Open Source

#1 2013-01-29 15:48:43

N-Tier Model

#2 2013-01-29 16:32:07

Re: N-Tier Model

#3 2013-01-29 16:47:41

Re: N-Tier Model

#4 2013-02-01 10:03:58

Re: N-Tier Model

#5 2013-02-01 10:42:36

Re: N-Tier Model

#6 2013-02-01 10:50:18

Re: N-Tier Model

#7 2013-02-01 11:05:56

Re: N-Tier Model

#8 2013-02-01 11:30:52

Re: N-Tier Model

Board footer