locked
Why are Subscribe/ReliableSubscribe messages re-implemented in every service contract? RRS feed

  • Question

  • I have wondered about this for quite some time as I have started making my own services and found myself constantly recoding the same Subscribe and ReliableSubscibe messages over and over again in each new service. The definitions always use the same Microsoft.Dss.ServiceModel.Dssp.ReliableSubscribeRequestType/SubscribeRequestType/SubscribeResponseType types.

    Re-implementing Get in every contract is required because each contract returns its own state. The only reasonable explination I can fathom for the Subscribe reimplementation is so that subscibes to one contract are specific (employs type safety since each subscrbe is specific to each contract) and therefore removes some coding/debugging confusion. Maybe just a leftover artifact from previous version of MRDS?

    Bryan
    Wednesday, January 7, 2009 3:50 PM

Answers

  • Hi Bryan,

    This is a reasonable question. I don't know the history, but it has been discussed internally before.

    Note that a Subscribe handler should send a Replace notification to each subscriber when they subscribe. This initializes the state inside the subscriber and makes sure that it is in synch with the service. In some cases this is not necessary because the subscriber is only interested in changes in state. I think that it is not entirely obvious from some of the samples that you should send a Replace notification immediately because some services do not do it and therefore appear to contain exactly the same code. As you noted, the service state is different for each service, so sending the initial Replace (another operation that has to be implemented for each service) is hard to generalize.

    I'm going to raise a bug as a suggestion that Subscribe and ReliableSubscribe be implemented in DssServiceBase so that you don't have to do it yourself. This is easier now that we have an attribute for the Service State so we can find the state using reflection.

    Of course, if you wanted to override these handlers you would still be able to do this. This is similar to the model for HttpGet now where you don't have to provide one any more.

    Trevor

    • Proposed as answer by Erik Oppedijk Wednesday, January 14, 2009 8:17 AM
    • Marked as answer by Bryan Roth Wednesday, January 14, 2009 1:58 PM
    Wednesday, January 14, 2009 2:14 AM
  • Darn! You know how you hit "Post" and then realise you had not finished ... Well here is a little more info ...

    The other issue with Subscribe is that if it sends a Replace notification, then Replace needs to be implemented as an operation so there is a dependency on the PortSet (and corresponding handler). I don't like making service start-up slower (while it reflects on itself), but on the other hand it hides some non-essential infrastructure and makes RDS easier to use.

    Trevor
    • Proposed as answer by Erik Oppedijk Wednesday, January 14, 2009 8:17 AM
    • Marked as answer by Trevor Taylor Friday, January 16, 2009 6:29 AM
    Wednesday, January 14, 2009 2:23 AM

All replies

  • Hi Bryan,

    This is a reasonable question. I don't know the history, but it has been discussed internally before.

    Note that a Subscribe handler should send a Replace notification to each subscriber when they subscribe. This initializes the state inside the subscriber and makes sure that it is in synch with the service. In some cases this is not necessary because the subscriber is only interested in changes in state. I think that it is not entirely obvious from some of the samples that you should send a Replace notification immediately because some services do not do it and therefore appear to contain exactly the same code. As you noted, the service state is different for each service, so sending the initial Replace (another operation that has to be implemented for each service) is hard to generalize.

    I'm going to raise a bug as a suggestion that Subscribe and ReliableSubscribe be implemented in DssServiceBase so that you don't have to do it yourself. This is easier now that we have an attribute for the Service State so we can find the state using reflection.

    Of course, if you wanted to override these handlers you would still be able to do this. This is similar to the model for HttpGet now where you don't have to provide one any more.

    Trevor

    • Proposed as answer by Erik Oppedijk Wednesday, January 14, 2009 8:17 AM
    • Marked as answer by Bryan Roth Wednesday, January 14, 2009 1:58 PM
    Wednesday, January 14, 2009 2:14 AM
  • Darn! You know how you hit "Post" and then realise you had not finished ... Well here is a little more info ...

    The other issue with Subscribe is that if it sends a Replace notification, then Replace needs to be implemented as an operation so there is a dependency on the PortSet (and corresponding handler). I don't like making service start-up slower (while it reflects on itself), but on the other hand it hides some non-essential infrastructure and makes RDS easier to use.

    Trevor
    • Proposed as answer by Erik Oppedijk Wednesday, January 14, 2009 8:17 AM
    • Marked as answer by Trevor Taylor Friday, January 16, 2009 6:29 AM
    Wednesday, January 14, 2009 2:23 AM
  • Trevor

    Thanks for the response. I was aware of the Replace notification and inferred its use as I became more familiar with what MRDS was all about. I do agree that an addition to the documentation would be helpful.

    Thanks
    Bryan
    Wednesday, January 14, 2009 2:03 PM