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.
