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+:
Perf: (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.
DCOM: 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!
first of all I'll be happy to talk with you. you can reach me via my e-mail, if you want.
I'm not frustrated or confused by all of those technologies. I think I know them well and when and where to use them. But that not the point. The point is that before I have that chance to build system architecture and then design I need to convince my customer
to use all of those solutions. As you know we are not alone in the enterprise software fields, so we need to compete other vendors suggestions.
now you can turn it as much as you want but customers wants application server and they want it as ONE solution that they need to take care of (not to mention other vendor solution that we are missing). They don't want to hear about operating system being application
server. enterprises software are building for years of use and they need to be maintain over different OS (even if they are just MS OS). they feel more secure with AS that need to be change by certain vendor to run their (unchanged) code, rather to be responsible
to migrate their code to new OS. they want that all of their code if writing for ASP.NET or BizTalk or exchange will run by the same AS providing container that let them use AOP to ask for service or add their own.
I cant talk about indigo since it isn't here already and I don't (and probably you) got any production experience with it. anyway 2 years is a lot of time ... and I don't see indigo answering all our concerns so ...
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.