The REST Uniform Contract

One of the key design decisions of REST is the use of a uniform contract. Coming from a SCADA background it is hard to imagine a world without a uniform contract. A uniform contract a common protocol for accessing a variety of devices, software services, or other places where I/O, logic, or data storage happens. The whole point of SCADA is acquiring data from diverse sources and sending commands and information to the same without having to build custom protocol converters for each individual one. Surprisingly, this is a blind spot to most software engineering. It’s a maturity hole that normally requires every service consumer to implement specific code to talk to each service in the architecture.

SOAP and WSDL are built on this style of software architecture, where every service in the system has a unique protocol to access the capabilities of the service. There is no common protocol mechanism to go and fetch information. There is no common mechanism to store information. What commonality exists between the protocols of different services exists at a lower level. Services define a variety of read and write operations. SOAP ensures these custom operation names are encoded into XML in a consistent way that can be encapsulated for transport across a variety of network architectures, and WSDL ensures there is a common way for the service to embed this protocol information into the integrated development environments for service consumers, as well as into the service consumers themselves.

The contract mechanism simplifies the task of processing messages sent between service and consumer, but still couples service and consumer together at the network level and at the software code level so that each consumer can only work with the one service that implements the contract.

OPC-UA and OPC are built on SOAP and COM, respectively. SOAP and COM both share this low level of protocol abstraction and both OPC and OPC-UA compensate for this by defining a service contract that not only one service implements but that every OPC DA Server or related server needs to implement in order for consumers to be able to communicate with them without custom per-service message processing logic and without custom per-service protocol. For this reason they are a good case study to contrast the features of SOAP and HTTP for industrial control purposes.

HTTP is the current standard protocol for one aspect of the REST uniform contract. In fact, there are two other key aspects. A REST uniform contract is a triangle of:

A standard syntax for resource identifiers
A standard protocol (“methods”) for accessing resources
A standard set of types (“media types”) that can be transferred

As all SCADA systems use some form of uniform contract, it is useful to understand the key design feature of a REST uniform contract compared to a conventional SCADA contract. In a conventional bandwidth-conservative SCADA protocol it is common to define fetch, store, and control operations that are each able to handle a defined set of types. These types might include a range of integer and floating point values, bit-fields, and other types. As I look back over the protocols I have used over my career I consider that some of the protocol churn we have seen over time has been because of the range of types available. Each time we need a new type we either have to change the protocol, start using a different protocol, or start to tunnel binary data through our existing protocol in ways that are custom or special to the particular interaction needed.

REST takes a different approach where the protocol “methods” are decoupled from the set of media types. This adds a little protocol overhead where we need to insert an identifier for the media type along with every message we send, and a long one at that. Examples of media type identifiers on the Web include text/plain, text/html, image/jpeg, image/svg+xml, and application/xhtml+xml. These type names are long, and they have to be to ensure uniqueness. We wouldn’t normally tolerate type identifiers of this length in bandwidth-conservative SCADA protocols, but where we can assume the use of Ethernet comms and other fast communication bearers the massive inefficiency in these identifiers can be tolerated.

The reason we would want to tolerate identifiers like this is because they allow our main protocol to be independent of the types that are transferred across it. There is no need to change protocol just because you need to send new types of information. The set of types can evolve separately to the main protocol, and experience on the Web and in SCADA environment suggests that this is an excellent property for the application protocol to have. Types of data that need to be moved around need to be changed, extended, and customised far more often than the ways that the information needs to be moved around. You can essentially think of the REST uniform interface constraint as a decision to use a SCADA-like protocol but to explicitly separate out the types of information to ensure longevity of the protocol in use.

This brings us back to OPC and OPC-UA. Although they are layered on top of COM and SOAP they bring back some of the uniform contract constraint. They allow some variation of media type through the use VARIANT to convey custom types. However, they don’t go all the way. In a REST environment we would not have a special protocol for data acquisition, another for alarms and events, and another for historical data. We would be looking to define one application protocol that could be used for all of these purposes in conjunction with specific media types. Perhaps not all of the features of that protocol would be used for all of these purposes, but they would be available and consistent across the architecture.

On the Web the application protocol is HTTP. It has features to GET, and to PUT, and to do all the basic things you would expect for a master/slave protocol. It is relatively efficient, especially when compared to a solution that tunnels SOAP messages over HTTP, and then OPC messages back over the SOAP. A simpler solution would see OPC make use of HTTP directly, and tie its future evolution to that of HTTP rather than to a three layer hierarchy.

It is conceivable that HTTP would require further work or some extension before it is completely suitable for use as a SCADA protocol, and I’ll put together a few observations on this front in a later post. However, if HTTP can be adopted as the foundation for future SCADA systems that have reasonable bandwidth available to them then it will result both in a system that is more efficient than something like OPC-UA but is also more at home in a world of web proxies and firewalls. HTTP is the protocol of the Web, and REST is the foundation behind HTTP. HTTP is and will remain more at home in complex internetworking environments than COM, SOAP, or any other custom contract definition mechanism. I would predict that disciplined application of the REST uniform interface constraint in conjunction with HTTP will produce a consistently better and more robust technical solution to the problems of SCADA systems.

Benjamin