Serializer Services - 30,000 Foot Introduction - (MSRS) Post 2

NOTE: These posts assume that you've read through some of the basic Microsoft Robotics Studio Tutorials and worked through some of their sample projects.

Where do I start? There's so much cool stuff to learn!

For the purpose of the next sequence of posts, I'm going to cover our Serializer Services collection only. Then, I'll follow up with our Traxster Drive Service. I want to keep the blog simple, and straightforward. Future posts will build on complexity and cover more advanced topics. Eventually, we'll be cooking with gas!

When I traveled to Redmond to get my two day crash course on MSRS last April, the concepts and archietecture weren't like anything I had ever seen, so I hope to help out newbies to MSRS understand what I didn't. The basic framework and architecture makes sense now (thanks to Joseph Fernando and Andreas Ulbrich), but it took me a while to fully understand how the basic architecture works.

Decentralized Software Services Protocol

Before I get started on the Serializer Services, I think it's important to provide a quick explanation of Services and DSSP, just so we can have them handy.

The following excerpts are from Microsoft's Decentralized Software Services Protocol document. They do a much better job than I could ever do of explaining the jist of DSSP. :)

Microsoft Robotics Studio Services are based on the Decentralized Software Services Protocol (DSSP). DSSP is a simple SOAP-based application protocol that defines a lightweight service model with a common notion of service identity, state, and relationships between services. DSSP defines a set of state-oriented message operations that provide support for structured data retrieval, manipulation, and event notification.

DSSP defines an application as a composition of services that, through orchestration, can be harnessed to achieve a desired task. Services are lightweight entities that can be created, manipulated, monitored, and destroyed repeatedly over the lifetime of an application through operations defined by DSSP.

This last excerpt regarding destruction and creation seemed really cool to me. Why? Because if you have a rogue service which is misbehaving, you can simply terminate it, spawn a new identical service, and continue on your merry way! So, Services beware! Instant discipline for bad behavior! :)

Basic Terminology

I think it's also important to understand, and use, the terminology defined by Microsoft regarding MSRS services. Thus, I'm going to include some basic terminology below, again repeating Microsoft's DSSP document verbatim.

Service - A service is a computational unit that has
identity, state, behavior, and context.

Application - An application is a composition of
services that through orchestration can be harnessed to achieve a desired
task.

Service State - The data representing a service at a
specific point in time

Service behavior/contract - The behavior of a service
(aka the contract) is the combination of the content model describing the state
and the messages exchanges that a service defines for communicating with other
services.

Partner - A partner is a labeled reference representing
a behavioral relationship that a service has to another service.

Message - A message is a one-way message, a request, or
a response participating in a DSSP operation.

Request - A DSSP request is a message participating in
a request-repsonse message exchange pattern.

Response - A DSSP response is a message participating
in a request-repsonse message exchange pattern.

Now I can communicate using this terminology, and you'll understand what I'm writing in this post, and in subsequent posts. :)

What does DSSP really buy me?

Since all Robotics Studio services are based on DSSP, we can take advantage of the fact that they can be distributed. This means that an application can be composed of multiple services running on local, or distributed computers.

Another advantage of DSSP is that services can serve as a basic building blocks to provide simple behavior. These basic services can be assembled together to build more complicated services and behaviors.

Futhermore, once you debug the service, everyone can reuse it (and not have to debug it again). Not only does this promote code reuse, but also improves reliability.

Lastly, DSSP allows you to pick and choose only those services you need "a la carte" using an XML manifest file. I'll discuss the manifest file in upcoming posts. So, as you can see, DSSP is very powerful!

What are Serializer Services?

The Serializer Services are actually a collection of what I call Serializer Peripheral (SP) services, or "SP services" for short. SP services encapsulate well defined functionality built into our Serializer .NET robot controller. Such functionality includes various distance sensor services, motor control services, wheel encoder services, servo services, I/O services, etc.

SP services all use a single central "Serializer service" as their Partner. The Serializer service is responsible for handling communications to and from the physical Serializer robot controller, as well as provide an external command-response interface to SP services. This allows the SP services to send a command to the service, and receive the response back (if needed). The SP services then update their internal state, and if they have subscribers, will send a notification that the state has changed.

An Example Application

I'm going to close by discussing the diagram below, which is composed of a Drive service, several SP services, a single Serializer service, and the actual Serializer robot controller.

Starting on the right, the Drive service sends messages to the main port (red dot) of specific SP services, such as a "SetMotorPower" message sent to the Motor service(s). When the Motor service(s) receive those messages, they in turn, send a message to the main port of the Serializer service. When the Serializer Serializer service receives the message, it sends the proper serial command to the Serializer robot controller.

Once the Motor service(s) receive a response from the Serializer service, they update their state, and in turn, notify the Drive service over the notification ports (yellow/orange rectangles). As the Drive service receives these notifications, it can update it's GUI, since now it knows for sure the motor power was correctly set.

Some of the SP services have internal timers, which fire internally to tell them to periodically update their state. An example is the Sonar service. Every time the internal timer fires, it sends a message to the Serializer service. The Serializer service then sends a command to the Serializer robot controller to query the state of the sensor connected to it. The value the propogates back up to the Sonar service, which updates it's internal state, and as you've probably already guessed, sends a notification to the Drive service.

Although the diagram shows a single notification port on the DriveService, there are in reality, a notification port for each partner.

Conclusion

In the next post, I'll discuss the Serializer service interface in more detail. Subsequent posts will drill down into the SP services, and finally into the Drive Service.

-Jason Summerour