A Remote Thing can preserve its state if the ThingWorx Platform shuts down and restarts. In addition, a Remote Thing can take action when its state changes. This action can consist of generating notification events for runtime listeners or executing code to respond directly to these changes.

The state of a Thing consists of all its property values. A Remote Thing in the ThingWorx Platform is updated when it receives new property values from the client application that is running on the remote device. The Remote Thing holds its state in memory. If the server is shut down, this memory is discarded. When the platform is restarted, this Remote Thing is re-initialized, using the default values of its properties, unless the properties are marked with the isPersistent aspect. In this case, the current state of the Remote Thing is stored in the database when it is updated, allowing these values to be used instead of the default values when the Remote Thing is re-created on platform restart.

In the Java SDK, a VirtualThing represents the state of a Thing in the application and does not benefit from the isPersistent aspect. Its job is to store the state of a device/machine on the remote machine.

Your client application is responsible for updating the state of this Virtual Thing. This state sits on the remote system until it is either pushed to the ThingWorx Platform or pulled as a result of a request made by the platform. A value cache on the platform controls the push and pull processes.

The value cache stores all states reported to the platform. These values are pushed to the platform by a client application. You can designate whether the properties are cached forever, cached for a set amount of time, or not cached at all. If you refer to one or more properties in a mashup, for example, the state is delivered to your browser. That state is determined by retrieving the values of the properties from the local database of the platform, unless some of those properties are bound.

Bound properties must be evaluated. If a property is bound to a Remote Thing, that value is stored in the value cache when the remote VirtualThing pushes it there. A timeout setting is applied to cached values. If the timeout period has not expired when a bound value is requested, the cached value is returned to the mashup.

Now consider a last cached value whose timeout period has expired. To evaluate the binding, the ThingWorx Platform must send a request to the remote system (if it is currently connected). This request pulls the current state of the corresponding VirtualThing from the remote system into the cache, forcing it to update. This process provides the latest value, but it can be slow and it can fail, so this behavior is not the default. You may have noticed these settings in a Remote Thing configured on your platform.

The following figure provides an example of the SteamSensor Thing's Properties page and provides a few details about them. Note the icons for three aspects of the properties in the table header, one column for each aspect isPersistent, isReadOnly, and isLogged:

To see the aspects of any property, click its name. The right panel displays the definition of the property. Aspects such as Persistent, Read Only, or Has Default Value can be updated in this panel. The Advanced settings allow you to control caching as well as the push and pull behaviors of each property that is bound to a value in the cache. The Data Change Type area allows you to control how or even if the cache is used. Here is a closer look at a property definition panel of one of the SteamSensor Thing's remotely bound properties: