If you compare with existing client/server SOA solutions (in Delphi, Java,
C# or even in Go or other frameworks), mORMot's
interface-based
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
define one 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
contexts.
Our interface-based approach allows to gather all events:
- In a single
interface type 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
as 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
as var/out, as we will see below, inWorkflow
adaptation.
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...
.jpg)
