The primary task of robotics applications is to consume sensory input from a variety of sources and orchestrate a set of actuators to respond to the sensory input in a manner that achieves the purpose of the application. As an example, the robotics application data-flow diagram shown below contains a simple bumper (sensor) that reports when it is hit, a message box (actuator) that controls the display, and an orchestrator that connects the pieces together. 

This orchestration is simple but as applications grow, there may be any number of sensors, actuators, and orchestrators communicating with each other to perform complex operations. An example of a more advanced robotics application data-flow is illustrated below:

While each of the sensors and actuators are similar to the first example, the orchestrator now has to manage more components. In addition to the added complexity of orchestrating a growing number of components (that each may also be orchestrations), there are several things that distinguish the application data-flows above from many other "Hello world" applications:

1. Handling of sensory input and controlling actuators must be dealt with concurrently as otherwise actuators can get starved and sensors ignored.
2. Orchestration and composition is a critical part of the application, especially as the number of sensors and actuators grow and the orchestration becomes more complex.
3. Autonomous and collaborative orchestration requires that components can be distributed and made accessed over the network.

In order to meet these requirements, Microsoft Robotics Studio Runtime provides a highly concurrent, service oriented application model which combines key aspects of traditional Web-based architecture with pieces from Web Services to provide a flexible yet lightweight distributed application model. Naturally, this way of viewing an application is not unique to robotics and sensors and actuators are not limited to traditional robotics components like motors and bumpers.

Merging Web and Web Services

The primary focus of Web architecture is on simplicity, interoperability, and loose coupling. HTTP promotes this model by allowing applications to take advantage of a simple, state-oriented application model commonly known as "REST". Web based applications have through HTTP demonstrated that this model scales well, provide interoperability, and is flexible enough to accommodate a wide variety of scenarios. Despite the success of HTTP, however, there are well-known aspects that it doesn't capture. In particular, the three limitations that Web applications run up against repeatedly are:

1. No support for manipulation of structured data. That is, the only operations allowed on a resource are at the "resource level"; not at the substructure of a resource. This makes it difficult to update the state of a service which limits how services can interact.
2. No support for event notification. HTTP is a request/response protocol and does not support an event notification model based on pushing data to subscribers. While mechanisms like RSS are very useful, they are still fundamentally pull oriented and provide little support for structured filtering.
3. No support for expressing the kind of relationships between components illustrated in the diagrams above. In other words, there is no way to express that a particular orchestrator is to be partnered up with specific sensors and actuators.

The Microsoft Robotics Studio Runtime provides a REST-based application model but augments it with pieces from Web services for handling structured data manipulation, event notification, and partner management between services. By extending the REST model in this manner, applications can take advantage of an event notification model and structured manipulation of data without loosing interoperability with existing REST infrastructure. The result is much more interactive and dynamic applications constructed as compositions of services organized both within nodes and across the network.

Structured Data Manipulation in a REST World

HTTP was defined before XML became popular and has no obvious way of thinking of resources as structured entities. As a result HTTP only provides methods that operate at the resource level such as GET and PUT that exchange the entire state of a resource. While one can argue that the URI query notation (e.g. "http://www.example.com?keyword=value") does provide a partial view of a resource, this is still an unstructured view and only reflects reading the state; not changing it.

In contrast, Web services are inherently represented as XML that often is described in a variety of type systems including XSD, C#, and Java. By thinking of a resource as a structured entity it becomes possible to define common operations that operate on parts of a service.

Microsoft Robotics Studio Runtime adopts the notion that a resource can be a structured entity and defines a set of operations that enables service state to be added, deleted, updated, and queried without requiring a common data model across all services. Manipulating state in this manner is not new but by combining the structured view of Web services with REST the result is a much more flexible way for services to interact.

Event Notification in a REST World

The second piece that Microsoft Robotics Studio Runtime adopts from the Web Services world is that of event notifications. By modeling an event as a state change in a service, it becomes straight forward to introduce events into the REST model. For example, in the case of an UPDATE operation on a service, the state of that service changes as a direct result of that UPDATE operation. Furthermore, the UPDATE operation itself directly represents the state change and so it is natural to think of the event notification as simply being the UPDATE operation.

By expressing event notifications in terms of state changes in a service, subscribers have a common way of monitoring publishers independent of the semantics of a particular service and publishers have a common way of representing event notifications by simply relaying all state changing operations to subscribers.

Microsoft Robotics Studio Service Model

In the Microsoft Robotics Studio Runtime, an application is a composition of services where each service is a REST style service with added support for event notification and structured data manipulation as described above. By orchestrating loosely coupled and lightweight services on a single host or across the network, applications of varying complexity can be created and composed with each other to create yet more complex applications.

Because of the relationship to HTTP, the state of each service can be monitored and manipulated directly through HTTP using a Web browser, or though a simple SOAP-based protocol called DSSP (Decentralized Software Services Protocol):

1. HTTP enables support for operations such as GET, PUT, and POST, and DELETE. This enables a service to be used within a rich UI context such as a Web browser using existing infrastructure and existing data formats.
2. DSSP enables support for structured data manipulation of the service state supporting semantics like UPDATE, INSERT, and QUERY. In addition, DSSP provides an event notification model that is tied to changes in the state of that service.

Sample Robotics Application

An example of simple Microsoft Robotics Studio application is a composition of three services that can be used to control a basic robot. The services are: A drive service (actuator) that can move the robot in different directions at varying speeds; a bumper server (sensor) that signals when another object is hit, and an explorer service (orchestration) that changes the speed and direction of the robot depending on input from the bumper. The Explorer service listens for event notifications from the bumper and determines the speed and direction of the drive service.

In this sample application the Explorer service subscribes to the Bumper service and sends instructions to the Drive service. Such composition is called partnering. A partnership represents a relationship that a service has to another service. A partner is described by the type of the partner and the partner service instance.  Partner information is also exposed as state and can be inspected using the LOOKUP operation which is part of DSSP.