I heard that Ingo Rammer quoted "i have
[Ingo, offcially confirmed that *wasted* is not quoted by him]
In MSDN article "Introducing Longhorn for Developers" & Introducing Indigo: An Early Look,
Indigo is a set of .NET technologies for building and running connected systems, best of ASMX + Remoting. Indigo service applications support two main communications types: a stateless model (Indigo Web Services), in which messages are received with few if any guarantees, and a stateful model (Indigo RemoteObject Services), which creates a communication session between two service objects. The stateless model is equivalent to current-day Web services and is useful when broadcasting noncritical information. The stateful model, on the other hand, uses session state to enable Web services to provide functionality across the Internet, including callback methods, events, widely distributed transactions, and reliability and durability guarantees that enterprise applications require.
Indigo RemoteObject applications are built using the Indigo SOAP messaging infrastructure; therefore, they support end-to-end security features, including authentication and encryption, widely distributed and long-running transactions, automatic activation, and a robust management infrastructure, in addition to providing the ability to perform interface-based remoting and use asynchronous server methods.
I'm still not sure if Indigo RemoteObject will work behind a firewall, if you know pls let me know. Happen to view the msdn channel 9 video of Richard Turner {Indigo Program Manager} looks like, stage is all set for Indigo and we know about that so called *support* he is talking about and as a matter of fact Indigo will NOT support Windows 2000 either.
With all the performance the remoting framework suppose to deliver, it looks like somebody throwed the baby out with the bathwater. Looking at MSDNtv, Matt Tavis was demonstrating some of the feature enhancements to remoting infrastructure in Whidbey, my guess nothing will be added in Orcas version of .NET.
IpcChannel - for inter process communication in same box, avoids the overhead of network stack
Secure TcpChannel - built-in support for encryption, signing and authentication
Version Tolerant Serialization - more a serialization feature but this allows for versioning of types without worrying about failing to de/serialize when communicating with older versions on the client/server
some more that i didn't understand
Finally a word from Ingo about this
"The role of Remoting after Indigo? Hmm ... it will be the same role as the one of ASP.NET Web services, WSE 2.0, MSMQ, and Enterprise Services/COM+: Existing apps will continue to work (you can even run Indigo and any of these previous technologies in the same application and AppDomain). New apps (or parts thereof) will however quite likely be developed directly based on Indigo. (If running on Windows XP, Windows Server 2003 or - future - Longhorn as these are the only platforms which will be supported). "Normal" apps with the previous technologies (Remoting, ASP.NET, ...) will be quite easy to migrate. Custom transport channels and custom sinks will be harder to move ... i.e. they will have to be rewritten using the new extensibility models. Oh btw: Remoting will also continue to exist for areas which are not addressed by Indigo like cross-AppDomain communication. After all: Indigo is based on Remoting's __TransparentProxy architecture anyway ;-) "
No, there is no need to push the panic button and stop using remoting in new projects, a Prescriptive Guidance for Today's Technologies by Richard Turner's Tech-Ed session.
1 comment:
Hi,
Well ... I tend to say that "I spent a two years on Remoting" ... I can not remember calling it "wasted".
Actually, the contrary might even be true: it taught me more about distributed applications than I ever dared to ask for ... ;-)
-Ingo
Post a Comment