The message from Joe Long a PUM with XML Enterprise Services is that there's an easy migration path from existing applications to Indigo.  The changes are mostly using different namespaces and attributes.  Most of the code inside methods stays the same, except for .NET remoting where instead of using 'new' inside a method the developer has to explicitly state that the object is created remotely

Key Questions

• I have an app - how do I make binary work with Indigo?
• Now how do I move the code to Indigo
• If I start writing a new app today, what should I do to best set myself up to move to Indigo?

There are two approaches to integrating:

• Teach the infrastructure new protocols. Put WS-Security into the existing infrastructure like DCOM and MSMQ
• Teach new infrastructure with existing protocols.  The problem is that these protocols don't interop or work over internet.

Various points

• ASMX code migration is basically just a matter of changing the namespaces and attributes, the code within the methods just work.
• .NET remoting requires similar basic changes.  Is .NET Remoting dead?  No, it's used inside the same process, creating objects and treating them like local objects.  The only difference is the new - you have to declare whether you're doing it locally or remote.  Channels or sinks are not supported, but most of the time these were used to overcome limitations in the platform.  Now things are better.
• There will be a new version of WSE (WSE 3.0?) before Indigo is releases.  The latest version of WSE will also be supported.

WSE code migration

•  Migrating WSE code to Indigo may require a non-trivial development investment.
• There will be whitepapers saying how to migrate.

The key PDC message, or welcome to the Service Oriented World

• Objects are appropriate within boundaries
• Services are appropriate across and within boundaries

What to do today

Build services using ASMX

• Enhance your ASMX service with WSE if you need the WSE feature set and you can accept the support policy

Use object technology in a service’s implementation

• Use Enterprise Services if you need ES rich feature set, you are communicating between components on the local machine and have performance issues with ASMX or WSE
• Use .NET Remoting if you need to integrate with an existing proprietary protocol, you are communicating in-process, cross app domain
  Use System.Messaging if you need the reliable messaging and queuing features in MSMQ

Things to watch out for today

ASMX

• Avoid or abstract using low-level extensibility such as the HTTP Context object

.NET Remoting

• Avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels

Enterprise Services

• Avoid passing object references inside of ES
• Do not use COM+ APIs – use System.EnterpriseServices
• Do not use MSMQ APIs – use System.Messaging