Web Services for Smart Objects - Part 3: A real-world web service system for smart objects

When a client performs an HTTP request to a Pachube server, the client first sets up a TCP connection to the server. Once the TCP connection has been successfully opened, the client sends its request using the normal HTTP mechanism where the first line of data sent from the client contains the HTTP request verb, followed by additional lines of text that contain additional HTTP headers. If the request contains additional data, they follow after the HTTP headers.

The server responds in standard HTTP by sending the status code as the first data over the TCP connection. The status code is followed by the server's HTTP headers. If the request caused any data to be sent back from the server to the client, these data are sent after the HTTP headers.

When the HTTP interaction is complete, the TCP connection can either be closed directly or kept open in anticipation of another request at some later time. Whether the connection is closed or not is determined via a negotiation through the HTTP headers. If either the client or the server sends the connection close HTTP header, the connection is closed after the request has been completed. Otherwise the TCP connection is kept open in anticipation of another request between the client and the server.

9.3.2 Pachube Data Formats
Pachube supports several data formats for exchanging data between clients and servers. Providing different forms of exchanging data allows integration of different types of systems with the Pachube servers. A simple sensor that only wants to submit data to Pachube may choose to send its data in a simple format that requires low effort to construct and transport, whereas a visualization system that processes sensed data from the Pachube server to visualize it needs meta-information about the data such as where the data were sampled and when.

In the Pachube system, the clients decide how they want their data to be formatted as part of the requests they pose to the Pachube servers. The responsibility for converting the data between the formats falls on the Pachube servers rather than the client, as the clients may be resource-constrained smart objects.

Not all data formats contain the same amount of information. The simplest formats contain sensor data values, whereas the more complex formats contain metadata such as where the sensor data were obtained and at what time the data were sampled. Pachube supports the following formats:

• Extended Environments Markup Language (EEML): A custom version of XML tailored to contain sensor data. The EEML format contains tags that specify the spatial location at which the sensor data were sampled, as well as meta-information about the sensor data such as the minimum and maximum values that the sensor data can reach, and the default unit in which the data are to be represented. An example of an EEML document is shown in Figure 9.12.

• JSON: The JSON format contains the same amount of information as the EEML representation, but formatted in JSON rather than EEML. The JSON format is more compact than the EEML format, and is also easier to parse for programs implemented in JavaScript.

• ATOM and RSS: The ATOM and RSS formats contain less information than the EEML and JSON formats. The ATOM and RSS formats contain sensor data, but include only a limited form of metadata such as the spatial location of the sensors as well as tags and titles of the sensors.

• Comma-separated value format (CSV): This is the most basic format. It also contains the least amount of meta-information: the data stream contains only the sensor data. The CSV format is suitable for use on tiny units with limited processing power where creation or parsing of the more complex formats is not suitable.

FIGURE 9.12 A document in EEML format that contains sensor data.