I've uploaded two sets of slides from my presentations at EKON 22 : Object Pascal Clean Code Guidelines Proposal High Performance Object Pascal Code on Servers with the associated source code The WorkShop about "Getting REST with mORMot" has a corresponding new Samples folder in our […]
We have just released a set of slides introducing ORM, SOA, REST, JSON, MVC, MVVM, SOLID, Mocks/Stubs, Domain-Driven Design concepts with Delphi, and showing some sample code using our Open Source mORMot framework. You can follow the public link on Google Drive! This is a great opportunity to […]
Our mORMot framework tries to implement security via:
- Process safety;
Process safety is implemented at every n-Tier level:
- Atomicity of the SQLite3 database core;
- RESTful architecture to avoid most synchronization issues;
- ORM associated to the Object pascal strong type syntax;
- Extended test coverage of the framework core.
Authentication allows user identification:
- Build-in optional authentication mechanism, implementing both per-user sessions and individual REST Query Authentication;
- Authentication groups are used for proper authorization;
- Several authentication schemes, from very secure SHA-256 based challenging to weak but simple authentication;
- Class-based architecture, allowing custom extension.
Authorization of a given process is based on the group policy,
after proper authentication:
- Per-table access right functionalities built-in at lowest level of the framework;
- Per-method execution policy for interface-based services;
- General high-level security attributes, for SQL or Service remote execution.
We will now give general information about both authentication and authorization in the framework.
In particular, authentication is now implemented via a set of classes.
I'm happy to announce that mORMot units are now compiling and working great in 64
bit mode, under Windows.
Need a Delphi XE2/XE3 compiler, of course!
ORM and services are now available in Win64, on both client and
Low-level x64 assembler stubs have been created, tested and optimized.
UI part is also available... that is grid display, reporting (with pdf export and display anti-aliasing), ribbon auto-generation,
SynTaskDialog, i18n... the main SynFile demo just works
Overall impression is very positive, and speed is comparable to 32 bit version (only 10-15% slower).
Speed decrease seems to be mostly due to doubled pointer size, and some less
optimized part of the official Delphi RTL.
But since mORMot core uses its own set of functions (e.g. for JSON serialization, RTTI support or interface calls or stubbing), we were able to release the whole 64 bit power of your hardware.
Delphi 64 bit compiler sounds stable and efficient. Even when working at low
level, with assembler stubs.
Generated code sounds more optimized than the one emitted by FreePascalCompiler - and RTL is very close to 32 bit mode.
Overall, VCL conversion worked as easily than a simple re-build.
Embarcadero's people did a great job for VCL Win64 support, here!
A new mORMot user notified on our forum that he just made a short video, about authentication and security with our framework, from the perspective of an AJAX Client. Many thanks for sharing your experiences! This video illustrate how RESTful authentication is implemented by mORMot. It compares also […]
Aim is to implement notification events triggered from the server side, very easily from Delphi code, even over a single HTTP connection - for instance, WCF does not allow this: it will need a dual binding, so will need to open a firewall port and such.
It will be the ground of an Event
Collaboration stack included within mORMot, in a KISS way.
Event Collaboration is really a very interesting pattern, and even if not all your application domain should be written using it, some part may definitively benefit from it.
The publish / subscribe pattern provides greater network scalability and a more dynamic SOA implementation: for instance, you can add listeners to your main system events (even third-party developed), without touching your main server.
Or it could be the root of the Event Sourcing part of your business domain: since callbacks can also be executed on the server side (without communication), they can be used to easily add nice features like: complete rebuild, data consolidation (and CQRS), temporal query, event replay, logging, audit, backup, replication.
If you discovered the mORMot framework, you may have found out that its implementation may sound restricted, in comparison to other ORMs, due to its design. It would be easy to answer that "it is not a bug, it is a feature", but I suspect it is worth a dedicated article.
Some common (and founded) criticisms are the following (quoting from our
forum - see e.g. this
- "One of the things I don't like so much about your approach to the ORM is the mis-use of existing Delphi constructs like "
index n" attribute for
the maximum length of a string-property. Other ORMs solve this i.e. with
- "You have to inherit from
TSQLRecord, and can't persist any
- "There is no way to easily map an existing complex database".
I understand very well those concerns.
Our mORMot framework is not meant to fit any purpose, but it is worth understanding why it has been implemented as such, and why it may be quite unique within the family of ORMs - which almost all are following the Hibernate way of doing.
In a discussion with Henrick Hellström, in Embarcadero forums, I wrote some high-level information about mORMot.
It was clear to me that our little mORMot is now far away from a simple Client-Server solution.
The Henrick point was that with Real Thin Client (RTC), you are able to write any Client-Server solution, even a RESTful / JSON based one.
He is of course right, but it made clear to me all the work done in
mORMot since its beginning.
From a Client-Server ORM, it is now a complete SOA framework, ready to serve Domain-Driven-Design solutions.
Here is the definition of "cache", as stated by Wikipedia:
In computer engineering, a cache is a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes.
To be cost efficient and to enable an efficient use of data, caches are relatively small. Nevertheless, caches have proven themselves in many areas of computing because access patterns in typical computer applications have locality of reference. References exhibit temporal locality if data is requested again that has been recently requested already. References exhibit spatial locality if data is requested that is physically stored close to data that has been requested already.
In our ORM framework, since performance was one goal since the beginning, cache has been implemented at four levels:
- Statement cache for reuse of SQL prepared statements, and bound parameters on the fly - note that this cache is available not only for the SQlite3 database engine, but also for any external engine;
- Global JSON result cache at the database level, which is flushed globally
INSERT / UPDATE;
- Tuned record cache at the CRUD/RESTful level for specified tables or records on the server side;
- Tuned record cache at the CRUD/RESTful level for specified tables or records on the client side.
The prototype of these methods has been modified one more time, to supply an
This is a CODE BREAK change and you shall refresh ALL your server-side code to match the new signature.
This unique parameter will let the signature remain untouched in your code implementation, even if the framework evolves (like adding a new parameter).
It seems to work well, and implements all secure hashing and
Our authentication mechanism is much more advanced than the one used by DataSnap - which is a basic HTTP authentication with the password transmitted in clear (this is the reason why it shall better be used over HTTPS, whereas mORMot can be used over plain HTTP).
The server side call back signature changed since this article was first published in 2010.
Please refer to the documentation or this forum article and associated commit.
The article was totally rewritten to reflect the enhancements.
And do not forget to see mORMot's interface-based services!
Note that the main difference with previous implementation is the
signature of the service implementation event, which should be now
procedure MyService(Ctxt: TSQLRestServerURIContext);
(note that there is one unique
class parameter, with no
Please update your code if you are using method-based services!
You certainly knows about the new DataSnap Client-Server features, based on
JSON, introduced in Delphi 2010.
http://docwiki.embarcadero.com/RADStudi … plications
We added such communication in our mORmot Framework, in a KISS (i.e. simple) way: no expert, no new unit or new class. Just add a published method Server-side, then use easy functions about JSON or URL-parameters to get the request encoded and decoded as expected, on Client-side.
Commonly, it can be achieved, in the SOA over HTTP world via:
- HTTP basic auth over HTTPS;
- Cookies and session management;
- Query Authentication with additional signature parameters.
We'll have to adapt, or even better mix those techniques, to match our framework architecture at best.
Each authentication scheme has its own PROs and CONs, depending on the purpose of your security policy and software architecture.