RESTful robotics @ MS
By sandoz on Aug 06, 2007
I am rather impressed by the application of the REST architectural style to the Robotics Studio architecture, and especially impressive is the light weight service model that enables loosely coupled composition and orchestration of services. Further more, this model enables fine-grained manipulation and notification of structured data. Core to this is the Decentralized Software Services Protocol (DSSP), which Microsoft has released under its Open Specification Promise.
DSSP uses SOAP 1.2 (and WS-Addressing), which may raise a few eyebrows as SOAP is more commonly associated with WS-\*. However, fundamentally SOAP is agnostic to architectural style, and DSSP is a good example of application of the REST architectural style to something other than HTTP.
DSSP specifies a uniform interface. A service must be identified by a URI and each service supports a fixed set of operations (CREATE, DROP, LOOKUP, GET, QUERY, INSERT, UPDATE, UPSERT, DELETE, REPLACE and SUBSCRIBE) and if those operations are safe /idempotent. The operation is declared using the SOAP action and can be determined from the child element of the SOAP body (the XSD of the messages can be found here). Notice that there are no WSDL documents. There is no need for any because services conform to a uniform interface.
Although the use of SOAP is interesting I do wonder why HTTP was not directly extended by the addition of new HTTP methods (note that a PATCH method is being proposed as an internet draft, i wonder if the community should look more closely at the DSSP methods?), use of HTTP status codes and MIME media types.
Details are a little sketchy so I will have to make some guesses as to why. DSSP SOAP messages are transport agnostic can can be transmitted over protocols other than HTTP. But it is not for the performance reasons of HTTP messages vs. SOAP messages as I suspect the message sizes and message processing times would be similar. HTTP is a request/response protocol. DSSP specifies a SUBSCRIBE operation to subscribe to event notifications, and event notifications are not acknowledged by the receiver. This can be implemented using HTTP when peers each have an HTTP server but it may not scale. DSSP event notifications could be sent over UDP or a multi-cast protocol or multiplexed over a two TCP connections that mixed both request/response and one-way messages initiated from either peer. Hmm... isn't this starting to look a little like what Waka is supposed to do...