RE: Need to share data asynchronously between ASP.NET and Legacy S



Thanks a bunch, will check.
--
Patrick


"Bruce Johnson [C# MVP]" wrote:

> 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
.



Relevant Pages