Sponsored Link •
Bill Venners: When you said, "...distributed apps are built in a loosely connected, stateless fashion...", what did you mean by "stateless?"
Anders Hejlsberg: If you program in a remote-objects fashion, whenever you instantiate a new object you may actually end up holding a proxy to a remote object that truly gets instantiated in memory on some computer somewhere else in the distributed system. And as long as you hold onto the reference on this machine, you are keeping state alive on that box over there. And you can enter into very long-lived transactions--transactions that might keep state alive on that box for a long time. That's problematic in a failover scenario, and it's problematic in a scaling scenario, because you can't easily distribute. Once you pick that box, you have to go back to that box every time a call comes in.
Whereas with HTTP, you are sort of forced to reckon with the problem that HTTP is stateless. Since there is no memory in the system about the channel--the channel has no state in it--you are forced to design your system such that every incoming request can freely get routed to any CPU that can then fetch the state, jiggle it, and stuff it back. And then the next time around you can go somewhere else.
Bill Venners: It's not necessarily stateless on the server. State is being stored.
Anders Hejlsberg: There is state, but no state is being kept alive by the distributed mechanism.
Bill Venners: I'm not sure I understand what the difference is. In both cases there's state. What the advantage of not having state in the distribution mechanism?
Anders Hejlsberg: It's funny. In a sense, a web service takes away the capability for you to instantiate a new object, hold onto it, and call methods on it. A web service is just an entry point. Any state that goes in, you have to pass in. Any state that comes out, the web service passes back out to you and then forgets about it. It's not like there's some object that's inherently kept alive. There's no notion of a session.
Bill Venners: In the protocol, there's no notion of a session.
Anders Hejlsberg: Exactly.
Bill Venners: But usually there is a session on the server.
Anders Hejlsberg: Of course. But you end up designing how that session works. We don't tell you that there must be a particular kind of session concept that amounts to: the client instantiates a new object, and as long as they hold onto it, that state is alive on the server and you better figure out how to make that work.