Microsoft Robotics Studio (MSRS) and Windows Communication Foundation (WCF) Work Together

• Download demo project - 58.4 Kb
• Download source - 73.7 Kb

Introduction

Microsoft Robotics Studio (MSRS), the first prerelease of which was announced several months ago, is going to become a powerful tool not just for robots control but also for a wide range of service-oriented applications. Its Concurrency and Coordination Runtime (CCR) considerably simplifies development of simultaneous and interrelated tasks and increases applications' responsiveness. Decentralized System Services (DSS) provides developers with light-weighted services-based tools to write and coordinate distributed applications.

Although MSRS supports Web user interfaces and even allows to run WinForms from inside of the DSS service, communication of DSS services with a non-MSRS application may be desirable. Particularly, such communication is required when MSRS-based servers respond to remote non-MSRS clients. This article presents a sample of such a communication. The connection is made using .NET 3.0 Windows Communication Foundation (WCF, formerly known as "Indigo") services. Some basic familiarity with MSRS and WCF is essential. Apart from Microsoft documentation, several useful links are given in the References paragraph at the end of this article.

Code Sample

Description

The code sample for the article consists of four projects (see the picture). Three of them, namely, PerformanceMonitor, FileWatcher, and Coordinator, are DSS of the same DSS host (node). The services have nothing to do with the actual robots control. Instead, in full compliance with their names, PerformanceMonitor periodically measures the % Processor Time performance counter, FileWatcher listens on changes in a given disk directory, and Coordinator coordinates activities of the formers and acts as gateway for this DSS node to the outside world. The shining outside world is represented by the forth project TheForm that is a WinForms application. TheForm and Coordinator communicate with WCF services. Each of the parties implements its own self-containing WCF service, and creates a proxy to connect the counterpart. TheForm implements a WCF service Notification with a http://<machine>:19191/Notification URI containing endpoints for the notification itself and the service metadata export. This service provides an interface (in the WCF parlance [ServiceContract]) TheForm.INotification implemented by the TheForm.Notification class. The service is defined in App.config file and opened in the StartNotificationService() method of the class TheForm.Helper. The DSS Coordinator has its own self-containing WCF service Coordinator http://<machine>:19190/Coordinator with [ServiceContract] Robotics.Coordinator.ICoordinator (file CoordinatorServiceType.cs) opened in an imperative form in the Robotics.Coordinator.CoordinatorServiceHost class. The client proxies for the above WCF services were generated using the SvcUtil.exe utility. Appropriate command files are included in the Coordinator (file NotificationProxyGenerator.cmd) and the TheForm (file CoordinatorProxyGenerator.cmd) Visual Studio projects. The commands in these files extract service metadata during service runtime.

The WCF service hosted by the Coordinator DSS receives commands sent by TheForm UI console. For simplicity, it has only one [OperationContract] ICoordinator.Command() with two parameters: a command name string and a typeless (of object type) command data specific to each command.  There are only three such commands in the sample: "notify me" to make Coordinator DSS a client of the TheForm's Notification WCF service, "set monitoring period" for PerformanceMonitor DSS, and "set watched directory" for FileWatcher DSS. The "notify me" command causes the DSS Coordinator to become a client of the Notification WCF service and call [OperationContract] TheForm.INotification.Notify() when the notification event occurred.

As it was stated above, the Coordinator DSS controls activities of other DSS services in this solution, gets notifications from them and, in its turn, notifies TheForm application. Thus, the Coordinator DSS sets a period for PerformanceMonitor and watches the directory for FileWatcher. This is achieved by including references to the PerformanceMonitor and FileWatcher proxies (FileWatcher.Y2006.M09.Proxy.dll and PerformanceMonitor.Y2006.M09.Proxy.dll, respectively), and posting the Replace verb to their main ports to replace the services states with new data (see classes implementing the interface IDssCommand in the file Commands.cs). ReplaceHandler() of PerformanceMonitor updates PerformanceMonitorState.timeout effectively changing monitoring period. Similarly ReplaceHandler() of FileWatcher updates FileWatcherState.watcherRootDir setting a new directory to listen on. Both PerformanceMonitor and FileWatcher DSS send notification to their subscription ports. The mechanism of communication between different DSS within one DSS node is explained (or rather "shown") in the ServiceTutorials shipped with Microsoft Robotics Studio CTP. See also comments in the sample's code.

In this sample, I don't care about DSS security restrictions. So in order to allow DSS to use the performance counter, listen to the changes in the disk directories, and communicate with WCF means, security restrictions are lifted for now (by commenting out the [PermissionSet] attribute of the DsspServiceBase-derived classes in all DSS). For simplicity, only synchronous calls to WCF services are used in the sample. Since the sample is intended to show just the concept, the error handling is primitive.

Installation of Code Source

First make sure that .NET 3.0 (currently RC August 2006) and MSRS (currently CTP October 2006) are installed on your machine. Then unzip sources to a _MsrsWcfWorkTogether directory just under MSRS main directory, start  Microsoft Robotics Studio Command Prompt, go to _MsrsWcfWorkTogether directory and run DevEnv.cmd file. VS 2005 will be opened with WCFConn.sln loaded to it. Check the project properties. Output path for all projects should be ..\..\..\bin\services\. For DSS services, the setting should be as follows:

Start external program: <Microsoft Robotics Studio main directory>\bin\DssHost.exe

Command line arguments: -port:50000 -tcpport:50001 -manifest:"_MsrsWcfWorkTogether/WCFConn/Coordinator/Coordinator.manifest.xml"

Working directory: <Microsoft Robotics Studio main directory>

Build solution in the following order. First, build FileWatcher and PerformanceMonitor projects. Then make sure that Coordinator has proper references to FileWatcher.Y2006.M09.Proxy.dll and PerformanceMonitor.Y2006.M09.Proxy.dll and build Coordinator project. Build TheForm project. Use files RunTheForm.cmd and RunCoordinator.cmd to run appropriate applications. For future MSRS releases, use the recommended converting procedure.

Installation of Demo

Unzip demo to directory <Microsoft Robotics Studio main directory>\bin\services and execute RunCoordinatorFromSvc.cmd and RunTheFormFromSvc.cmd files.

Note. This demo project works for the version of MSRS and WCF specified above.

Conclusion

A sample of collaboration between MSRS service and a WinForms application by means of WCF services is presented. WCF provides the developer with a range of transport adapter channels (HTTP, TCP, Named Pipes, Peer to Peer and MSMQ) as a means of transporting messages between the sender and receiver. Thus, the ability to communicate using WCF considerably extends the capabilities of MSRS services, particularly to serve as a server engine.

References

• Sara Morgan Rea. An Introduction to Programming Robots with Microsoft Robotics Studio.
• Jeffrey Richter. Concurrent Affairs: Concurrency and Coordination Runtime.
• Ingo Rammer. From .NET Remoting to the Windows Communication Foundation (WCF).
• Yasser Shohoud. Meet the WCF Channel Model - Part 1.