Custom Surrogate. Well, the use of CoRegisterSurrogateEx() turned out to be easier than I expected. I buildt a small managed sample to... [Commonality]
A few comments on using CoRegisterSurrogateEx.
CoRegisterSurrogateEx expects the application id of an Enterprise Services/COM+ package. It "consumes" the calling thread and sets up the COM+ thread pools, etc. on top of the calling host.
Using CoRegisterSurrogateEx causes your server apps to behave the exact same way as if they were hosted by dllhost.exe. Dllhost.exe is a very thin wrapper around this exact API. If you launching the app from within managed code (as Tomas does it), the activated serviced components will be activated in the default domain of the host and free them from the "GAC ghetto".
Bad news: COM+ will ALWAYS start packages on top of dllhost.exe if an activation occurs and the package isn't running. That means that your custom host must be running before any activation takes place. The best ways to guarantee this are only available on COM+ 1.5:
(a) Disable/Enable the application when your own host spins up and shuts down. That requires that the custom host runs in the context of a principal with write access to the COM+ catalog.
(b) Host the application inside a managed Windows Service, register the COM+ app to "run as NT service" and patch the registry (yes, you heard right) for that service so that the service host is your own host and not dllhost.exe. The registry value to patch is under "SYSTEM\\CurrentControlSet\\Services\\{ServiceName}" and there the ImagePath" value. That must be set to your exe instead of dllhost.exe. The service must be set up to match the logon identity of the COM+ app. It can't be "interactive user", obviously.
If you grab my esutilities and try the EnterpriseServicesApplicationInstaller setting its "UseCustomSurrogateService" property to true, it'll dump a service process exe right next to the registered assembly and do the necessary registry patches. (Source code for some of these things isn't available but will be available in the forseeable future.)
On Windows 2000, you will probably have to register/unregister the whole COM+ app at startup/spindown as Disable/Enable isn't available there. Due to the auto-registration features of Enterprise Services that isn't really as bad as it sounds -- it's still bad, but not SO bad.
Blogging from TornadoCamp.net (just finished the introductory keynote -- CLR; JIT, GC, etc.)
A few comments on Tomas' wishlist...
- As of COM+ 1.5, you have full control over the process lifetime. You can disable/enable, pause/resume, auto-recycle, be notified of spin-up and shutdown and you can host your own process with CoRegisterSurrogateEx()
- As of Win2K SP3 and better, you can define a single port for each DCOM endpoint (per process)
- For a release from the dllhost.exe ghetto (actually from the default domain) and therefore for elimination the need for the GAC, consider my "ServicedComponentEx" hack from this source code archive. (This version only works for server-activated components)
- The archive also has a managed catalog wrapper :)
- I am told that there's indeed a somewhat public load balancing hook in COM+ which would allow you to write your own Application Center if you wanted. I haven't really looked at that yet (I am betting that this is something to look at), but I have no reason to doubt that the source of this information isn't telling me the right thing.
In general, I would say, however, that good use-cases for CLB are fairly rare. Only if you are seeing a huge variation in processing times (eg. user-supplied ad-hoc queries against a data store), CLB is a better tool than load-balancing on the user-tier and bind groups of user-tier servers to dedicated backend servers.
Mission accomplished. 
Ingo Rammer is now an Enterprise Services guy. We had a very interesting discussion at a conference last week and I explained some additional Enterprise Services details to Ingo for which I had no room in my book. We also talked a bit about the results of my analysis of the COM+ patent and I guess that may have sparked Ingo's wish to be able to get at those internals and to be able to extend the "unmanaged context". My impression is that COM+ may be a bit too far down the road in it's life-cycle for Microsoft to make such "extensibility for everyone" happen there, but that the general interest in AOP and the various extensibility points in managed code today seem already to be hinting at a more extensible architecture for whatever type of renovated/rebuilt/new services infrastructure they may come out with tomorrow.
Public revenge. #1 in Germany's mainstream music-charts is "Der Steuersong", performed by an imitator of Gerhard Schröder (Video links 1 2). "You elected me, now you won't get rid of me, we'll raise the taxes and get all money out of your pockets that we can." The Schröder administration will raise taxes and compulsory social insurances fees across the board to counter a "sudden" dramatic drop in tax income for 2002/2003 (>30bn) that they claim didn't know about before this year's elections. And that in one of the worst economical situations in German post-war history. There's going to be a parliamentary commission investigating whether the administration intentionally lied to the people. All that on top of the administration's embarrassing foreign policy and diplomacy. Many people regret their votes. Better start thinking earlier. Thanks :(
Power = Work / Time
.NET Remoting performs as well as or better than DCOM? Binary performs better than XML? A Porsche 911 performs better than a Freightliner Truck? Yes. No.
"Performance" is an abused term. It's too often used as a synonym for "speed" and mostly in a completely unqualified and unquantified context.
Performance belongs on the left side of power = work/time. In contrast, "speed" is simply operations/time. Difference: "operations" is about crunching machine code instructions, "work" is about handling application features.
To execute a remote call, .NET Remoting may be doing just as well (or a tiny bit better) than COM-transport-tunneled serviced components in absolute time -- but there's a lot less work being done by Remoting: context propagation, authentication, authorization, signature, encryption, etc. are things that COM does on top of what Remoting does.
Conversations using protocols that carry binary data are faster than conversations carrying XML in absolute time -- but there's a lot less work being done and the benefit of that work are interoperability, extensibility and enabling of the virtualization of system and network services.
So, Microsoft bans modified XBoxes from XBox Live. I may be alone, but I honestly think that's a reasonable move in the favor of -- plain and simple -- gameplay. The whole online "play with random folks on the Internet" is only fun as long noone is cheating. Mod your box as you wish, but don't ruin my game-night with using an "invulnerability hack". I think that putting mod-chips into the XBox certainly isn't an evil act as such (if I wish I can just as much gut the box and turn it into a cat toilet), but the consequence of being able to mess around with the games and spoil other's fun by being unfair in the online-game certainly is.
The most interesting aspect of service-oriented architectures is that they have potentially unlimited nesting. A full-blown SOA solution is just a simple service to others.
Is WSDL too hard?. In response to Greg Reinacker's comments I didn't say WSDL is hard, I said its cumbersome and unproductive. Come on, its just angle brackets how hard can it be ?? [Simon Fell]
Hard or not hard -- can we agree on "It's just not enough" ? :) My main problem with WSDL is that it tries to do 2 things (message contract and transport mapping), while it should do 3 things (message contract, service contract and transport mapping), however at the same time, one thing (WSDL) shouldn't do all these 3 things altogether but leave them to 3 separate things: A message contract definition language (defines soap:Body content), a service contract definition language (soap:Header) and a "web services binding language" that maps messages combined with services to transports.
It's not easy to read, it's certainly not written to entertain, but still one of the most important pieces of information on COM+ out there: U.S. Patent 6,422,620. PDF browser at espacenet , image and full-text version (you want to look at the text version first) at USPTO.
The patent explains how COM+ works internally -- how stuff gets activated, how policies provide extensibility points, how contexts are built and how context propagation works. The filing of this patent was a long while ago (Aug 17,1998), but the document was only published by the USPTO three months ago and although in XML times it may seem like anything 1998 must be outdated, this stuff describes quite well what's happening inside any copy of Win2K and up. Reminder: It's not a "how to" guide for hooking your own stuff into COM+, but allows you to understand what they've done -- reading this it is also a pretty complicated way to explain to oneself why WS-Coordination is such a relevant WS spec.
Related: US6473791, US6301601, US6134594, US6014666, US5958004, US5890161, US6425017
The event I've been waiting all weekend to announce: Everett is out!
Visual Studio .NET 2003 Final Beta is here:
For MSDN members only:
download: http://msdn.microsoft.com/subscriptions/resources/subdwnld.asp
site: http://msdn.microsoft.com/vstudio/productinfo/vstudio03/
[Sam Gentile's Weblog]
.... that event is also an event that's releasing me of yet another NDA. It's a "freedom of speech" event. Celebrate!
There's tons of cool new things in Everett, but don't look for the next wave of revolutions. Everett comes with very many little improvements here and there, some needed, some nice to have, but no huge new chunks of functionality -- MS simply made a good thing better and that's perfectly cool this time around :)
One of the little things that I really like is that in C#, typing "override<space>" inside a class-body will bring up IntelliSense with choices from the base class. Once you select a method to override, IntelliSense will give you a default implementation for the method that calls the base-class. Pretty.
Architect's Forum, Oslo (Dec. 9-10) is the first stop on the tour. This is the 4th time I am going to be in Norway this year and I am always happy to go back -- Norway is a great country -- it'd be at a "fantastic country" if a beer (in words: one) wouldn't cost at least 7.50.
Benelux, mark your calendars for Feb 18-19: Developer Days 2003. I will be doing a rerun of my Web Services DevCon talk about how to extend ASP.NET Web Services with custom extensions and I am honored to have been invited to do one of the keynotes, which will, among other things, highlight and (maybe) prove that "Enterprise Services" (COM+ if you're of the old-fashined type) is now more than ever heart and soul of scalable, robust and secure .NET server applications.
Pretty much 100% of what I am working on right now is covered by some NDA and still keeps me very busy at the same time. Funny, how one starts to feeling "guilty" about not blogging for a while. With the number of people having linked here and/or are visiting frequently, keeping the blog going really is like "customer service" -- in a good sense.
However, there's light at the end of this tunnel. I am preparing for a speaking tour throughout Europe which will kick off in Norway next month and will continue through 10 more countries from January to April '03. I'll talk about "service-oriented architectures" and "aspect-oriented programming/metadata-driven architectures" on this tour - as usual there's going to be plenty of "demo-code fallout" from brand-new talks, which I'll post around here in the upcoming weeks.
And now for something completely different: http://www.somethingawful.com/photoshop/ ;)
Little known COM feature: CoGetInterceptor. This function provides you with a universal interception mechanism that lets you dynamically inspect all aspects of a call and that feels a lot like .NET Remoting Context interception sinks (which unfortunately went from documented to "internal only" in .NET FW RTM)
I don't have the cycles right now to provide an isolated sample or an in-depth explanation, but it works something like that:
IUnknown * pItfToBeIntercepted;
ICallInterceptor * pInterceptor;
// ... get pItfToBeIntercepted from somewhere
MyEventHandler * myEventHandler = new MyEventHandler( pItfToBeIntercepted ); // implements ICallFrameEvents
CoGetInterceptor(iidToBeIntercepted, NULL, IID_IContextInterceptor, (void**)&pInterceptor); // get interceptor
pInterceptor->RegisterSink( myEventHandler ); // register
with myEventHandler being an instance of a class that implements ICallFrameEvents. That interface has a method OnCall that gives you the ICallFrame info. You forward the call to the actual target object using ICallFrame::Invoke or you can just consume the call right there and not forward.
To get between the caller and the object, you call QueryInterface for iidToBeIntercepted on pInterceptor and hand this reference to the client instead of the actual interface.The actual "inner" interface is wrapped by the class that handles ICallFrameEvents and which forwads the call to it inside OnCall using ICallFrame::Invoke. (as shown in the pseudo-code constructor above).
If the target object is aggregatable, you can do all of this in an outer QueryInterface, proxying each interface being asked for and therefore construct a fully transparent interception layer.
|