Follow up to my previous post regarding the possibility of intercepting a call to ServicedComponent by having it implement IMessageSink. Short story: it doesn't work. Reason: ServicedComponentProxy calls RemotingServices.ExecuteMessage() which basically just dumps the message onto the StackBuilderSink from where the method call will be executed directly.

Whidbey feature request: Interception capabilities for ServicedComponents. Would be pretty cool.

Clemens also just shared his opinion about whether EnterpriseServices are basically only for distributed TX or not.

From the while you've been out-department.

Don found a cool feature in Remoting: MarshalByRefObjects can implement IMessageSink. In this case, when accessed via a transparent proxy, instead of calling the real method, the object's IMessageSink.SyncProcessMessage() will be called by the Remoting framework. Damn, that's cool! [1] Maybe that's how I can even intercept calls to ServicedComponents. I'll try this later ...

However, Don notes that "The one thing this doesn't enable is allowing you to catch BeginInvoke requests.". I'm glad to say that this is not 100% true. For the more curious readers of my blog can find a sample on how to do this here.

The reason why some async calls are handled by SyncProcessMessage() is the following: depending on the kind of Remoting boundary you are crossing, the server has no chance of knowing whether the client sent the call synchronously or asynchronously (and also doesn't care because the thread detachment has already happend on the side of the caller anyway). For example, for a process boundary, everything the server sees is an incoming HTTP request, no matter if the client used a direct call or .BeginInvoke(). However, when you're just working on a context boundary, everything is fine because this boundary is obviously only virtual and the server knows in this case if you're using .BeginInvoke() or not. An AppDomain boundary is somewhat in between .. even though it's virtual, the parameters are marshalled. In this case, the server also has no notion of sync or async calls on the client side ... maybe this should be different, but anyway.

[1] And yes, I didn't know about it before ;)

John Lam joins our discussion of Enterprise Services by discussing the obvious question

If I'm writing a managed application that has a web-based front end, and I don't need distributed transactions, why do I need to care about Enterprise Services?

The essence is, that if you're running transactions on a single resource manager, you don't need [Transaction(TransactionOption.Required)] but instead can simply use your resource managers's direct means of creating and confirming a transaction.

True, if you have full control of your application's source code, don't have to provide means of exensibility, know the exact call flows through all of your infrastructure layer components, and have the luxury of relying on a team of very smart developers of which everybody knows about the very transaction concept you're about to use in your application. No, change this to "a team of very smart developers of which everyone can recite and describe the very transaction concept you're about to use in your application even if you wake him up at 5 am after a long night at the bar.". TX' are just to precious. ;-)

I think however, that there are at least two scenarios where it simply doesn't make too much sense to go the way of imperative transactions:

First, if you're about to provide any kind of extensibility hooks (public interfaces, plugins, ...) you might run into trouble because the component which is dynamically loaded into your app (and of course, not know to you at compile time) could have different TX needs than your main app. It could for example want to run in a different transaction or even want to include another resource manager in your main transaction. Can you solve this without EnterpriseServices? Oh, definitely - E/S isn't magic, it's just some nice concepts. However, providing a clean TX logic in this case could be quite a complex task, because in essence every component would have to vote on the outcome of the TX. Actually, you might end up re-implementing some of the same things which are already available in EnterpriseServices. But why would you want to do so? It could be as easy as going for [Transaction(TransactionOption.Required)] and [Transaction(TransactionOption.RequiresNew)].

The second scenario in which I'd think about using EnterpriseServices is if I don't know the exact call chain of my infrastructure components. Using imperative, single resource manager transactions absolutely requires you to know the very call chain/s which will be used to call your infrastructure components.

<example type="very contrived">
  public void StoreCustomer(Customer cust);
  public void AddOrder(Order ord);
</example>

Perfect. In both methods, you open a transaction, store the data and return success/failure state by means of managed Exceptions. Problem is, when you designed this application like this some time ago, it was absolutely impossible (by the call chain logic in your GUI-based application) that an order could be submitted before the customer would exist in the database for at least some days. No need to share a TX here. (Pretty common scenario in the telco business because new customers have to be validated and approved using a somewhat lengthy process and would only end up in the SAP/R3 system some time later.)

However, your customer contacts you again and asks you (or some other party) to provide a web app which allows sales agents to add VIP customers ( f.e. new branch offices of already existing business customers) directly to your system without any further approval. And yes, they should of course also be allowed to order special services. So, how do you share your TX now? Yes, you could of course do it manually which is quite easy when talking about two methods but which becomes massively more complex when using a multitude of components which have not been designed, right from the start, to allow for sharing a TX. And still, what happens if you suddenly have to integrate other resource managers?

Contrived example? Well, some weeks ago, a developer working at one of my clients, called me up and told me about a problem she's currently facing. It involved a system which has not been designed to be changed but for which the initial developers decided that they know each and every possible call chain.

They were wrong.

The developer who had to extend this system was working for quite some time trying to retrofit TX sharing capabilities into the existing system and came to points where she decided that she had too make too many assumptions about the possible future call chains. The system would be quite fragile and again depend on certain invocation sequences. We discussed the issues on the phone and I recommended to her to look into EnterpriseServices before proceeding. She later sent me a thank-you note after converting most of her components to ServicedComponents instead of using manual TX sharing.

So, at least for me, the question which should be used to choose between declarative and imperative TX (and therefore also in favor or against EnterpriseServices) is not only "Do I need distributed transactions?" but also "Do I need transactions for which I don't know the exact call chains which will be used to access my infrastructure layer components?" and "Will these call chains ever change or could there be new ones?".

If you answered yes to any of these questions, you owe it to yourself to at least look into EnterpriseServices.

Due to some interesting developments which have been started at WIN-DEV and re-confirmed during the last week, I'm currently also spending some time with polishing up my .NET skills. Hey, that's going to be the first time that someone wants to do a hard assesment of my .NET knowledge.

I still miss parts of Code Access Security, COM Interop (but I know someone who knows ;-)) and ASP.NET Web Forms ...

To avoid any rumors: No, I'm not going to find out where this giant sucking sound comes from. No H1B1 visa here, I'm still talking about Europe.

Some of you might wonder why I didn't post too much lately, and didn't even respond or link to a great piece written by Sam Gentile some days ago. The simple reason is that I've been on the road for the last two months and will continue to do so until mid-december. I will basically hit my homebase for only about 5 days within a ten weeks period, and I guess I'll spend most of these days with Katja instead of hanging out on the 'Net. I'm sure you understand ;)

Tomas Restrepo is joining the discussion on EnterpriseServices. He's talking about some of the practical issues of using EnterpriseServices, like load balancing and the necessity of GAC registration.

I like Clemens' current piece about power = work/time in which he states that raw performance must not be the most critical or even the only piece of data on which to base your architecture or implementation choice. (Obvious not-so-joke: else nobody would do J2EE/EJB).

I guess it's also somehow along the lines of: yes, you could implement distributed transaction propagation in Remoting, but why the heck would you want to do so? Use EnterpriseServices and it comes for free. Yes, Remoting might be a little bit faster than EnterpriseServices/DCOM, but as soon as you add all the features (like TX propagation, context propagation, etc.), I guess EnterpriseServices would win even in terms of hard, raw performance.

So, the thing basically comes back to one statement: EnterpriseServices is about Services (which are, for example: security, object pooling, just in time activation (JITA), declarative transactions, distributed transactions, compensation, loosely coupled events, ....). If you need these services, please save yourself from reimplementing them - it could be as easy as setting the correct attributes.

At the end of the day, I think that some people [1] are afraid of EnterpriseServices because of two reasons:

• First, it seems just so much like magic. Throughout history, people have been afraid of things they didn't fully understand and which therefore seemed just too powerful. In medieval Europe people with special skills which weren't available to the general public were denoted as witches and burnt at the stake. Only later, as people got more educated about healing and medicine, nobody considered their skills as black magic anymore. Would you burn your doctor at the stake just because he knows enough to cure your illness?
  The same thing is true with EnterpriseServices. Don't be afraid: they aren't magic. They are just some nice concepts (and by the way the largest production implementation of aspect oriented patterns) which can save you some time.
• Second, there's this thing, COM, in the name "COM+". It seems to be soooo 1990s, right? Forget about it. As Clemens said before, there's no COM/Interop in EnterpriseServices. Calls are marshalled using the Remoting infrastructure over a DCE/RPC [aka DCOM] channel. DCOM is only used as a wire protocol here - zero COM/Interop for the parameters of your method call.

So what can you do to prevent EnterpriseServices from being burnt at the stake - or more important, to save yourself from some work re-implementing already exisiting functionality? Learn about it. I absolutely recommend two books in this area: Clemens Vasters' (German) book ".NET Enterprise Services" and Juval Löwy's book "COM and .NET Component Services". I normally don't read tech books cover to cover, but I can tell you - I did it with both of them.

As soon as you know about EnterpriseServices - and even more important, as soon as you know about its services - you're way better equiped to make the right decision in regard to your application's architecture. Please also keep in mind that EnterpriseServices is not just for distributed or web based applications, but for every component which needs its services.

To summarize: The decision between EnterpriseServices, Web Services and/or Remoting should not be based on raw performance or scalability numbers (because you can in fact create quite well performing and scalable solutions with all of them) but more or less on the features each of these programming model provides:

• EnterpriseServices: Services. TX, security, JITA, object pooling, loosely coupled events, ...
• Web Services: Interop. It's all about interop.
• Remoting: Extensibility & ease of deployment in non-supervised environments (i.e. no SMS, no deployment procedures, no Active Directory, ...).

As I said before, the only thing that's really missing from EnterpriseServices in my opinion, is the ability to add interception layers in the same way we can with .NET Remoting.

[1] Yes, people told me that even I did so in a former life. Guilty as charged.

Why, oh why, doesn't allow EnterpriseServices the same level of interception Remoting does? This would really make the world a better place ... or such. And after all, E/S already uses IMessage & friend ...

If I get one wish granted for V 2.0, let's make it interceptable EnterpriseServices, ok?

OMG, "Advanced .NET Remoting" is in the "Top 10 Editor's Picks: Computers and Internet" for 2002  (and it's the only .NET book there). This rocks!

[sellsbrothers.com: Windows Developer News] New C# Language Features (someday). "On November 7th, at the OOPSLA Conference in Seattle, WA, C# creator Anders Hejlsberg unveiled several potential language features for the next major release of Visual C# .NET. The four primary features Anders spoke about were:

-Generics, a form of C++ templates that makes reusing existing code easier
-Iterators, a construct that makes traversing collections of data significantly faster and easier
-Anonymous methods, an easier way to perform simple tasks using delegates
-Partial types, a means for programmers to split code across multiple files"

All of these features sound really cool (not just generics), but unfortunately the presentation included no mention of when they'd actually ship...

Cool. I'd love to see anonymous methods in C#.

[douglasp] http://www.newgrounds.com/portal/uploads/68000/68643_sw_switch.swf: Great parody.

[douglasp]: Rotor 1.0: It runs on Mac OS X. Let me repeat that. It runs on Mac OS X. I haven't seen a single Mac site run this story yet and only one blog.

Please, don't misunderstand me - I absolutely love Rotor and spent a considerable time with stepping through CLIX.EXE in the debugger. It's a brilliant tool to learn how the framework really works and there's even a friend of mine who's just recently joined this team. Rotor rocks!

But - and that's the sad part - as long as one is not able to really use any CLR implementation on a different platform [1] due to licensing restrictions, I guess thinking about doing so has a fairly limited appeal to the conventional business developer. I have to admit that I therefore couldn't yet ditch my old habits, and still use the other VM when not working on the Windows platform. (Actually, this other VM isn't that bad compared to .NET. To quote Sam Ruby: "insert obvious joke here").

So, I basically have two issues with Rotor right now:

• One can't use it apart from looking at it (which is fine by me ...)
• One can't extend it without in turn limiting others to only look at the extensions but not use them

The second point is what I consider problematic. I'd for example love to take the source code for the TcpChannel and fix some issues - but I can't, because nobody would be allowed to run this channel on the "real CLR". That's too bad ... I have the source code, I would know which lines to change but I mustn't use the changed channel later on. Heck, I can't even take the source, fix the channel and use it for my own applications without breaking the license agreement. Grrrrr ....

[1] Yes, I also know quite a bit about mono. I also really like it, but again - I can't use it in a production environment. In this case, my inability to run programs on it is not based on any licensing issues but instead simply on the fact, that it's not yet done.