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