Joe Long from Microsoft gave a nice talk on the technology roadmap for Indigo,
with a nice dose of prescriptive guidance for those of us who need to do
distributed application development today but want to be mindful of the
future. The talk was framed around this question: how do we support
incremental upgrades of clients and/or servers as we move to Indigo?
Joe suggested two approaches to this problem:
- We can teach the existing infrastructure new protocols. For example, if I have a component written that gets deployed and accessed via Enterprise Services (COM+), Microsoft can shim in some new bits under the hood to teach enterprise services how to talk via Indigo.
- We can teach the new infrastructure about the existing legacy protocols. For example, if I write a new Indigo service, it could fall back in some fashion to talk via DCOM.
Microsoft is opting for the first approach – move the underlying protocols
forward and don’t look back. This does place some constraints on what you do
today and what might or might not work in the future. Joe covered several of
the common cases, which I’ll briefly discuss here.
COM+ Binary Interoperability
Interesting stuff here – the goal is to not force a recompile of clients or
servers by utilizing a bridged service environment. There are a few
requirements for this to work though:
- Servers must have a type library for metadata
- Components must be COM+ / Enterprise Services. Sorry, your ATL DCOM NT Service won’t magically be accessible via Indigo.
- You must be explicit about interface types when used as parameters, i.e., don’t pass around IUnknown references.
- Avoid explicit use of COSERVERINFO.
- Custom proxy/stub marshalling will not be supported.
MSMQ Binary Interoperability
I was a bit confused on this point, but it appears that Indigo will provide
Indigo compatibility by automatically exposing MSMQ servers via web services.
ASMX Web Services
No real concerns about interoperability here, since this is SOAP/XML.
.NET Remoting and WSE
Out of luck – don’t expect much help here.
Migrating Code to Indigo
I won’t go into extensive detail here – you can check out the presentation
yourself if you would like
more details. The gist of changes revolves around instantiation of servers and
proxies – everything else can pretty much remain the same if you are writing
ASMX web services or Enterprise Services components today. .NET remoting is
mostly orphaned, though porting won’t be too difficult. The use of “new” to
create client proxies will not be supported.
Where Should We Host Server Components?
I asked this question at the end of the talk. In the Longhorn world, as in
today, there are two primary hosts for components – IIS / ASP.NET, and
Enterprise Services. Joe’s recommendation was to use ASMX web services by
default and host in IIS. If you need Enterprise Services, go ahead and use it
but opt for the library component model and still host in IIS if at all