Synopse Open Source

2012-03-07

Interface based services - Implementation details

By AB4327-GANDI, 2012-03-07. Open Source › mORMot Framework

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.

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

By AB4327-GANDI, 2012-03-07. Open Source › mORMot Framework

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;

Interface based services - Server side

By AB4327-GANDI, 2012-03-07. Open Source › mORMot Framework

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

Interface based services - defining a data contract

By AB4327-GANDI, 2012-03-07. Open Source › mORMot Framework

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.

Interface based services

By AB4327-GANDI, 2012-03-07. Open Source › mORMot Framework

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").

2012-02-29

Delphi and interfaces

By AB4327-GANDI, 2012-02-29. Pascal Programming

No, interface(-book) is not another social network, sorry.

In Delphi OOP model, an interface defines a type that comprises abstract virtual methods.
The short, easy definition is that an interface is a declaration of functionality without an implementation of that functionality. It defines "what" is available, not "how" it is made available. This is the so called "abstraction" benefit of interfaces (there are another benefits, like orthogonality of interfaces to classes, but we'll see it later).

In its upcoming 1.16 revision, our mORMot framework is able to use interface for its service definition.

So we'll discuss and introduce this gem available in all modern languages - including Delphi: interfaces.

2012-02-14

ORM cache

By AB4327-GANDI, 2012-02-14. Open Source › mORMot Framework

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.

2012-02-09

Using SetLength or SetString

By AB4327-GANDI, 2012-02-09. Pascal Programming

Some Delphi users even do not know the existence of the SetString function.

As stated by the official documentation:

procedure SetString(var S: String; Buffer: PChar; Length: Integer);
For a long string variable, SetString sets S to reference a newly allocated string of the given length. If the Buffer parameter is not nil, SetString then copies Len characters from Buffer into the string; otherwise, the content of the new string is left uninitialized. If there is not enough memory available to create the string, an EOutOfMemory exception is raised. Following a call to SetString, S is guaranteed to reference a unique string (a string with a reference count of one).

Some have noticed that in our libraries, I sometimes use SetString instead of SetLength.
When the string is already allocated, it could be faster to use SetString, if you are sure that you will overwrite the string content.