2012-03-28
2012-03-28. Open Source › mORMot Framework
As stated by this previous article, the default answer format is a valid JSON object.
In some cases, it may be useful to have a service operation (i.e. an interface method) returning any content, e.g. some plain TEXT, HTML or binary data (like a picture).
2012-03-07
2012-03-07. Open Source › mORMot Framework
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.
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.
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;
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.
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.
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").
