RE: Need to share data asynchronously between ASP.NET and Legacy Syste
- From: "Bruce Johnson [C# MVP]" <bruce@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 28 May 2005 14:07:06 -0700
What you might want to look at as a good starting point would be the Caching
Application Block provided by the Patterns and Practices group at Microsoft.
The block implements caching expiration by creating a background thread that
wakes up when an expiration takes place. The approach that they take (which
is basically to create a thread in Application_Start) would do what you're
looking to accomplish, I believe.
Hope that helps.
--
Bruce Johnson [C# MVP]
http://www.objectsharp.com/blogs/bruce
"inetmug" wrote:
> Hello:
>
> I am using ASP.NET as our front end. I also have to interface to some
> legacy systems that use a callback mechanism. The legacy systems use
> callbacks (via CORBA) to communicate back to clients. The ASP.NET web pages
> will initiate communication with the legacy backend, but results from the
> backend will often take quite some time and will be asynchronous in nature in
> their return. We have successfully created a prototype that integrates .NET
> and ASP.NET with the CORBA backend using the IONA Artix product. Its works
> very nicely and is fully based on Web Services and is transport agnostic.
>
> I want to take this prototype and create an application, or separate thread
> in IIS that can access the legacy systems, handle the callbacks, and store
> the results of the callbacks so that subsequent requests can access the data,
> or client based applets or J# Browser Controls on the client can listen for
> the data. I am looking for a method to share data between the standard
> ASP.NET HTTP pipeline and this “legacy handling thread”, or application.
> Things that come to mind is the ASP.NET cache, application state, or some
> other state mechanism. The issue is this is really not state, but data that
> is returned from the asynchronous callbacks. I have looked into to
> IHTTPAsyncHandler but it looks like that mechanism really exists to offload
> the CLR threadpool so more requests can be handled (makes perfect sense).
> What I need is a thread running that is not associated with any specific
> request. This thread should run in the IIS process space, but needs to share
> data with requests. This is somewhat like what the Shared Property Manager
> did in MTS.
>
> The ultimate goal would be to implement the Observer pattern. That is, a
> request can execute a synchronous method and register for some work to be
> done asynchronously by the back end system. Then the browser clients would
> be notified when the work has completed. Things that come to mind here are
> applets and web services.
>
> Any suggestions here would be greatly appreciated. Thanks.
>
> --
> Patrick
.
- References:
- Prev by Date: RE: Webservice handling amount of requests per sec/min.......
- Next by Date: RE: Sending requests to two different servers
- Previous by thread: Need to share data asynchronously between ASP.NET and Legacy Syste
- Next by thread: Webservice handling amount of requests per sec/min.......
- Index(es):
Relevant Pages
|