OK, sorry. No code this time, but quite useful information, I think.

Rick Strahl asks about the relationship between COM, COM+ and Indigo,

First: no, Indigo does not communicate on the wire using DCOM.
But Microsoft provides the ability to expose (even existing) COM+ services as Indigo services without requiring any code change in the COM(+) implementation on the server side. You just need to run a tool and a corresponding 'invisible' Indigo service is built for you. This service exposes the COM+ component to the wire, as an Indigo style web service.

But there is still the 'other direction'. What about COM(+) calling Indigo services? For this, we may use the special Indigo moniker to enable COM developers (like VB6, VBA etc. geeks) to communicate with the Indigo services in a COM-like but Indigo-natural manner.
So let's go a bit into detail.

COM+ application as an Indigo service

It is a tool thing. Using Indigo’s COM+ integration feature, a developer is able to do this without making any code changes. Just run the Indigo integration utility on the appropriate application interfaces. When the COM+ application is restarted, the appropriate Indigo service will be started and there will be a rich functioning Web service interface to the existing business logic - which of course does not mean that one should expose *any* COM application via an ‘automatic Web services interface’… just like the checkbox feature in COM+ to enable ‘SOAP functionality’ (which uses .NET Remoting in fact).

With this feature developers are able to specify the binding, transport and address choices, determining where and how the service will be offered - all just through manipulation of a standard Indigo configuration file. No new code. Where the COM components within the application support or require transactions, the Indigo service will convey that requirement and support it on incoming request messages. Where the components within the application require authentication and authorization (i.e. Windows identity and thus COM+ roles), the Indigo service will convey that (authentication) requirement and enforce it (the authorization) on incoming request messages.

The behavior of the services fronting the COM+ application are provided by an automatically started Indigo listener and controlled by a standard Indigo configuration file.

By default, the service will mimic the RPC-like behavior of DCOM with reliable request-reply sessions using Indigo’s shared session instancing. The default binding, transport and address details come from a generated (at COM+ application/interface opt-in time) config file. Also, to mimic a secure DCOM deployment Windows authentication and encryption will be required by default. Different behaviors are only a config edit away.

COM client calling Indigo services

With the deployment of Indigo/Web services within their organization, both built on Indigo or other technology stacks (like IBM WebSphere, BEA WebLogic, or Axis), developers will be faced with difficult choices and significant challenges when deciding how to bring this newly developed functionality into the widely deployed COM based environments such as Office/Excel, ASP, VB6 or script. Using the Indigo service moniker, a simple approach to integration is provided. The execution of the moniker builds upon a local definition of the Web service interface – there are a few ways top to get this but one of the easiest is for developers to point the Indigo svcutil.exe tool at the URL of the service's metadata exchange endpoint (/MEX). This creates a client proxy and service interface details.
After ensuring that the type library from that assembly is marked ComVisibleand referencing it from a development environment e.g. VB project, we are able to use the service moniker with the GetObject function to construct a proxy instance for that service within our 'legacy' code.
Just like this (OK, a bit of ‘old’ code, at least):

Dim MathProxy As IMathService
Dim result As Integer

Set MathProxy = GetObject( _
  "service:address=http://localhost/MathService, _
  binding= wsProfileBinding, _
  bindingName=Binding1")

result = AddService.Add(3, 5)

The COM Service Moniker takes most of its wire functionality directly from the standard Indigo client infrastructure and its binding configuration from a simple config file. Additionally, rather than simply picking up the current identity, the new IChannelCredentialsinterface on the proxy instance supports specifying credentials using a range of broadly interoperable mechanisms e.g. username/password or X509 certificates from a file or store.
Also, subject to configuration, when operating within a transaction scope, the transaction will flow using standard Indigo ServiceModel transaction mechanisms with the use of WS-AT on the wire where appropriate.

A big thanks goes to Microsoft's Andy Milligan for helping me putting together this information.

OK, and now off to the CeBIT computer show for the whole next week – then Florida J.