locked
Subscribe behavior? RRS feed

  • Question

  • I'm modifying some working services to use generic contracts in a multi-headed way. I've broken something related to Subscribe and I'm not sure what.

     

    Previously, SerialPortOperations supported a Subscribe port and a SensorObservation (which was derived from Update). An internal timer in SerialPortService posted SensorObservation messages to itself. SystemModelService subscribed to SerialPortService. SerialPortService.SensorObservationHandler did a SendNotification on the subscriptionmanager port with the SensorObservation object (which is defined to contain sensor data as part of its contract). SystemModelService defined an arbiter when it receives a SensorObsevation on its sensorNotify port. This all worked correctly.

     

    I created a SensorStreamContract that support Subscribe and SensorObservation. I removed Subscribe and SensorOperations from SerialPortOperations and added an AlternateContract for the new SensorStreamContract. The partner definition between SystemModelService and SerialPortService did not change and the subscribe request is successful. The problem is that my SendNotifications in the SerialPortService no longer make it back to the SystemModelService.

     

    And I just found the problem. I had set SerialPortOperations to use SensorObservation and SystemModelService to use Proxy.SensorObservation. Sending the SensorObservation from SerialPortOperations was not triggering the Arbiter for Proxy.SensorOperations in the SystemModelService. It seems that services that implement contracts have to use Proxies.

     

    Which leads to another question: Is there any use for the non-proxy assembly for a generic contract if all it contains is a generic contract?

    Monday, October 8, 2007 5:48 AM

Answers

  •  

    If you implement multiple contracts in a service, you should use multiple subscription managers, since they will manage the subscriptions for each contract, and keep thte subscribers seperate between the "base" contract and any alternate contracts.

     

    Regarding the use of the non-proxy assembly for a generic contract, one that only contains types: As you point out subscribers should always use the proxy, unless there are special considerations (like helpers on types that only exist in the original assembly). The original generic contract assembly is there just to generate the proxy Smile

    Monday, October 8, 2007 6:50 PM