Java client - events and messages
The Things service identifies every ditto-client by its unique ID. The client ID is used by the Things service to check permissions and dispatch messages to clients.
A client ID consists of two parts:
- the solution ID
this part your retrieve after successfully booking a service instance and
- a suffix
helping to distinguish e.g. different applications of a solution.
The permissions on a thing or its features are described within a policy (for API v2). If you need to receive events or to handle messages, it is crucial that the policy of a thing contains an entry for every client ID that needs access rights.
- In case the client is allowed to write a thing, it can for example create, read, update and delete the thing, its attributes, features, properties, etc.
- In case the client is allowed to write a thing’s policy, it can change the permissions.
This proves useful especially in case your client needs to handle a claim message. Find an example at Concepts > Auth > Claiming.
- In case the client is allowed to read a thing, it will be informed with an event for all changes executed by another client.
Events caused by commands from a connection are not published to the same origin. The Java client can receive a response, but will not additionally get an event. For example, messages produced by the same Java client (to update an attribute) are forwarded to all subjects with read permission, which would include the (publishing) Java client. However, the server would by default filter out such a notification.
In case you don’t need all events of a thing but only specific ones, find details about filtering at the protocol section Event filter.
The things-client as well as ditto-client can be clustered.