It got increasingly difficult to distribute my sample code, because the dependencies on the set of standard libraries that I've built over the past months just keep growing. I fell in the same trap for the "polished" version of the samples for TechEd so that I decided to make a cut and make a whole "SDK" out of this stuff, finally (I think I've written about that a while ago) and simply make it a prerequisite for installing additional demos. That takes away a lot of the repetitive work for building installers over and over again. The MSI file is almost finished and I think I should be able to make a first drop available by tomorrow.
From Monday until the end of the week I will take a desperately needed week of vacation. I'll just get into the car and drive up north to the sea. No computer in the luggage. I won't even try to read email.
Sorry, Testing. Welcome DIPLOMAT, bye bye AMBASSADOR. I just inaugurated a brand new 60GB harddrive for my notebook by installing a new OS and I am finally, finally on Win03 for good. Nothing beats lots of RAM and a fast disk. That notebook is screeeeaaming now.
Ingo has some new guidance around Remoting. While I don't agree with him on giving any "perfectly okay" marks the WAN case in his feature/scenarios matrix, most of the rules make sense to me for a LAN scenario that doesn't need to scale heavily. Still, the "put state into the database" rule is a bit strict and probably needs a little more thought; after all, the database is just another shared service. Also, in a LAN where security doesn't play much of a role, you probably also don't need to scale unexpectedly as it happens on the web and therefore the whole "host in IIS" and "single call only" business seems a bit strict, too.
And if you didn't believe me until now, here's Ingo with some definitive guidance around ASMX, ES and Remoting that I obviously very much agree with:
- If you plan on using SOAP Web Services to integrate different platforms or different companies, I really urge you to look into ASMX (ASP.NET) Web Services instead of Remoting.
- Do not try to fit distributed transactions, security, and such into custom channel sinks. Instead, use Enterprise Services if applicable in your environment.
I summarize his guidance for an old COM guy like myself as:
Whatever was cool with OLE Automation* is cool with Remoting. If the use-case looks much different, look elsewhere.
*(no security or scalability to worry about, chatty interaction, stateful objects, events, late binding)
"ServicedComponentEx" broken: The code that I published a year ago here in order to fix the dependency of ServicedComponents on the default appdomain (and its config) no longer works with the Framework 1.1. The reason for that is that the cross-appdomain case of Remoting now explicitly filters calls to IRemoteDispatch and rejects them. The way the proxy attribute of my hack works is that it redirects the activation into a different AppDomain and therefore causes a "double proxy" to be created. The proxy that the ES infrastructure talks to is indeed a cross-appdomain proxy which talks to a transparent serviced component proxy in the target appdomain. If a managed call comes in from a different process, it wants to talk to IRemoteDispatch to circumvent COM/Interop (IRemoteDispatch is where the DCOM tunneled binary serializer packages get dropped in) and that call then gets forwarded into the secondary app domain through the cross-appdomain proxy.
Now, in the 1.1 Framework, any IRemoteDispatch calls through Remoting are explicitly rejected and hence the hack no longer works. Bummer. However, I did expect some things to break and this should be a reminder that any hacks in undocumented territory that you may find anywhere are not guaranteed to work in the next version, even point releases of the Framework. I am poking around to get the functionality restored, but based on what I've figured out so far it doesn't really seem possible without either violating the rules of the game in very horrible ways or moving this functionality into the core framework I built to make aspects work ....
Craig Andera on why AOP is broken & Why I surprisingly agree and what I am doing about it
Craig Andera has some interesting thoughts around AOP and specifically mentions the stuff that I have been doing in that area. And he say that it doesn't work and never has, because services are never truly orthogonal and have various interdependencies. In essence he's saying (I guess) that because the interdependencies just create a whole new level of complexity, the AOP approach is broken and it's better to generate explicit code instead of using interception techniques. I partially agree and always put a warning at the end of all of my talks around this issue: There is a limited set of use-cases for which an aspect'ish approach is useful. Security, logging, monitoring, billing, transaction enlistment, and a few others.
One of the biggest problems is service-order. You need to run the decryption and signature verification services before you can even evaulate a header that any other service can use. And even then, when you have something like a transaction-enlistment filter, do you open the transaction before or after a logging service wants to write something to a database? Does the logged data need to stay in the logging store when a transaction aborts? Yes? What if the log is used for billing? No? What if the log is used for diagnostics?
However, being explicit when chaining services together doesn't make things any better than using interception:
try
{
handleServiceA(msg);
handleServiceB(msg);
handleServiceC(msg);
}
catch( Exception e )
{
// do proper handling
}
is just as broken. I don't think it fundamentally matters much how code gets woven into the call chain. Setting up contexts is just one issue. What's even more difficult is to find a way to deal with errors in the presence of cooperating aspects (or, in more general terms, interception services). What's clear is that there's no way around interception-driven services in a web services world. It's all pipeline-based and, even worse, the pipelines are distributed pipelines of pipelines. It's too simple to say "it's broken, get over it". That doesn't help solving what is an actual problem.
A promising approach is to make aspects/interceptors act like resource managers and coordinate their work using a very lightweight 2PC protocol ("AC" guarantee only; no "ID"). Using 2PC for this approach allows interceptors/aspects to coordinate their work and know about each other before any work actually gets done. I have discussed these issues with a couple of people in depth we put some code together that essentially implements a little, in-memory "DTC" for that purpose. We call it a "WorkSet" instead of a transaction. There's still some work to be done there, but I think I'll be able to post an example in a little while. Maybe around TechEd Europe time.
Sam on Perf
Sam outs himself as a fan of low-level performance optimization. That's all good and fair, but often micro-optimization just takes way too much time with way too little of a result for the overall application throughput and its scalability. For distributed apps, the true optimization happens during the architecture phase. Or, as my friend Steve Swartz put it during our "Scalable Apps" tour: When you are stuck in a traffic jam with a Porsche, all you do is burn more gas in idle. Scalability is about building wider roads, not about building faster cars.
On 400 level sessions and scores
Samer Ibrahim writes "I believe that a 400 level session should present 400 level material regardless of how many people have never wrote a single line of code in their entire life. That's not my problem and that's not fair to those of us who are here to get an edge. Find 100-200 level sessions instead."
My WEB404 session at TechEd US was probably a 500 because I really had lots (too much) of code. The downside of doing 400 level sessions at an event with a very broad audience spectrum is that you are getting killed in the feedback and scores after the talk, no matter what you do. Either you're too shallow for some or you are too deep down in the bits for others. Now, what needs to be understood is that speakers will often scale back on content if they feel that the content is too deep for the audience they have, just because it'll kill their average score. There's lots of competition behind the scenes on that.
What was new at this TechEd was that the written comments are now available to MS in "softcopy", which means that they get printed up with the numbers. And if you have only 10 people in an audience of 300 who write "Thank you, this session was really helpful for me", you feel like you have done your job right and MS sees that too, which is of much higher importance for "us" external speakers than the average score.
So, here's a hint: My understanding is that the scoring system is still open over the weekend at www.mymsevents.com. If you attended a session that you found helpful and on which you haven't given a score so far, do so and don't forget to write a comment stating what you liked or what you would like to see improved. That's especially true for sessions with deep and focused technical content and lots of people in the audience. These will typically get comparatively bad scores, because it's nearly impossible that the content is absolutely relevant for 400 or 600 people in a room at a conference like that. So, if you think that the speaker did a good job, say so. You'll be heard.
(I should add that I am fairly happy with my scores already and I am not begging ;)
Andres observes that Steve and I are in agreement on very many things, including what to put on slides in talks covering services, layering and tiering. ;)
Clemens - I attended your two sessions, AOP and "I dont know you could do that". Excellent stuff. Couple of questions I have:
1. I heard, and I might be wrong(and please correct me if I am), that you have serious issues with .Net Remoting. Is that true, and if it is, why? 2. In an app where you want to cache objects, would you use com+ object pooling, or are there better ways to cache your objects?
And last, but not least, have u written any papers? And can you tell me any good book to go deep into the stuff that you talked about?
Thanks Ali / Ali Khawaja • 6/6/03; 5:53:13 PM
1. I don't have serious issues with Remoting as such. I am just saying that it is the successor of Automation and not of the full blown DCOM model. Hence, it is useful in all the scenarios (mostly on-machine) where Automation is useful in the unmanaged world. Once you go across machines where security plays a role and when you need an appropriate hosting and process model for your objects, there is Enterprise Services. Whenever you see a need to add a custom channel sink to Remoting for authentication, authorization, encryption, or signature, there is a fair chance that you are using the wrong technology set. Whenever you think you need to write a custom host for you app in order to tune the thread pool and up the number of available threads for Remoting, you are using the wrong technology set. There's nothing fundamentally wrong about Remoting -- there's just a limited set of use-cases where it is applicable. My issue with it is only how many people are using it and how it is being portrayed as the successor to DCOM, which it is not.
One thing is important to keep in mind: The COM transport sits on top of Microsoft RPC, which is, in turn, the core technology stack that essentially powers most call-level communication between the components of Windows and hence has had full kernel support ever since the NT kernel saw the light of day. RPC supports virtually all network protocols as well as shared-memory marshaled L(R)PC [read!] for on-machine calls. Remoting sits on top of the CLR and on top of the Framework, which, in turn, sits on the Win32 user-level API. That's a wholly different ballgame.
Enterprise Services has a very elegant solution for mixing the two models in that it uses Remoting to do almost all marshaling work (with two exceptions: QC and calls with isomorphic call sigs) and then tunnels the serialized IMessage through DCOM transport, which means that you get full CLR type fidelity while using a rock solid transport that has been continuously optimized ever since 1993. I understand that some people consider a 10 year old protocol boring; I just call it "stable". Also I see people complaining about COM being hard to deploy, because it requires use of the registry and distribution of proxies. Admittedly, there's some truth to that, but in the end, you will also have to deploy and customize config files for Remoting and distribute proxies there. That's true for any RPC-type technology and is, as per current practice, even true for most Web Services. For distributed systems of any scale, "xcopy deployment" is a sweet dream. There's work to do.
2. Yes. Enterprise Services object pooling is great to pool object instances and guard access to limited resources.
Finally, I have written a book on Enterprise Services, which is, for a variety of historic reasons, in German. However, I am talking to a publisher for translation and once that happens I will definitely rev it so that it incoporates all of my "current" thinking (of course).
Ingo has WSE 2.0 and is obviously all excited about it.
PerfectTheft.
PerfectXml.com has a redirect tool up that presents this blog (and everyone else's blog) on their site: http://www.perfectxml.com/RSSConnect/RR.asp?u=http://radio.weblogs.com/0108971/rss.xml. Since they didn't get back on my email, I'll have to tell them in public:
Any content of this blog is my property. The RSS feed is available for aggregation and personal information by anyone, BUT if you republish my weblog on your website without my permission, you are stealing intellectual property and you are violating my copyright. Take that redirector down or block my blog.
|