locked
WCF Event/callback architecture... RRS feed

  • Question

  • Hello,

    I'm looking into implementing a nice simple example of server events/callbacks.

    I've gone through the MSDN duplex example...which is fine...

    I notice that really the events 'fire' during the context of a server method call.

    i.e.

    client calls server...

    during call server calls client

    end of server method.

     

    If I want to instigate async calls from the server to the client then there seems to be 2 options.

    i) save the callback interface on the server (probably on construction of the server object)

    ii) (as in sample) only call client during a method call.

     

    ii) feels intrinsically preferable BUT...is there anything wrong with potentially being in that method call for hours/days?.....

    how do I log off?...call another method on the server on another client thread?

     

    Advice?

     

    Monday, June 21, 2010 9:44 AM

Answers

  • Remember that WCF calls should be of short duration.  A call should not be around for hours/days.  Remeber that there is a configuration paramter that defines a time out period and the time out defaults to one minute (you can increase it, but from what I have read, you really want to keep service calls short).  This should be more than enough for any calls to complete.  If it takes longer than that, then you start to have problems with other calls to the service timing out because by default only 10 requests can be processed at a time (you can increase it by changing the behavior on the binding, but it should be done only when absolutely necessary). 

    I have used a callback interface, but it is usally reserved for a specific scenario, one in which the service does some processing of its own and must send out updates to clients.  A good example of this might be a performance monitoring service.  The service will check the performance of the system every 10 seconds or so and must send out to clients what the performance was.  In this case, the client must subscribe to the service and provide its own endpoint for the service to talk to (it has its own self-hosted service listining for replies from the service).  In this case, the client can expect that every 10 seconds it will get a request from the service that it needs to process and display on the screen.  Notice that in the callback scenario, the client has actually become the service and the service has become the client (to an extent).  In this scenario the service has to keep track of its clients so that it knows who to send requests to.

    A book that I found useful when I started programming with WCF was "Programming WCF Services" by Juval Lowy and you may want to pick up a book like that for some guidance if you are going to start building business critical applications with WCF.  That is just my thoughts, I hope they help.

    Monday, June 21, 2010 4:35 PM

All replies

  • I've now found the listbased publish subscribe example....but to be honest....I think option ii above may be preferable...
    Monday, June 21, 2010 9:47 AM
  • Hello,

    check this article http://msdn.microsoft.com/en-us/magazine/cc163537.aspx I hope it will answer your questions.

    Best regards,
    Ladislav

    Monday, June 21, 2010 9:49 AM
  • You answered your own question really qhen you said you want the callbacks to be async. If you try to block as method call that the client makes so you can callback then the client will timeout (unless they use one-way messaging). Just save the callback proxies in a list and callback when you need to. Just be aware of receive timeouts in both directions that may render the proxy useless
    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Monday, June 21, 2010 10:09 AM
  • I was assuming one way....

     

    Thread 1 on client calls "subscribe"...that blocks...and returns 'events'

    When client wants to unsubscribe...it calls (on thread 2) unsubscribe....that makes 'subscribe' return.

    I prefer it (instinctively) because it the return path to the client seems to be (logically) scoped by a call from client to server...so to use it...you need to be in a method call.

    Monday, June 21, 2010 11:02 AM
  • I'll take a look at the magazine link...thanks.
    Monday, June 21, 2010 11:03 AM
  • The magazine thing...looks very complicated...my way the subscription is captured by the blocking call to Subscribe...if there is an error..it will be handled by the RPC protocol...i.e. the client disappears..the callback fails... the call to subscribe fails....seems to make sense....I don't need to track it in a list of subscriptions...in the same way I don't track method calls...threads do that for me.
    Monday, June 21, 2010 11:10 AM
  • I think I'll build it and see what happens...
    Monday, June 21, 2010 11:11 AM
  • Actually having built it and seen what it does, and build a 'standard' WCF callback....it would seem to make more sense to poll!....and block if there is no new data.

    (or return Maybe<T> after a timeout period...)....i.e. like a simple MSMQ read interface.

     

     

    Monday, June 21, 2010 4:03 PM
  • Remember that WCF calls should be of short duration.  A call should not be around for hours/days.  Remeber that there is a configuration paramter that defines a time out period and the time out defaults to one minute (you can increase it, but from what I have read, you really want to keep service calls short).  This should be more than enough for any calls to complete.  If it takes longer than that, then you start to have problems with other calls to the service timing out because by default only 10 requests can be processed at a time (you can increase it by changing the behavior on the binding, but it should be done only when absolutely necessary). 

    I have used a callback interface, but it is usally reserved for a specific scenario, one in which the service does some processing of its own and must send out updates to clients.  A good example of this might be a performance monitoring service.  The service will check the performance of the system every 10 seconds or so and must send out to clients what the performance was.  In this case, the client must subscribe to the service and provide its own endpoint for the service to talk to (it has its own self-hosted service listining for replies from the service).  In this case, the client can expect that every 10 seconds it will get a request from the service that it needs to process and display on the screen.  Notice that in the callback scenario, the client has actually become the service and the service has become the client (to an extent).  In this scenario the service has to keep track of its clients so that it knows who to send requests to.

    A book that I found useful when I started programming with WCF was "Programming WCF Services" by Juval Lowy and you may want to pick up a book like that for some guidance if you are going to start building business critical applications with WCF.  That is just my thoughts, I hope they help.

    Monday, June 21, 2010 4:35 PM