locked
Named service partnerships via createservice (in simulator). RRS feed

  • Question

  • Hi,

    I'm trying to use CreateService to connect MyService to a specific instance of an existing SimulatedWebCam service.  My code is modeled on SimulationTutorial2.

    Consider first the case where there is only one instance of the simulated webcam exists:
    Code Snippet

    // Create simwebcam (assuming the entity is already inserted)
     CreateService(
                    simwebcam.Contract.Identifier,
                    Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(
                        "http://localhost/"+mywebcam.State.Name);
                );
    // This call works:
    CreateService(MyService.Constract.Identifier);
    // So does this:
    CreateService(MyService.Constract.Identifier,
                    new PartnerType(new System.Xml.XmlQualifiedName("foo"), simwebcam.Contract.Identifier, "http://localhost/" + "bar"));



    Note that it doesn't seem to matter what name or service address I provide, the partnership succeeds.  That said, it takes a very long time to establish the partnership.

    Now I want to partner with a specific instance of the simwebcam:

    Code Snippet

    // Create simwebcams (assuming the entity is already inserted)
     CreateService(
                    simwebcam.Contract.Identifier,
                    Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(
                        "http://localhost/"+mywebcam1.State.Name);
    CreateService(
                    simwebcam.Contract.Identifier,
                    Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(
                        "http://localhost/"+mywebcam2.State.Name);
                );

    CreateService(MyService.Constract.Identifier,
                    new PartnerType(new System.Xml.XmlQualifiedName("*****"), simwebcam.Contract.Identifier, "http://localhost/" + "****"));



    Now, no matter what I insert in *****, I seem to have no control over the camera it partners with.  It will always partner with the first [second?] service.  I suspect that if I had a method for actually naming the created simwebcam services then I could use it in the XmlQualifiedName field.  Is there a way to do this?  ie, how do you assign a name to a service programmatically?

    Thursday, May 31, 2007 9:00 PM

Answers

  •  Rob Sim -- Braintech wrote:
    Thanks George,

    Here's the partnership code inside MyService:
      [Partner("Camera", Contract = webcam.Contract.Identifier,
                     CreationPolicy = PartnerCreationPolicy.UseExisting)]
            webcam.WebCamOperations _camPort = new webcam.WebCamOperations();

    Before I switch to UsePartnerListEntry, I want to make sure I can cover all my bases.  I want to give the end user the opportunity to specify the webcam partner in the MyService manifest, or to specify it programmatically (e.g. they dynamically create a robot/webcam in the simulator) when they use CreateService to create MyService.

    1. UsePartnerListEntry won't try to create the partner service itself, correct?
    2. The partner list entry either comes from the manifest, or the partner list supplied to CreateService, depending on the creation context, correct?
    3. afaict, if the user creates the webcam service using CreateService, the only way to specify the service url is if they use the overload taking a ServiceInfoType, correct?  And it seems to me that there's no direct way to give a service a name programmatically.
    4. If use CreateService with a ServiceInfoType and then create MyService with a partner list containing a partner with a matching service url, is it safe to assume now that the partnership will take place correctly?  It's a bit odd that presently I can specify an arbitrary url and a partnership takes place with any service matching the specified contract.

    Wrt timing, I understand now why the partnership takes so long.  I mentioned in a related thread that I want transparent operation, whether I'm connected to a simulator or hardware camera service.  As a result, I have a WebCamServiceOperations partnership specified as optional (this service is only associated with the hardware webcam service), and in a simulation context it takes some time for dss to decide that the partner doesn't exist.  Barring any race conditions, I think it would make more sense for me to check for this service programmatically- once the webcam partnership is created then it's a no-brainer to poll the service directory without the need for a long timeout.

    Thanks for the heads-up about Sleep(). :-)

    R

     

    1. Correct, thats why its nice if you want 100% control

    2. correct, manifest always overrided code attributes, and programmatic requests are same as manifests. As a matter of fact even if you used *any* PartnerCeationPolicy, we always override using the manifets or programmatic create value

    3. Correct, you need to supply a serviceInfo, and fill in the partner list. And, yes you *can* directly control the name of a service. Just set the ServiceInfo.Service as a URI, with no need to set the port. For example you can set it to ServiceInfo.Service = http://localhost/MyServiceNameIJustChose;

    4. Yes, we match on partner name first, then we match by contract. Indeed we should only match by contract  if the partner name matches, so i will check into this, it might be a "feature"/bug Smile

     

     

     

    Saturday, June 2, 2007 3:44 AM

All replies

  • The partnering behavior will depend on what the Partner attribute for the webCam port looks like on MyService. Can you post a snippet from MyService implementation class, with the partner definitions?

     

    I would use the PartnerCreationPolicy.UsePartnerListEntry to have exact, deterministic control of who you partner with. It will always expect a full URI in the partner list for the webcam, and it will fail otherwise.

     

    Also, partnerships should take only as long as it takes for the partners you need ot be created. Sim services sometime will take longer because they rely on the sim world being created, etc But it should all be a few seconds, tops, on an average machine. If you see anything more, look for errors in the logs and let us know about them.

     

    In general, any wierd behavior you see with partnerships, let us know (you can contact us directly if necessery). For example i saw in another thread that you had to do a Sleep(2000) in your start routine to make things work. That should *never* be necessery and it will actually cause serious issues (it canl actually cause deadlocks). So please let us know why that was required and we can follow up.

     

    thanx

    g

    Friday, June 1, 2007 4:22 PM
  • Thanks George,

    Here's the partnership code inside MyService:
      [Partner("Camera", Contract = webcam.Contract.Identifier,
                     CreationPolicy = PartnerCreationPolicy.UseExisting)]
            webcam.WebCamOperations _camPort = new webcam.WebCamOperations();

    Before I switch to UsePartnerListEntry, I want to make sure I can cover all my bases.  I want to give the end user the opportunity to specify the webcam partner in the MyService manifest, or to specify it programmatically (e.g. they dynamically create a robot/webcam in the simulator) when they use CreateService to create MyService.

    1. UsePartnerListEntry won't try to create the partner service itself, correct?
    2. The partner list entry either comes from the manifest, or the partner list supplied to CreateService, depending on the creation context, correct?
    3. afaict, if the user creates the webcam service using CreateService, the only way to specify the service url is if they use the overload taking a ServiceInfoType, correct?  And it seems to me that there's no direct way to give a service a name programmatically.
    4. If use CreateService with a ServiceInfoType and then create MyService with a partner list containing a partner with a matching service url, is it safe to assume now that the partnership will take place correctly?  It's a bit odd that presently I can specify an arbitrary url and a partnership takes place with any service matching the specified contract.

    Wrt timing, I understand now why the partnership takes so long.  I mentioned in a related thread that I want transparent operation, whether I'm connected to a simulator or hardware camera service.  As a result, I have a WebCamServiceOperations partnership specified as optional (this service is only associated with the hardware webcam service), and in a simulation context it takes some time for dss to decide that the partner doesn't exist.  Barring any race conditions, I think it would make more sense for me to check for this service programmatically- once the webcam partnership is created then it's a no-brainer to poll the service directory without the need for a long timeout.

    Thanks for the heads-up about Sleep(). :-)

    R
    Friday, June 1, 2007 4:45 PM
  •  Rob Sim -- Braintech wrote:
    Thanks George,

    Here's the partnership code inside MyService:
      [Partner("Camera", Contract = webcam.Contract.Identifier,
                     CreationPolicy = PartnerCreationPolicy.UseExisting)]
            webcam.WebCamOperations _camPort = new webcam.WebCamOperations();

    Before I switch to UsePartnerListEntry, I want to make sure I can cover all my bases.  I want to give the end user the opportunity to specify the webcam partner in the MyService manifest, or to specify it programmatically (e.g. they dynamically create a robot/webcam in the simulator) when they use CreateService to create MyService.

    1. UsePartnerListEntry won't try to create the partner service itself, correct?
    2. The partner list entry either comes from the manifest, or the partner list supplied to CreateService, depending on the creation context, correct?
    3. afaict, if the user creates the webcam service using CreateService, the only way to specify the service url is if they use the overload taking a ServiceInfoType, correct?  And it seems to me that there's no direct way to give a service a name programmatically.
    4. If use CreateService with a ServiceInfoType and then create MyService with a partner list containing a partner with a matching service url, is it safe to assume now that the partnership will take place correctly?  It's a bit odd that presently I can specify an arbitrary url and a partnership takes place with any service matching the specified contract.

    Wrt timing, I understand now why the partnership takes so long.  I mentioned in a related thread that I want transparent operation, whether I'm connected to a simulator or hardware camera service.  As a result, I have a WebCamServiceOperations partnership specified as optional (this service is only associated with the hardware webcam service), and in a simulation context it takes some time for dss to decide that the partner doesn't exist.  Barring any race conditions, I think it would make more sense for me to check for this service programmatically- once the webcam partnership is created then it's a no-brainer to poll the service directory without the need for a long timeout.

    Thanks for the heads-up about Sleep(). :-)

    R

     

    1. Correct, thats why its nice if you want 100% control

    2. correct, manifest always overrided code attributes, and programmatic requests are same as manifests. As a matter of fact even if you used *any* PartnerCeationPolicy, we always override using the manifets or programmatic create value

    3. Correct, you need to supply a serviceInfo, and fill in the partner list. And, yes you *can* directly control the name of a service. Just set the ServiceInfo.Service as a URI, with no need to set the port. For example you can set it to ServiceInfo.Service = http://localhost/MyServiceNameIJustChose;

    4. Yes, we match on partner name first, then we match by contract. Indeed we should only match by contract  if the partner name matches, so i will check into this, it might be a "feature"/bug Smile

     

     

     

    Saturday, June 2, 2007 3:44 AM
  • Thanks George,  this is working for me.

    cheers,
    R


    Monday, June 4, 2007 5:23 PM