In RXX library document we see this concerning WCF using Observables...
Just add System.ServiceModel.Reactive.ObservableServiceAttribute to your service interface or class and define operations that return IObservable<T>.
Viola somehow, someway data get's pushed to subscriber.
So if this is doable in WCF what about ASPX.NET? We know that AJAX is an Asynchronous pull based architecture. But what about a ASPX Get request that returns an observable. Could it be done? Example we put a clock on a web page showing server time, could a Subscription to that observerable suffice to update the clock on a Web Page?
I wouldn't see the underlying support in HTTP protocol because each trip represents a single GET or POST request and the session is closed. But if WCF can do it wouldn't there be a way in ASPX? BTW, How does WCF do it? This would be a radical shit from PULL based GETs and POSTs...
JP Cowboy Coders Unite!
It's a very good idea, but I don't think that Rxx's feature for WCF works the way that you think it does.
Rxx enables you to create an IObservable<T> service, but it doesn't enable remote clients to consume it as a pushed-based sequence by calling Subscribe. Instead, Rxx's support is purely a server-side implementation that wraps the already existing support in WCF for defining asynchronous operations.
In other words, WCF allows you to create asynchronous operations by defining a pair of methods, Begin* and End*. Clients don't know anything about this; i.e., the WSDL is unaffected. Rxx simply wraps this functionality by allowing you to create an asynchronous operation by defining a single method that returns an IObservable<T>. Calling the method behaves like calling Begin* and calling OnCompleted behaves like calling End*. The data that is pushed through the sequence is buffered on the server until OnCompleted is called. Then either the last element in the sequence or the entire sequence converted into a list (e.g., Array_Of_T in SOAP) is sent to the client, depending upon the options you've chosen for the operation.
The benefit of writing asynchronous operations is that it allows the server to free up pooled threads to handle other requests while an operation is waiting for things like network and file I/O to complete; however, the client's connection is technically still a synchronous (pull-based) connection to the data. WCF does not return anything to the client until the operation completes. It is not a truly reactive service.
ASP.NET provides a similar feature to allow requests to be handled asynchronously, though it's not a truly reactive solution. And in fact, the Rx team wrote a similar wrapper a while ago:
It was called ObservableHttpHandler and it could be used in a similar way as I've described above for WCF.
I've actually written an entire RESTful framework that uses ObservableHttpHandler to enable a simple model for defining asynchronous service operations in ASP.NET. It turns out that MS had a similar idea to simplify RESTful services in .NET 4.5 by introducing the ASP.NET Web API, though I haven't looked at it yet so I don't know whether it natively supports asynchronous operations. If it does, then I'd be happy to wrap it just like I did for WCF.
> We know that AJAX is an Asynchronous pull based architecture. But what about a ASPX Get request that returns an observable.
> Could it be done?
Yes, it can be done. I've recently been investigating Web Sockets, new in .NET 4.5, in an attempt to do exactly what you're asking. I'm sure that a lot of people are though.
I believe the common goal is to enable IQbservable<T> support over web sockets. The big problem is that Expression trees aren't serializable, though the Rx team has reported that they are working on something in this space. I'm very interested to see what solutions they come up with.
A secondary goal might be to enable a simple client/server scenario (IObserver<T>/IObservable<T>) by offering client-side and server-side APIs that generalize subscription behavior over a custom protocol (with web sockets as the transport) and then simply serialize T. The service won't be queryable but at least it will be a truly reactive service. This should be fairly easy to do in theory, though I've found that working with Web Sockets isn't that easy because it seems that browsers don't support it yet. I'll continue my research though, when I find the time. If I develop a prototype I'll probably check it into the Rxx library.
Again Dave, thanks for excellent breakdown on this. It'll take me a week or longer to digest. I'll post back then. It's an exciting time for me now after having transformed all my thinking to event based vistor pattern programming styles, and now the whole Observable thing. It's kind of like being a Gold Miner, you think your on to something but you really have to dig in to get there.
JP Cowboy Coders Unite!