Don Box is just amazing, hale the xml warrior...

1.  The message is the center of things; it will always be available across all indigo versions. Because the message is the center of things
2. Remoting is not going away it will work on longhorn, EnterpriseServices too.
3. asmx is the best solution available.
4. asmx is the facade, once in it you can employ EnterpriseServices as a private implementation. Remoting for communication.
DON'T fool yourself about Remoting. It is a methodology.
Use EnterpriseServices if you care about performance.
Don't build the essence of you application on Remoting.

"No program is an island" - "every program needs another program to work"

"The only people that upgrade their CPU are those that can't get laid"

"We see a trend of having an integration model not based on integrated circuits"

Services are not replacing objects, objects become the "ic". "One metaphor to rule the all(about object)".
Services are about respecting boundaries. It's a program that gets a message and does something. Everything is base of message exchanges. We don't build application, the real world has lots of programs. We build services ], new programs get introduced, old ones recycled or banned , and it's like an organism growing.
Boundaries are explicit, the programmer needs to know when a boundary is being crossed by them. When the boundary is explicit ...
a service is autonomous, service integrity is important

With services we share schema and content not classes. Objects by value screw things up on services (CORBA 2.2,2.3), Schema is 100% structural, no code is required to use it, and I don't need your code to handle the data. Remoting is using objects , asmx is the opposite.

You don't need indigo for doing this right, asmx is the closest thing there is.

Indigo Stack:
1. Service Model - most programmers will code with this. Many attributes
2. Connector - Channels, and transports channels (soap....) policy, security and encoders.
3. Hosting services in indigo can handle :asp.net, .exe, dll host, NT service, .container(Avalon container)


MS is working hard on transaction plumbing, changing the stuff we know. Bringing the transaction to the service oriented world.

No need to derive from MBR

using System;
using System.ServiceModel;

[Service]
class MyService
{
 [ServiceMethod]
 void f(){}
 
 public void g(){} //- a regular method
}

In f(), indigo will make sure the security is ok, because we have marked the f as private you can't use it outside,
 we can have a method that does g() work and f() work together.

Making it more interface - contract like: 
[ServiceContract]
public interface IServiceFoo
{
 [ServiceMethod]
 void f(){}
}

[Service]
class MyService : IServiceFoo
{
 void IServiceFoo.f(){}
 
 public void g(){} //- a regular method
}


indigo is unifying : asmx .net Remoting and Enterprise Services
those were not always talking to each other, indigo is about writing code without knowing about each technology,
 what we could do in those technologies is available thru indigo.
Indigo will be the thing to use on the same machine