I'm currently on the train from Munich, Germany to Vienna, Austria. I spent the last days in the community of some great people at Basta!2002 where I did three sessions on .NET Remoting technologies. The first one provided a general overview of the differences between .NET Remoting, ASP.NET Web Services and well known friends like DCOM.

For the second and third talk, Arne asked me to do some real advanced stuff. I therefore showed the .NET Remoting extensibility model and the underlying concepts like proxies, messages, sink chains and sink providers with a whole lot of sample code.

The third talk has been the best one ... it's been on ContextBoundObject and the possibilities of tapping into some sort of "Design by Contract" or AOP by the use of context properties, attributes and custom sinks. This has been mostly a code-only session and my audience was absolutely brilliant here. I really loved this talk!

• .NET Remoting vs. ASP.NET Web Service vs. DCOM at 12:20 on February 27
• Inside .NET Remoting - Extending the Framework at 2:20 pm on February 28
• ContextBoundObject - The Power of Message Based Processing at 3:40 pm on February 28

If you happen to be there, just say "Hi" before or after the talk to have a little chat.

- Note to self: check out arstechnica's article about .NET - everyone else already has done so.

I guess the most interesting .NET Remoting threads come up on [DOTNET] whenever I don't follow it as closely as I normally do. [still writing on the last chapter]. Thanks to one reader who forwarded a reference to this thread to my private email address I've been able to investigate a little and post a new article about "Using a custom .NET Remoting proxy for cross AppDomain calls".

But be warned ... you'll be entering uncharted territory!

I just sent the last chapter of "Advanced .NET Remoting" to my reviewer. yyyyyyyyyyyyeeeeesss it's done!

I want to take this as reason enough to say thanks to some of you who've made working on this book especially fun for me -- maybe without you knowing it yet.
[alphabetically ;-)]

• Christian Weyer
• Dave Winer
• Ingemar Lundberg
• James A. Sievert
• John Lam
• John Sims
• Mike Woodring
• Orion A. Buttigieg
• Patrick Logan
• Peter Drayton
• Pradeep Tapadiya
• Sam Ruby
• Simon Fell

Thanks for all the great discussions, email- and weblog exchanges with you!

Well, those have just been the people who did not directly participate in making this book. Of course my biggest thanks go out to everyone who joined me on this project (alphabetically as well, no preferences indicated ;-)): Alexa, Ami, Dan, Kent, Gary, Grace, Stephanie and everyone else from Apress or Springer NY who helped to make the best book on this technology. You've been brilliant!

Last but not least I have to thank Katja for still being with me even though I used to close the door to my room for some hours a day - and also for keeping most day-to-day duties from me while I've been working on this book. For you see, each day I love you more, today more than yesterday and less than tomorrow.

I have two good news regarding my book today: first and foremost, it's nearly finished. I just send the last but one chapter to my reviewer and will start to work on the very last chapter in some minutes. This also means [second news ;-)] that I can now reveal the currently planned release date for this book: April, 5th 2002.

Until now, May 2002 was official because I didn't want to put myself into too much pressure to meet a deadline ... I like quality books, not rushed ones ;-)

- Regarding WSDL again: Sam just showed a brilliant attitude towards this subject: "having developers code SOAPAction and endpoint information directly into their logic seems so twentieth century". Well, I agree!

If you want to get "the real stuff", you can of course check the official specification at http://www.w3.org/TR/wsdl, but be aware that this is more than fourty printed pages ...

As I'm currently working on the last chapters of my book, I wanted to reveal the fact that I'm not really working alone. Here you can see the most recent photo of my one and only co-author right after he finished checking his emails.

As some of you know, I've been offline (a.k.a "out-of-town) for the last three days. Now I found an excellent statement from Dave: "A note of congratulations to Microsoft and best wishes for a successful launch of Visual Studio .NET, tomorrow. We look forward to many years of happy interop."

Wow! The only thing left to say is that I fully support this attitude. With all those great chances we're facing in regard to web services in the not-so-distant future, I don't really believe that "hell froze over", but instead that we might finally be able bury the hatchet which has been used as a base for religious debates among developers using other programming languages or paradigms.

Finally, we can work together!

I guess you better don't think about me as a romantic optimist [1] in this case ;-). I've "been there, done that" in a project that integrates C/C++, Java, Visual Basic, VBScript, PHP, ColdFusion and some others to form a massive system which leverage existing implemented application logic. This also allowed us to use the best programming environment for the given task without sacrificing the overall application architecture.

Well ... I did it - so can you!

[1] even though I sometimes may be ...

Well ... I'm back from my current three day trip out of town.

You know what's worst with having no email access during > 50 hours? Coming back and having to read through hundreds of them ;-).

Guess it will take some more hours until I'll be able to post something "meaningful" ;-)

Just wanted to let you know that I'll be out of town for the next three days. I might have some email access but unfortunately I'm not yet posting with Radio and CityDesk does not accept weblog posts by email ;-).

So there won't be any new posts until Wednesday ..

Simon, the reason why I'm a WSDL FM fan is simple:

I guess that SOAP & web services in general will only really take off as soon as they are absolutely easy to use. For me, Radio together with WSDL FM was easy to use.

Let's recap the steps necessary to make Radio talk to .NET Remoting:

• Write the .NET Remoting Web Service and start the server
• Run WSDL FM and point it to the (automatically generated) WSDL
• Write <% someservice.someMethod() %> in Radio

I did never ever have to know about SoapActions, method namespaces or anything like this. The tools (.NET Remoting on the server side and WSDL FM on the client) took care of this for me.

I think this tool support will be essential for the success of web services. Developer's shouldn't have to worry about those kind of "internals". They should instead care about solving their application domain specific issues. We need those kinds of tools for other platforms and languages (compilers and scripting) as well!

You might also want to compare this with other (manual) approaches - IMHO there are too many possibilities of problems with those.

This, Dave, is the real reason why I believe that we need WSDL for our web services.

Yesterday, Simon Fell did the only reasonable thing. While everyone else (at least Dave, Sam, John and me) were trying to convince each other that WSDL is either great (John, Sam & me) or is absolutely unnecessary (mostly Dave ;-)), Simon hacked a tool that will WSDL-enable Radio.

This thing is just brilliant!

To show how nice it works, I just did the following little .NET Remoting web service:

using System;

public class TestingRadio: MarshalByRefObject {

   public String getLocalTime(String yourname) {
        Console.WriteLine("Service called from " + yourname +
             " at " + DateTime.Now.ToString()); 

        return "Hi " + yourname + ". Local time is " +
             DateTime.Now.ToString() + " [CET]";
   }
}

After creating a "generic" .NET Remoting server (which is about 10 lines of code as a console application; not using IIS here!), I used Simon's WSDL FM and pointed it to a copy of this service's WSDL at http://www.dotnetremoting.cc/DotNetCentric/radiotest.wsdl to generate the following Radio macro (watch out for line breaks!):

on getLocalTime ( yourname)
{
    local (retval, params={"yourname": yourname});
    retval = soap.rpc.client ( 
        soapAction: "http://schemas.microsoft.com/clr/
nsassem/TestingRadio/TestObjects#getLocalTime",
        rpcServer: "212.88.191.179",
        rpcPort: 5555,
        actionURI: "/RadioTest.soap",
        methodName: "getLocalTime",
        adrParams: @params,
        methodNamespace: "m",
        methodNamespaceURI: "http://schemas.microsoft.com/clr/
nsassem/TestingRadio/TestObjects%2C%20Version%3D1.0.770.40188%2C
%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull" );
    return retval ;
}

It's best to start Simon's tool directly from the "Macros"-subdirectory of Radio, else this macro has to be manually placed in the correct subdirectory (Macros\TestingRadioPort) before it can be called with a line like following from a Radio post:

Got the following reply: 
<% TestingRadioPort.getLocalTime("World") %>

This is interop ;-)! Thanks Simon, Sam & Dave! (btw. you can check the result on my "inoffical" Radio testbed).

Note: This sample web service will only be available for the next some hours, so if you want to play around you better be quick ;-)

Dave replied to my earlier post: "No longer are we the unwashed masses yearning to be taught the true path to enlightenment by the C developers now they're pleading with us to help them work around limits in their crippled environments. Heh.".

:-) In fact, I've never been a C developer nor did I ever tell any scripting developer that he's using bad tools and therefore needs to be enlightened. Scripting tools are great; so are compilers. I regularily use both of them ...

The only problem for me is, that people like Dave (or John as well) are trying to put up a wall between a "Compiler User" and a "Scripting Developer" whereas there is none. I'm fine with you and as long as you give me the WSDL, I frankly don't care how your Web Service has been implemented ;-)

Recently, Don Box posted an article on MSDN on scripting languages providing web services. It's summarized as "A personal appeal to the Web services community to make type-safety a priority by writing WSDL for script-based Web services.".

When reading this, some people in the scripting community shouted "Fire! Fire! Don is trashing scripting languages - let's show him our community's power ..." and started to interpret Don's article in many interesting ways:

There were the ones from the hardcore scripting league like Dave who accused Don of showing "[the] arrogance of C programmers" and stated the IMHO true fact that "scripting languages are here to stay.". Patrick for example also said that "Compile-time type checking is not a sufficient contract.", but web service clients have to be tested as well to ensure consistency. This is of course true, but having WSDL simply decreases the number of potential problems.

Naturally there were replies to those posts by hardcore compiler users like John Lam  who wouldn't ever touch a scripting language: "Dynamically typed languages suck".

In my opinion nevertheless, Don's article was not about scripting languages vs. compiled languages. It's just been a plea to scripting developers who publish web services to write WSDL, so that all those poor compiler users don't have to write it themselves. Yes, compiler languages are limiting - and if the web service providers don't write the WSDL, everyone who wants to consume their services has to write it on his own ...

So I can just beg all of you to calm down as Don's article has IMHO not been meant as a offense to anyone. I'd also like to re-state his plea: Scripting Community, help us poor compiler users and supply the WSDL for your services. We know that you don't need it and we know that we will have to test our programs whether or not we have the interface definition in machine readable format. But you can just help us a little here which in turn might even increase the acceptance of your great web services. So I guess it's a win/win for all of us.

After all, Scripting languages and compilers are here to stay!

And isn't this whole web services idea about interoperability? So we maybe better stop bashing each other's technology ...

Update: Read my reply to Dave's post here.

Fellow google conspiracy theorist John Lam posted a new "undocumented C#" article on the use of the CLR varargs calling convention. His point: It's possible but SLOOOOOW. I guess I'll stay with the five times faster param object[]

btw John, google just switched back to the current cache ...

Patrick Logan asked on ASP.NET web services vs. .NET Remoting: I wonder why Microsoft has established this dichotomy?

.NET Remoting simply supports some proprietary "object oriented" extensions. You can for example return "object references" from remoting web services. In this case the framework automatically generates a unique endpoint for each objects' instance.
Those references to a specific instance can then be passed around in the network just like normal parameters and calls to these objects are automatically mapped to the corresponding endpoints. This happens transparently ...

And of course .NET Remoting allows for somewhat easy binding to other transport protocols like SMTP, MSMQ, ... i.e. the SOAP binding for SMTP/POP3 took me only around two days to implement.

Looks like I should buy Ingo's book when it comes out.

:-) thanks for these kind words.

Today John Lam joined the group of people having their own theories about Google ;-) [1].

In fact this happend exactly on the same day on which google switched back their main servers to an older version of the index and cache. Today you won't find my weblog on google ... (and IUnknown.com is cached in a way older version as well)

I still guess there's a lot more going on behind the scenes at Google than one might imagine.

[1] Oh, yes ... I also have some ;)

I recently checked the Web for any reliable and reproducable performance numbers of .NET Remoting's various channels compared to ASP.NET web services.

I could not find any ...

What I'm going to do in the next days (after finishing the chapter I'm currently working on) is to compare the following techs

• ASP.NET via HTTP
• ASP.NET via HTTPS
• .NET Remoting via HTTP/Soap, hosted in command line application
• .NET Remoting via HTTP/Binary hosted in command line application
• .NET Remoting via HTTP/Soap, hosted in IIS
• .NET Remoting via HTTP/Binary hosted in IIS
• .NET Remoting via HTTPS/Soap, hosted in IIS
• .NET Remoting via HTTPS/Binary hosted in IIS
• .NET Remoting via TCP/Soap, hosted in command line application
• .NET Remoting via TCP/Binary hosted in command line application

Anything else you'd be interested?

Something different: In one of yesterday's posts I mentioned that I did an SMTP Channel for .NET Remoting. This is true and it will be in my book (and the code will be downloadable). Unfortunately I just cannot share this code yet ...

Today Bill Gates gave the closing keynote for the Visual Studio.NET Launch event in Vienna, Austria. Yes, we've been first ...

In the morning the notoriously brilliant David Chappell kicked off this event with one of his typical keynotes. It's just great when people can combine technology with funny stories to tell.

And yes ... there's been a whole lot of people ...

The photo on the left has only been possible because my co-worker Josef Kammerhofer kindly changed seats with me ... thanks for this! [yes, I had to promise to mention him here ;-)]

On .NET Remoting performance ...

Apart from the performance tests I've already mentioned, I'm going to include the following as well:

• .NET Remoting via HTTP/Soap, hosted in IIS with no authentication
• .NET Remoting via HTTP/Soap, hosted in IIS with basic authentication
• .NET Remoting via HTTP/Soap, hosted in IIS with integrated authentication

After my comment earlier today, Simon pointed out that "[...] oft cited wisdom is to use remoting for .NET to .NET work, and ASP.NET WebServices for Interop with other platforms". This is generally true, even though there shouldn't be too many problems (at least not for the "hello world"-style web services presented during the discussion ;)) when working only with Server Activated Objects. Client Activated Objects or passing object references, etc are definitely not supported in any cross-platform environment [1].

Regarding the SMTP binding for .NET Remoting: Been there, done that [2] ;). By the way, does anyone know any other standards or recommendations apart from http://www.pocketsoap.com/specs/smtpbinding/ which point in this direction?

[1] Maybe apart from Intrinsyc's Ja.Net but a) I didn't try it yet and b) it doesn't solve the core problem but it just "extends" the reach of a proprietary solution ... [and I didn't use properietary as a bad word here because I really like the concepts behind .NET Remoting]

[2] And in fact, passing CAOs (aka object references) around in SMTP messages between various servers and clients appears to be a little .... strange. But it's possible ;)

In the ongoing discussion of web services' overhead (both in Lines Of Code and servers necessary) with .NET, Java or scripting languages, Patrick stated that IIS is mandatory (and Simon who's normally very in-favor of .NET repeated it as well ;-) ) for .NET web services.

This is somehow only true for ASP.NET web services. I don't know how much you take .NET Remoting as web services in the classic sense, but as the Group A and Group B interop results show, MS .NET Remoting should be quite fine even in cross-platform scenarios.

And it's perfectly sane to host .NET Remoting web services way apart from IIS in a command line application. In this case the overhead (in LOCs) might still be a little higher than when using GLUE but you don't at all depend on using IIS.

Simon welcomed me to the world of weblogs today:  "[...] spotted Ingo Rammer's weblog today [...] This guy seems to know an insane amount about the remoting architecture in .NET, his book is definitely on my to buy list."

Thanks for these nice words!

[What Simon doesn't yet know is that I'm actually using his tcpTrace tcp proxy for some of the screenshots in my book ... ;-)]

about food ...

I also somehow got to read about Vegemite (which is one of the best example for an absolute "love-it-or-hate-it"-food). I happend to work with an Aussie in a former project and he let me sample it. Somehow this is definitively a "once in a lifetime experience" ... at least for me ;-)

Regarding Vegemite, let me also point you towards one of the funniest authors around: Terry Pratchett. In his brilliant [1]  The Last Continent: A Discworld Novel he shows you how Vegemite really has been invented ;-) 

[1] as nearly all of his "Discworld series"

Today's not really about .NET ;-)

Finally I came across the answer why every second person I meet for the first time knows someone how knows someone who knows someone whom I know as well: according to a 1960s theory of Stanley Milgram [1] every American [2] is linked to every other by a chain of no more than six people.

Even though this theory has never been proven until now, it might very well explain why virus/worm hybrids like LoveLetter could spread in such a short time. The Ohio State University and the National Science Foundation are somehow working on applying this theory to the Internet as well.

Today I also came across Philip Greenspun's experiences with publishers. After reading this article and hearing several similar stories from other authors I'm more than glad for choosing Apress in the first place ;-)

[1] Yes, the same one who did the famous "Obedience Experiment"
[2] I guess this applies for others as well. Else it wouldn't be that interesting for me as I'm from Europe ;-)