The standard model for populating a account with data from physical devices in the field is for those devices to communicate with 's communication servers; a device sends messages to , publishes them on some messaging queue, responds to a poll from a communication server, and so on.
Once a communication server receives a message, it will use one of 's server-side cloud adapters to process that message into a format that the application server itself can interpret. If a client does not wish to use this approach for some reason, they can alternative get data onto a application using the Device API.
With this approach, a client implements their own client-side adapter that will receive and process messages from their devices, and normalize it into the very same XML message format that 's own adapters use to send data from its communication servers to its application servers. The client-side adapter can then send these normalized messages directly to an application server.
There are no restrictions for how a client-side adapter communicates with devices in the field, so a client can write such an adapter in any language and talk to devices over any protocol. There are, however, several requirements for how that adapter then communicates with .
The adapter must be able to receive a SOAP or REST PUT request via HTTP, and implement three web services methods for to call; these web services methods are described in the Required Client-Side Methods sub-section.
can provide, upon request, a Java package that implements communication with 's servers, so that all that remains to be implemented is communication between the adapter and devices in the field, and the processing of messages from these devices or directives from . However, the use of this package is entirely optional; you may fully implement your own adapter to achieve the same functionality. A brief description of the classes of this Java package is located in the Java Package section below.