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