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