2012-03-07

Interface based services - sample code

In addition to the other related blog articles, you can find in the "SQLite3/Samples/14 - Interface based services" folder of the supplied source code distribution, a dedicated sample about this feature.

Purpose of this code is to show how to create a client-server service, using interfaces, over named pipe communication.

Continue reading

Interface based services - Implementation details

You will find out in SQLite3Commons.pas all classes implementing this interface communication.

There are two levels of implementation:
- A services catalog, available in TSQLRest.Services property, declared as TServiceContainer (with two inherited versions, for each side);
- A service factory for each interface, declared as TServiceFactory (also with two inherited versions, for each side).

In fact, TServiceFactory.Create constructor will retrieve all needed RTTI information of the given interface, i.e. GUID, name and all methods (with their arguments). It will compute the low-level stack memory layout needed at execution. And the corresponding "contract" will be computed, to validate that both client and server expect the exact same interface.

On the server side, TServiceFactoryServer.ExecuteMethod method (and then a nested TServiceMethod.InternalExecute call) is used to prepare a valid call to the implementation class code from a remote JSON request.

On the client side, a TInterfacedObjectFake class will be created, and will emulate a regular Delphi interface call using some on-the-fly asm code generated in the TServiceFactoryClient.Create constructor.

Continue reading

Interface based services - Using services on the Client or Server sides

Once the service is registered on the server side, it is very easy to use it in your code.

In a complex Service Oriented Architecture, it is pretty common to have services calling each other. Code re-usability is a key here. So you'll have to consume services on the server side. According to the SOLID design principles, you'd better rely on abstraction in your code, i.e. not call the service implementation, but the service abstract interface.

You can use the following method of your TSQLRest.Services instance (note that this method is available on both client and server sides, so is the right access point to all services):

 function TServiceFactory.Get(out Obj): Boolean;

Continue reading

Interface based services - Server side

In order to have an operating service, you'll need to implement a Delphi class which matches the expected interface.

Continue reading

Interface based services - defining a data contract

In a Service Oriented Architecture, services tend to create a huge list of operations.
In order to facilitate implementation and maintenance, operations shall be grouped within common services.

The data contract is to be defined as a plain Delphi interface type.
In fact, the sample type as stated in a previous blog article can be used directly:

type
  ICalculator = interface(IInvokable)
    ['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}']
    /// add two signed 32 bit integers
    function Add(n1,n2: integer): integer;
  end;

This ICalculator.Add method will define one "Add" operation, under the "ICalculator" service (which will be named internally 'Calculator' by convention).
This operation will expect two numbers as input, and then return the sum of those numbers.

Continue reading

Interface based services

The Client-Server services via methods implementation (our DataSnap-like feature) gives full access to the lowest-level of the mORMot's core, so it has some advantages:
- It can be tuned to fit any purpose (such as retrieving or returning some HTML or binary data, or modifying the HTTP headers on the fly);
- It is integrated into the RESTful URI model, so it can be related to any table/class of our ORM framework (like DataAsHex service above), or it can handle any remote query (e.g. any AJAX or SOAP requests);
- It has a very low performance overhead, so can be used to reduce server workload for some common tasks.

But this implementation pattern has some drawbacks:
- Most content marshaling is to be done by hand, so may introduce implementation issues;
- Client and server side code does not have the same implementation pattern, so you will have to code explicitly data marshaling twice, for both client and server;
- The services do not have any hierarchy, and are listed as a plain list, which is not very convenient;
- It is difficult to synchronize several service calls within a single context, e.g. when a workflow is to be handled during the application process (you have to code some kind of state machine on both sides);
- Security is handled globally for the user, or should be checked by hand in the implementation method (using the aParams.Context values).

You can get rid of those limitations with the interface-based service implementation of mORMot. For a detailed introduction and best practice guide to SOA, you can consult this "classic" article.

According to this document, all expected SOA features are now available in the current implementation of the mORMot framework (including service catalog aka "broker").

Continue reading

2012-02-14

ORM cache

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 on any 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.

Continue reading

2012-02-06

Modification of TSQLRestServerCallBack method prototype (bis)

In order to implement some RESTful Services, a callback has to be defined on the server side.

The prototype of these methods has been modified one more time, to supply an unique parameter:
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).

Continue reading

2011-08-10

Framework documentation updated for revision 1.15

The framework documentation was just updated.

The general organization of the SAD document (which is the one to be read in all cases) has been refreshed, and is now separated in smaller chapters.

The new official name has been changed into "Synopse SQLite3/mORMot framework"...

Continue reading

2011-07-02

Is Object-Relational Mapping the Paradise of Computer Science?

There is a well known syndrome around, against ORM.

Do you remember The Vietnam of Computer Science article?

It is worth reading... and commenting.
Sounds a bit outdated by now. Tempus fugit!

Continue reading

2011-06-29

Synopse SQLite3 framework 1.14

Our ORM framework has been released as version 1.14.

It's mainly a bug-fix release:

  • Integrated SQLite3 engine updated to latest version 3.7.7.1;
  • Fix several issues about JSON generation layout;
  • Enhanced automated User Interface generation for object on-screen edition;
  • SynPdf unit now handles Bézier curves from TCanvas, and some CMYK functions; also enhanced PDF/A-1compatibility;
  • Some speed enhancements, and new functions for the SynOleDB unit.

Continue reading

2011-06-02

Fast JSON parsing

When it deals with parsing some (textual) content, two directions are usually envisaged. In the XML world, you have usually to make a choice between:
- A DOM parser, which creates an in-memory tree structure of objects mapping the XML nodes;
- A SAX parser, which reads the XML content, then call pre-defined events for each XML content element.

In fact, DOM parsers use internally a SAX parser to read the XML content. Therefore, with the overhead of object creation and their property initialization, DOM parsers are typically three to five times slower than SAX. But, DOM parsers are much more powerful for handling the data: as soon as it's mapped in native objects, code can access with no time to any given node, whereas a SAX-based access will have to read again the whole XML content.

Most JSON parser available in Delphi use a DOM-like approach. For instance, the DBXJSON unit included since Delphi 2010 or the SuperObject or DWS libraries create a class instance mapping each JSON node.

In a JSON-based Client-Server ORM like ours, profiling shows that a lot of time is spent in JSON parsing, on both Client and Server side. Therefore, we tried to optimize this part of the library.

Continue reading

BATCH sequences for adding/updating/deleting records

When use the so-called BATCH sequences?

In a standard Client-Server architecture, especially with the common understanding (and most implementations) of a RESTful service, any Add / Update / Delete method call requires a back and forth flow to then from the remote server.

In case of a remote connection via the Internet (or a slow network), you could have some 100 ms of latency: it's just the "ping" timing, i.e. the time spent for your IP packet to go to the server, then back to you.

If you are making a number of such calls (e.g. add 1000 records), you'll have 100*1000 ms = 100 s = 1:40 min just because of this network latency!

The BATCH sequence allows you to regroup those statements into just ONE remote call. Internally, it builds a JSON stream, then post this stream at once to the server. Then the server answers at once, after having performed all the modifications.

Continue reading

2010-10-23

Synopse SQLite3 Framework 1.10 - including engine 3.7.3

The Synopse SQLite3 Database Framework was just released under version 1.10:
- internal SQLite3 database engine is updated to version 3.7.3;
- code modifications to compile with Delphi 6 compiler;
- enhancements in TSQLRestServerStatic, for easier stand-alone work of this in-memory database engine;
- new SQLite3Edit unit, for automated creation of a UI window, ready to edit any TSQLRecord, with no RAD necessary (all components are created from RTTI): think this is an ORM for User Interface.

This version compiles from Delphi 6 up to Delphi XE.

Continue reading

2010-08-24

Synopse SQLite3 Framework 1.9.1

The Synopse SQLite3 Database Framework was just released under version 1.9.1:
- internal SQLite3 database engine is updated to version 3.7.2;
- new TSQLRecordFTS3 record, for using FTS3 virtual tables, i.e. implementing full-text search;
- new SQLite3UIEdit unit, to edit table content with a dialog created from RTTI;
- new dedicated BLOB methods and JSON array serialization;
- a lot of fixes and speed enhancements (including our HTTP/1.1 RESTful server now using Thread Pool).

The new 3.7.2 version of the SQLite3 engine, which is mandatory according to SQLite3's authors, is included.

Continue reading

2010-08-19

How to implement multi-tier architecture in our SQLite3 Framework

In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client–server architecture in which the presentation, the application processing, and the data management are logically separate processes. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of multi-tier architecture is the three-tier architecture.

Both ORM and RESTful aspects of our framework makes it easy to develop using such a three-tier architecture.

Continue reading

2010-07-02

JSON format of a RESTful application

RESTful JSON is still a buzzing process... there is no standard yet, and they should not be, since JSON itself has its own RFC, and REST is a powerful but vague statement.

Continue reading

2010-05-24

SQLite3 Framework version 1.7

Our SQLite3 Framework has been updated into the 1.7 version. For Delphi 7 to Delphi 2010.

Mostly User-Interface (reporting) enhancements, and some bug fixes.

Continue reading

2010-03-14

SQLite3 Framework version 1.5

Our SQLite3 Framework has been updated into the 1.5 version.

Continue reading

2010-02-08

SQLite3 Framework version 1.4

The framework has been updated, and is released now under the LGPL license (public domain license was found to be confusing).

Continue reading

- page 4 of 5 -