Modifying the state of a resource

Elements of state (aka properties) of a resource (such as WSDM properties, the properties of a CIM class or the attributes of an MBean) are a common component of management meta-models. They provide a way to expose information related to the resource. They are usually readable and sometimes also writeable. Reading the value usually means that the returned value is what the manageability representation believes reflects the state of the resource at the time the request is served. You generally can’t be sure that what the manageability representation sees is the actual state of the resource and that the state will not change one microsecond later, but within these usual restrictions, the semantics of a read are pretty clear. The semantics of a write are trickier as properties may represent an observed value, not one directly controllable (sometimes called a configuration value). For example, one cannot just “set” the GPS coordinate of a car and expect the car to be instantly teleported there. Does this mean that the GPS coordinate should not be writeable, or does it mean that setting them should be interpreted as an instruction to the car to do the best it can to drive itself to the location corresponding to the coordinates? Either is ok, as long as the contract is clear. Here are possible ways to handle this:

• One approach is to make ALL properties (that is, the entire state of the resource) read-only and any change goes through operations. The state only changes as a side effect of operations, each of which has clear semantics. So instead of setting the GPS coordinates, one sends a DriveTo message containing the coordinates. The semantics are those of “DriveTo”, rather than reusing some generic semantics applicable to a class of “set” or “write” requests.
• A variation on this is to explicitly select some elements of state as configuration elements that can be set by a generic “set” operation and leave aside non-configuration elements to be modified only as side-effects of operations. For example, threshold levels and ownership contact information can usually be written directly by the manageability implementation.
• Another approach is to clearly acknowledge the difference between observed state and desired state and model all interactions as modifications to the desired state, leaving the manageability representation in charge of doing its best to reconcile the observed state with the desired state. In this case, a “set” or “write” operation is clearly a modification of the desired state, not necessarily the observed state.