How do I implement a WCF asynch service call so it can continually receive callbask from clients?


I'm building a series of VB.Net WCF services.
The break down of the services is as follows:

RecorderService: Persists data to the DB.

ListenerService: Receives events from attached clients, then
pushes data to RecorderService to process.

The client wants the following scenario/design.

1) ListenerService exposes an async method.

2) The RecorderService calls into the ListenerService.
When the ListenerService has data available, it will call back (via the async callback)
into the RecorderService. The RecorderService will then persist to the DB.

So basically, the ListenerService will hold on to that Recorder callback
and push data to it whenever data becomes available.

I've haven't done much with async callbacks in the world of WCF.
Can someone point me to an example/pattern which relatively matches my needs?

jxbmaSoftware ConsultantAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ste5anSenior DeveloperCommented:
hmm, without further information 2) makes no sense. Why should the recorder service call the listener?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I agree that this design doesnt make a lot of sense. As a matter of fact, using services here is probably out of place - a message-driven architecture might be a better choice here. Think MSMQ, ApacheMQ, NServiceBus and so on. A classical publisher-subscriber case.

then pushes data to RecorderService

Wouldnt it be better for it to *Discover* (WCF Discovery) a RecorderService and push data to it when it has anything? This is going to be more fault-tolerant and scalable. Alternatively, a Listener can use Configuration to truly push to a recorder. In both cases there is only one way coupling, in that, only the Listener is dependent on the Recorder.

However, what you are trying to achieve by the recorder subscribing for events is possible using duplex communication. The idea is that the service an always callback and invoke a method on the client by using the OperationContext. This article demonstrates the concept:
jxbmaSoftware ConsultantAuthor Commented:
Agreed on the design comments. Despite my strong protests, the client is insisting on the design.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.