locked
Designing services question RRS feed

  • Question

  • Hi,

    I have a question about design. I have a situation where I have a single resource which I'd like to have represented as multiple services in Robotics Studio. Our sensors allow only one connection but provide numerous services. I don't want to expose the raw feed from the sensor as a service because of the overhead and that it wouldn't make any sense to expose.

    Most of the samples I've gone through have one service/contract identifier per assembly, is it possible to have multiple service contracts in a single assembly?

    Also from my previous thread, I'd really like to know how one would debug Silverlight applications inside the dsshost

    Thanks for your help

    Mike

    Thursday, January 29, 2009 6:05 PM

Answers

  •  For the VEX interface, I built a layer that did the communications with the robot (Vex\VexService) but he does not know about the 'standard' interfaces.  The standard services are implemented in VexService\*.  This lets the primary service control communications (and gather updates) and the services act 'naturally'.  They just have to subscribe to my coordinator to get the update events/tell it what to update the sensors/motors to do.

    In my case, the extra delay from the controller to the services is minor in comparison to the time taken to talk to the robot so I'm willing to overlook the overhead.  (I'd suggest that you try such a setup as a test and see how much of a performance degradation you get.)

    The VEX public services interfaces are all published in the same DLL.  You just need to make sure that each service is in a separate namespace.  (I think you have to tweak AssemblyInfo.cs, but it's been a long time since I worked through that.)

    Ed

    Thursday, January 29, 2009 6:23 PM
  • That's great. Make sure you take advantage of Ed's services for VEX. I know there is a steep learning curve, but eventually it will all "click" into place.

    Trevor
    Saturday, March 14, 2009 5:15 AM

All replies

  •  For the VEX interface, I built a layer that did the communications with the robot (Vex\VexService) but he does not know about the 'standard' interfaces.  The standard services are implemented in VexService\*.  This lets the primary service control communications (and gather updates) and the services act 'naturally'.  They just have to subscribe to my coordinator to get the update events/tell it what to update the sensors/motors to do.

    In my case, the extra delay from the controller to the services is minor in comparison to the time taken to talk to the robot so I'm willing to overlook the overhead.  (I'd suggest that you try such a setup as a test and see how much of a performance degradation you get.)

    The VEX public services interfaces are all published in the same DLL.  You just need to make sure that each service is in a separate namespace.  (I think you have to tweak AssemblyInfo.cs, but it's been a long time since I worked through that.)

    Ed

    Thursday, January 29, 2009 6:23 PM
  • Thanks, I just got the Vex code to see your approach. In my case I am looking at a high rate of communication so I am not sure about the extra overhead but it might not matter that much.

    Mike

    Thursday, January 29, 2009 11:11 PM
  • No problem.  Don't be too critical of my code while you're looking at it.  It's gone from 1.0 CTP to 2.0 with only minimal rewrites for new MRS features.  Lots of bug fixes, but few new MRS features.  (I'm only working on it on weekends when I don't have other things taking up my time.)  I'll try to keep an eye on this thead if you have questions.  I'm sure if I cannot answer your questions, someone else can.

    Ed

    Friday, January 30, 2009 12:26 AM
  • To answer one of your original questions:
    You can have multiple services per assembly. This is how Robotics Common works. Each distinct service needs a service contract, and therefore its own namespace.

    However, you can add as many operations to a service as you like. You could also have operations that accept parameters and do several different things, or conversely return different information depending on what you ask for. This helps to keep the number of operations down.

    The extra overhead to talk to a local "brick" service is not very great. CCR/DSS messages are processed very efficiently.

    Trevor
    Tuesday, February 3, 2009 8:18 PM
  • Thanks for your all the replies. Trevor, I got your book Pro MSRS (great book by the way) and between that and the Vex code I am beginning to understand the power and complexities of the CCR/DSS. In my vast free time (between 1 AM and 3AM :) ) I am beginning to make some progress adapting the 1Wire sensors into MSRS once I understand these simple sensors I can move to bigger things.
    Thanks
    Thursday, March 12, 2009 2:51 PM
  • That's great. Make sure you take advantage of Ed's services for VEX. I know there is a steep learning curve, but eventually it will all "click" into place.

    Trevor
    Saturday, March 14, 2009 5:15 AM