Answering Some Questions About Indigo

  • Article

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