An event reports that a change has been applied to a thing entity. Important is the “past tense” here; it took already place (it was for example persisted into the data store) and cannot be reversed or stopped.
Example: A property value of a feature is modified.
In our service, events are just a sub-type of what Eclipse Ditto defines as Signal.
A signal combines common functionality of
Error Responses and
Such common functionality is for example that all those have header fields in which they can be for example correlated to each other.
People request changes to the domain by sending commands. They are named with a verb in the imperative mood plus and may include the aggregate type, for example ConfirmOrder. Unlike an event, a command is not a statement of fact; it’s only a request, and thus may be refused. (A typical way to convey refusal is to throw an exception).
An event represents something that took place in the domain. They are always named with a past-participle verb, such as OrderConfirmed. It’s not unusual but also not required for an event to name an aggregate or entity that it relates to; let the domain language be your guide.
Since an event represents something in the past, it can be considered a statement of fact and used to take decisions in other parts of the system.
Within the Bosch IoT Things service, we distinguish various categories of events and respectively their audiences:
(e.g. thing created, thing deleted)
These messages are forwarded to all subjects with read permission at the Thing level.
(e.g. update of a value for a thing attribute, feature, feature property etc.)
These messages are forwarded to all subjects with read permission.
(e.g. update of the Access Control List entries)
These messages are not forwarded to external subscribers.
If your application employs a Java client, you might be also interested in further details described at https://www.eclipse.org/ditto/client-sdk-java.html.
A Claim notification is not an event, but a special message for so-called claiming. It can be used to request access on things on which a user had no access yet. This message is dispatched to the client affording ownership w/o any permission check, and the solution implementation is responsible to handle this message.
As soon as your application has permission to read about any change of a thing entity, it will be sent such events.
However, in case you are not interested in all of these events, you can apply either a more fine-grained policy, or some filtering.
Find further details at Protocol - event filter