Share via

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

Comments

  • Anonymous
    February 14, 2004
    Thanks for your quick response, Karsten! Now if I could just ask one more question... :)

    http://dotnetjunkies.com/WebLog/kenbrubaker/archive/2004/02/14/7265.aspx
  • Anonymous
    February 18, 2004
    How will aspect oriented programming via interception be handled in Longhorn? I’ve read where ‘Indigo’ is the messaging system in Longhorn. However, it appears that ‘Indigo’ may only be addressing ‘Service Oriented Architecture’ scenarios between different machines. How will interception occur between objects within the same process?

    As an example you can currently create a context attribute, a context property, and an appropriate message sink. Since this method is undocumented and may disappear in Longhorn will there be a substitute method to use?
  • Anonymous
    February 19, 2004
    The comment has been removed
  • Anonymous
    February 20, 2004
    I spoke with an Indigo architect about the whole aspect thing the other day. The current approach to building apects will change radically with Indigo, however the support in netFx will not change. Indigo is an OS pillar that is implemented in managed code, it does not replace or affect netFx all at.

    If you need aspect oriented solutions that span across the longhorn operation system, the only way to pull it off is via ContributeObjectSinks.

    The details (that aren't covered under NDA) are on my blog.



    Paul

  • Anonymous
    February 23, 2004
    Thank you for your response. We had one additional question. When you mentioned the only way to pull it off when spanning across the longhorn operating system was via ContributeObjectSink did you mean to imply that ContributeEnvoySink, ContributeContextServerSink, and ContributeClientContextSink will not be supported in longhorn?
  • Anonymous
    March 30, 2004
    I don't see how this answers the question about firewalls. How is the server going to call back to a client behind a firewall? Is indigo assuming that firewalls will be changed or just ignoring them?
  • Anonymous
    April 05, 2004
    Depending on the scenario, there are different solutions to the firewall issue. If there are two computers in the whole P2P universe and both are behind firewalls that block incoming connection requests, Indigo does not solve this, and nothing else can either. This is by design (of the firewalls). However, if there are two computers, one is behind a firewall, and one is not (can accept incoming connections), with Indigo, after an initial setup handshake, both can send messages at anytime (both act as if they are not firewalled).

    We are also looking into providing SOAP Relays: This is a service outside the firewall that provides a publicly addressable endpoint to clients inside the firewall. A client keeps a TCP duplex connection open with the relay, and advertises its reply address as the address on the relay. The relay simply forwards messages to the client.

    You can think of the SOAP relay as similar to a Teredo server, but it can apply SOAP level routing, authentication, etc. to messages.

    The SOAP relay solution would require the firewall to allow outbound TCP connections.


  • Anonymous
    June 15, 2009
    PingBack from http://debtsolutionsnow.info/story.php?id=582