Archive for the ‘ MRDS ’ Category

Decentralized Software Services (DSS)


The CCR enables segments of code to pass messages and run in parallel within a single process. The Decentralized Software Services (DSS) library extends this concept across processes and even across machines.

Problem Areas Covered by DSS

  • Robustness

In any complex system, a failure in a sub-part of the system has the potential of bringing down the whole system. The reason is that a partial failure can lead to a catastrophic failure if it cannot be properly isolated, detected, and handled. Loose coupling is a design pattern that often is invoked as a way of limiting the impact of partial failures. However, in order to build loosely coupled systems, each component must be isolated from all other components as well as from the underlying runtime environment. Two common ways in which systems fail to isolate components are data isolation and execution isolation. Lack of data isolation can cause the internal state of a service to be corrupt and lack of execution isolation can cause a component to become unresponsive. DSS isolates services in both data and execution. Data isolation is achieved by fully cloning all messages exchanged between services (including system services). The cloning code is generated as part of the compilation and is much faster than full serialization.

  • žComposability

The requirement of robustness forces applications to become compositions of loosely coupled components. This raises the additional problem of how to identify, locate, and compose such components into a running application. Most traditional systems define an application as a single process and not as a composition of loosely coupled services working together leaving the task of composition to the application designer. DSS provides both protocol and runtime support for creating, managing, deploying, and running applications that are composed of loosely coupled services: A service is created and wired-up at runtime based on a description of which other services it needs to compose with in order to function properly. This model allows applications at runtime to configure where each service instance is running. Further, the relationships that each service instance has with other service instances is exposed through DSSP making it possible to see which other service instances any particular service instance is dependent on.

  • žObservability

A critical aspect of any application is that it is possible to know what it is doing, what state it is in, and how it got to be in that state. In short, without a way to observe a system it is impossible to know whether the system is functioning properly. DSS puts the notion of observability at the core of its application model by defining a service as a resource identified by a URI and with exposed state that change as a result of internal service behavior and through interaction with other services. However, the notion of observability goes beyond just monitoring an application by inspecting the state of its services. By uniformly exposing all services in terms of their state, DSS provides simple and consistent solutions for dealing with administration, management, security, and service composition based on state manipulation. Further, DSS enables every DSS service to be accessed through a Web browser enabling rich UI as well as easy integration with a variety of common tools and platforms.


  • Simple, flexible, and service oriented
  • Coarse grained and loosely coupled
  • Compatible with existing Web infrastructure

Concurrency and Coordination Runtime (CCR)


Concurrency and Coordination Runtime (CCR) is a managed code library, a Dynamically Linked Library (DLL), accessible from any language targeting the .NET Common Language Runtime (CLR).
The CCR addresses the need of service-oriented applications to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. It enables the user to design applications so that the software modules or components can be loosely coupled; meaning they can be developed independently and make minimal assumptions about their runtime environment and other components. This approach changes how the user can think of programs from the start of the design process and deals with concurrency, failure and isolation in a consistent way.

Dealing with Concurrency

Sequential Model
  • CPU-bound – Flat or merely incremental performance
  • Potentially poor responsiveness
Concurrent Model
  • Workload decomposed into many heterogeneous work items
  • Lots of latent concurrency that can be mapped to computational resources
  • Data flow scheduler

Problem Areas

  • Asynchrony
When communicating between loosely coupled software components, like programs running across the network, or User Interface (UI) code communicating with the user input and the file I/O subsystem, asynchronous operations enable the code to scale better, be more responsive, and deal with failure across multiple operations. Asynchronous programming however, considerably reduces the readability of user code, since logic is often split between callbacks and the code that originates the operation. In addition, it is an almost impossible task to correctly handle failure across multiple outstanding operations.
  • Concurrency
Code that needs to better utilize multiple execution resources, must be split into independent logical segments, that can run in parallel, and communicate when necessary to produce results from the combined execution. Often, that logical segment is captured by the thread OS primitive, that is nothing more than a long lived iteration. Because of thread performance implications on thread startup, the thread stays active for long periods of time. This forces a particular pattern.  Code is structured as long sequences that use blocking or synchronous calls, and only deals with one thing at a time. Further, threads assume that the primary communication between them is shared memory, forcing the programmer to use very explicit, error-prone methods to synchronize access to that shared memory.
  • Coordination and Failure Handling
Coordinating between components is where most of the complexity in large software programs lies. A mismatch of interaction patterns, such as calling methods on objects versus using OS signaling primitives versus using queues plus signaling, leads to unreadable code, where the runtime behavior changes drastically between coordination approaches. More importantly, the error handling approaches are ill-defined and again vary drastically.

Application Model

CCR is appropriate for an application model that separates components into pieces that can interact only through messages. Components in this model need means to coordinate between messages, deal with complex failure scenarios, and effectively deal with asynchronous programming. This application model is also very similar to how heterogeneous hardware is integrated and how network applications are built. Most software programs have the same needs, from traditional client PC programs to server applications, to applets running in the Web browser. The software needs to coordinate user input, storage input/output and UI presentation. Although disguised in layers of mostly synchronous application code interfaces, asynchrony is inevitable since the devices operate at different speeds, have large differences in resources available, and we in general know how to use queues to isolate them.


  • Focus on coordination of messages
  • Hide traditional threads and locks primitives
  • Enable non thread blocking sequential execution between I/O, avoiding nesting/callback chains

Microsoft Robotics Developer Studio Components

The Microsoft Robotics Developer Studio SDK consists of a number of components.
  • The Concurrency and Coordination Runtime (CCR).
  • Decentralized Software Services (DSS) comprise the run – time environment.
They are both managed libraries, so the robotics services that operate within their environments are also implemented using managed code.
  • The Visual Simulation Environment is a 3D simulator with full physics simulation that can be used to prototype new algorithms or robots.
  • The Visual Programming Language (VPL) is a graphical programming environment that can be used to implement robotics services.
In addition to all of these components, the MRDS team has implemented numerous samples and complete applications to provide programming examples and building blocks for user applications.

Henrik Frystyk Nielsen on the Restful architecture of Microsoft Robotics Studio

Henrik Frystyk Nielsen used to work for the World Wide Web Consortium on some key pieces of infrastructure including the HTTP specification and libwww. He left the W3C in 1999 and now works for Microsoft where his current project is Robotics Studio, whose tagline is: “A Windows-based environment for academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware.” What that description doesn’t tell you, but today’s screencast shows, is that the Robotics Studio is based on a RESTful architecture, and that applications are built by composing lightweight services in ways that will be instantly familiar to every web developer.

To drive home that point, much of the action in this screencast occurs in a web browser, where you’ll see Henrik explore a distributed directory of services and view XML snapshots of the current state of bumpers, cameras, and laser range finders.

From a read-only perspective it’s all HTTP GET, and you can do things like subscribe to robotic sensors using RSS feeds. When you control a robot, SOAP is used to optimize fine-grained updates. But either way it’s a loosely coupled and late bound system that leverages the fundamental flexibility of web architecture in a very different domain. In one compelling demonstration of that flexibility, you’ll see a generic controller — which had been controlling the robot in Henrik’s office with no prior knowledge of the device, purely by interface discovery — switch over to a simulated robot and drive it by means of the same kind of discovery.

Jon Udell Original Article

%d bloggers like this: