EKON 24 just finished. "The conference for Delphi & more" was fully online this year, due to the viral context... But this was a great event, and I am very happy to have been part of it. Please find the slides on my two sessions: mORMot 2 Performance: from Delphi to AVX2 Of course, […]
Last weeks, we introduced REST, ORM and SOA process in the mORMot2 repository.
During this phase, we split the huge
mORMot.pas unit into several
mormot.soa.*.pas units, to follow SOLID principles.
But we also renamed the base types into something more consistent and easier to work with.
After having enjoyed EKON 21 conferences in Köln, some quick post to share material about my presentations. MicroServices: SOLID Meets SOA MicroServices: Event-Driven Design Practical Domain-Driven Design I also included the "Practical DDD" source code in a new sample folder of the mORMot […]
EKON20 is now over, and there was a lot of people, great speakers, beautiful T-Shirt, and fresh beer! I've published the slides of my mORMot conferences on SlideShare... EKON20 From RAD to SOA with mORMot EKON20 mORMot Legacy Code Technical Debt Delphi Conference EKON20 Ride a mORMot EKON20 2016 […]
If you compare with existing client/server SOA solutions (in Delphi, Java,
C# or even in Go or other frameworks), mORMot's
callback mechanism sounds pretty unique and easy to work with.
Most Events Oriented solutions do use a set of dedicated
messages to propagate the events, with a centralized Message
Bus (like MSMQ or
JMS), or a
P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to
class per message, the
class fields being
the message values. You would define e.g. one
class to notify a
successful process, and another
class to notify an error. SOA
services would eventually tend to be defined by a huge number of individual
classes, with the temptation of re-using existing classes in several
interface-based approach allows to gather all events:
- In a single
interfacetype per notification, i.e. probably per service operation;
- With one method per event;
- Using method parameters defining the event values.
Since asynchronous notifications are needed most of the time, method
parameters would be one-way, i.e. defined only
const - in such case, an evolved algorithm would
transparently gather those outgoing messages, to enhance scalability when
processing such asynchronous events. Blocking request may also be defined
var/out, as we will see below, inWorkflow
Behind the scene, the framework would still transmit raw messages over IP
sockets (currently over a
WebSockets connection), like other systems, but events notification would
benefit from using interfaces, on both server and client sides.
We will now see how...
One year ago, we published a set of slides about the main concepts implemented by our framework. Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work. Worth a look, if you want to find out the benefits […]
2015-05-03. Pascal Programming
I've just updated the documentation part about the SOLID Design
The former blog article (almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.
Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.
The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):
- Single responsibility principle: the notion that an object should have only a single responsibility;
- Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
- Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
- Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
- Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).
If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.
They certainly help to fight the three main code weaknesses:
- Rigidity: Hard to change something because every change affects too many other parts of the system;
- Fragility: When you make a change, unexpected parts of the system break;
- Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.
Usually, in Delphi application (like in most high-level languages), errors
are handled via exceptions. By default, any
raised on the server side, within an
method, will be intercepted, and transmitted as an error to the client side,
then a safe but somewhat obfuscated
will be raised on the client side, containing additional information serialized
You may wonder why exceptions are not transmitted and raised directly on the client side, with our mORMot framework interface-based services, as if they were executed locally.
We will now detail some arguments, and patterns to be followed.
When publishing SOA services, most of them are defined as
stateless, in a typical query/answer pattern - see
Service-Oriented Architecture (SOA).
This fits exactly with the RESTful approach of Client-Server services via interfaces, as proposed by the framework.
But it may happen that a client application (or service) needs to know the state of a given service. In a pure stateless implementation, it will have to query the server for any state change, i.e. for any pending notification - this is called polling.
Polling may take place for instance:
- When a time consuming work is to be processed on the server side. In this case, the client could not wait for it to be finished, without raising a timeout on the HTTP connection: as a workaround, the client may start the work, then ask for its progress status regularly using a timer and a dedicated method call;
- When an unpredictable event is to be notified from the server side. In this case, the client should ask regularly (using a timer, e.g. every second), for any pending event, then react on purpose.
It may therefore sounds preferred, and in some case necessary, to have the ability to let the server notify one or several clients without any prior query, nor having the requirement of a client-side timer:
- Polling may be pretty resource consuming on both client and server sides, and add some unwanted latency;
- If immediate notification is needed, some kind of "long polling" algorithm may take place, i.e. the server will wait for a long time before returning the notification state if no event did happen: in this case, a dedicated connection is required, in addition to the REST one;
- In an event-driven systems, a lot of messages are sent to the clients: a proper publish/subscribe mechanism is preferred, otherwise the complexity of polling methods may increase and become inefficient and unmaintainable;
- Explicit push notifications may be necessary, e.g. when a lot of potential events, associated with a complex set of parameters, are likely to be sent by the client.
Our mORMot framework is therefore able to easily implement
asynchronous callbacks over WebSockets,
defining the callbacks as
interface parameters in service method
definitions - see
Available types for methods parameters.
In a previous
article, we presented how Master/Slave replication may be easily
implemented in mORMot's RESTful ORM.
Do not forget to visit the corresponding paragraphs of our online documentation, which has been updated, and is more accurate!
Sometimes, the on-demand synchronization is not enough.
So we have just introduced real-time replication via WebSockets.
For instance, you may need to:
- Synchronize a short list of always evolving items which should be reflected as soon as possible;
- Involve some kind of ACID-like behavior (e.g. handle money!) in your replicated data;
- Replicate not from a GUI application, but from a service, so use of a
TTimeris not an option;
- Combine REST requests (for ORM or services) and master/slave ORM replication on the same wire, e.g. in a multi-threaded application.
In this case, the framework is able to use WebSockets and
asynchronous callbacks to let the master/slave replication - see
Asynchronous callbacks - take place without the need to ask explicitly
for pending data.
You would need to use
TSQLRestServer.RecordVersionSynchronizeSlaveStop methods over the
proper kind of bidirectional connection.
2014-07-12. Pascal Programming
Cape Cod Gunny just wrote a blog article about how to replace a global variable by a static class instance.
But I had to react!
Using such static declaration is just another way of creating a global variable.
This is just a global variable in disguise.
In fact, the generated asm will be just like a global variable!
It encapsulates the global declaration within a class name space, but it is
still IMHO a very wrong design.
I've seen so many C# or Java code which used such a pattern (there is no global variable in those languages), and it has the same disadvantages as global variables.
Just like the singleton syndrome,
Code is just not re-entrant nor thread-safe.
Nightmare to debug and let evolve.
It comes to my mind what mORMot can offer.
We did not want to compare the features or say that one framework is better than the other, but it appeared to me that a lot of object pascal programmers are tied to 20th century programming model.
In fact, to embrace the potentials of mORMot, you need to switch your mind, and enhanced your RAD and OOP background, into 21th century SOLID model.