Thanks for responding to my original post. I am picking up this thread after Jonathan's post. Since he covered some of the initial responses I had to your response to my last message, I won't re-iterate too much on them here.
With regards Windows being an App Server ... I think Jonathan summed it up nicely - Windows is an application server in that it gives you multiple ways of hosting and running your code.
HOWEVER, I share your frustration and confusion as to which is the best technology to use in order to host your apps - should you use ASMX, ES/COM+, Remoting, etc. I delivered a presentation at the MVP summit here in Redmond a few weeks ago outlining our prescriptive guidance on which technologies to use and in which scenarios.
This guidance was carefully formed by a number of factors. One of those factors is what we know about how you'll likely be writing, testing, deploying and operating your applications and systems in the coming years. You see, we know about Indigo!
We in the Indigo team also own DCOM, COM+, ES, MSMQ, System.NET, Remoting and ASMX. We know that it's frustrating for you to have to write your code differently, depending on how it'll be hosted - in an EXE, as an ASMX WebService, as an ES component, etc. This is why Indigo consolidates and supersedes all of the technologies and capabilities of our existing distributed app services into one clean, consistent, .NET technology.
This will mean you'll write your code once and then decide how to deploy and host it at runtime - whether as an EXE, hosted to serve HTTP or TCP, it's your call - you just change your service's config settings.
Further, you mentioned that you wanted to snap-in your own services (such as logging etc) that the platform will support. On this front, Indigo will give you a HUGE amount of flexibility. Indigo supports a fully pluggable pipeline message transport architecture, so if you wanted to provide, for example, your own logging engine, you would simply write a custom ChannelProvider that parses the incoming message and logs the information you're interested in to a store of your choice. The service developer doesn't even (necessarily) need to write a line of code for their service to take advantage of your logging engine! Of course, you'll also be able to write .NET assemblies that provide attributes and classes to control and manipulate your channel providers if you wish that level of control.
And before I forget ... on the code portability front: The VAST majority of your code will run just fine if and when you migrate to our Longhorn platform. Existing COM+, MSMQ, Win32 stuff will work fine. All your current .NET development will move over just as easily. And if you want to take full advantage of the Indigo infrastructure and want to port your .NET code to use Indigo, we're doing a heck of a lot of work to make sure your migration path is as smooth as possible!
I know details are a little thin on the ground right now, but be assured that there will be a great deal of information flowing from Redmond over the next year or two on just what Indigo is, what is does and how it will greatly benefit you in developing Secure, Reliable, Transacted systems.
Finally, on the subject of ES/COM+:
(Have just read your paper) You mention that your experiences of ES have resulted in very different perf characteristics to the demo we published on MSDN ... be very interested in discussing further. Were you
a) Creating the object, calling it repeatedly and then releasing it?
b) Repeatedly creating, calling and disposing the object?
If b: you're not going to be taking advantage of JITA and won't see the perf' benefits I mention.
Why DCOM? DCOM is fast. VERY fast! Via DCOM we could support the HUGE array of existing COM based componentry. AND DCOM came for free when we built ES on top of COM+!!
For the future, Indigo natively talks SOAP & WS-* over HTTP and TCP (and IPC for x-process), and is extensible enough to allow you to write your own wire serializers/marshallers if you wish to handle unusual wire protocols.
Thanks for your throughts and discourse though - I really appreciate you taking the time to press your case. Be assured ... we ARE listening!