Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

(Asking this here instead of SO because I don't even know what technology to tag it with :))

My team is about to embark on a project to convert a large part of our code base to use asynchronous file I/O, as our file storage medium is increasingly being locate across a high-latency connection. We have some basic experience with asynchronous development, but this is on a larger scale than our previous work. At this point, I'm not even sure where to begin looking for technologies, patterns, or documentation on how to solve this problem.

The basic setup we have to work within has client applications with a user interface that sends file requests off to some locally-running background process, which does the actual work of communicating with the file storage services to obtain data. (This "proxy" layer is needed because we have a number of client applications that need to share the file services, cached results, etc.)

The design I have in my head would be for a client to submit a request to the service, which would in turn submit a request to the file storage services to begin an asynchronous I/O job. As progress was made downloading the file, the service would receive notifications, and would then fire off some kind of callback mechanism to the UI client to report process and/or completion. This means I need some sort of cross-process mechanism for executing callbacks.

Previously we have use duplex WCF services to implement something similar to this, but I am unsure if it will work properly in our current case. In particular, we want to handle the case where a client submits a request, then exits while the retrieval was in process. The service needs to be able to detect that the client has terminated but keep downloading the file; what I know about WCF duplex channels would imply that the client channel closing would terminate the service's channel as well. In addition, I would prefer not to require the client app to sit in some kind of spin-lock loop waiting for the async call to finish, but again, my research has led me to believe that the duplex callbacks only operate within the context of a single WCF call, so we would need to keep the calling thread around for the duration.

What other mechanisms are there for registering and sending callback-style messages across process? The team would prefer a fully-managed solution, though I'm certainly open to unmanaged options if they are significantly better in some way.

share|improve this question
2  
Keep in mind that the .NET Framework 4.5 will include support for asynchronous processes. In particular, C# 5.0 will include new 'await' and async keywords to simplify writing/managing background processes and callbacks. –  Bernard Dec 15 '11 at 22:38
    
@Bernard finally :) –  Chad Dec 16 '11 at 20:41

1 Answer 1

up vote 4 down vote accepted

As for patterns the "Enterprise Integration Patterns" book could be worth while.

As for technologies I think a service bus, like NServiceBus or MassTransit, might help you.

share|improve this answer
1  
+1 A well-established book explaining the pertinent patterns, and a couple well-established technologies to support the implementation. Don't reinvent the wheel. –  qes Dec 15 '11 at 23:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.