Sign in
IRhetoric - Karsten Januszewski
Avalon: Convergence in the Simulacrum
Translate This Page
Translate this page
Powered by
Microsoft® Translator
Options
Blog Home
Email Blog Author
Share this
RSS for posts
Atom
RSS for comments
Search
Tags
.NET Framework 2.0 (Whidbey)
3D
Action Script
Avalon
Expression Blend
Facebook
Flash
MIX07
Pages
Philosophy
sxsw
Twitter
Vista
WCF
weblive
Windows Communication Foundation
Windows Presentation Foundation (Avalon)
WPF
WPF TWITTER
WPF/e
Archive
Archives
August 2007
(1)
June 2007
(6)
May 2007
(7)
April 2007
(2)
March 2007
(7)
February 2007
(5)
January 2007
(8)
December 2006
(5)
November 2006
(6)
October 2006
(9)
September 2006
(2)
August 2006
(3)
July 2006
(3)
June 2006
(12)
May 2006
(8)
April 2006
(7)
March 2006
(4)
February 2006
(8)
January 2006
(9)
December 2005
(4)
November 2005
(9)
October 2005
(10)
September 2005
(4)
August 2005
(1)
July 2005
(5)
June 2005
(19)
May 2005
(9)
April 2005
(4)
March 2005
(1)
February 2005
(2)
January 2005
(3)
December 2004
(1)
November 2004
(4)
August 2004
(2)
July 2004
(3)
June 2004
(3)
May 2004
(3)
April 2004
(5)
March 2004
(3)
February 2004
(3)
Answering Some Questions About Indigo
MSDN Blogs
>
IRhetoric - Karsten Januszewski
>
Answering Some Questions About Indigo
Answering Some Questions About Indigo
karstenj
13 Feb 2004 7:46 PM
Comments
8
A great
post
by Ken Brubaker that I wanted to address...
Aren't both ASMX and Remoting equally dead-ends for services since both are basically RPC structures (i.e. Function Call)
If Indigo will not look like either ASMX or Remoting, how could either be better. They're both dead ends.
Not at all! Think of Indigo as the evolution and ultimate rationalization of .NET Remoting, ASMX and Enterprise Services. Those three technologies are the fundamental foundations for Indigo, not dead ends. The method vs. message distinction gets confusing, in that anyone looking under the hood at ASMX understands that the method calls manifest as messages, as you point out yourself below. A lot of work ends up getting done to shield the developer from the fact that messages are going across the wire. And, in fact, getting at the message can be difficult. One of the goals of Indigo is to provide a method-based programming model, but allows developers to work with the message if they choose to.
How can Indigo be message-based across a firewall? The whole point of a firewall is to not allow the server to call back to the client. A message-based system
implies
call backs.
Assume the client is not just a client, but an addressable node. If you've played with callbacks in .NET remoting, you'll notice that the client has to provide a callback address. Indigo works similarly, in that the client must be addressable.
Doesn't RPC serve a very useful purpose of eliminating the need for an Ack/Nak protocol? I'd hate to have to build Ack/Nak into every one of my future Web Services.
The reliable messaging infrastructure in Indigo is designed to provide Ack/Nak delivery guarantees -- without the developer having to build it themselves.
Can't we design an ASMX that simulates a message-based system? Isn't asynchronous similar to two one way messages? Couldn't you just define your functions so that there is no out or ref parameters or any return value?
You are right on as far as one way methods that return void. The trick would be getting a one-way message to the client if the client is not addressable. If you look at what .NET Remoting has done in the space, you can glean how such an infrastructure could be extended to ASMX, given an addressable client, which is what Indigo will provide. Expect more on this topic...
8 Comments
Blog - Comment List MSDN TechNet
Comments
Loading...