As announced earlier, Katja and I will spend the next 5 weeks in the US. I'll speak at WIN-DEV and VS.NET Connections and will attend Chris Sells' Web Service Dev Con. During this time we'll stay around Boston from 10/1 to 10/18 and in Florida from 10/18 to 11/3. It would be great to meet some of you fellow .NET webloggers there - just send me an email if interested.

I just updated my consulting page (also available in German) - to get rid of the generic thingy and instead write what my work is really about - and put my availability information online.

[Clemens Vasters] I've been (and still am) busy preparing the downloads site for my new book ".NET Enterprise Services" (Hanser Verlag), which is going to hit shelves in Germany on Monday.

Clemens, despite our agreed upon disagreement on various .NETish and webservicish topics, let me just tell you that this is one of the few books I'm really looking forward to read (preordered for some time now)! Hey, who knows - maybe it's the book to make me change my mind on some of our points of discussion.

Looking forward to meeting you again at the DevCon!

[Matt Croydon::postneo] Sam Gentile and Brian Graf noticed that I'll be at the Web Services DevCon.  Ingo Rammer will also be there, along with a bunch of other webloggers who will be speaking and attending.  It's gonna be CRAZY!

[Sam Gentile's Radio Weblog] It sure is! Welcome to the Jungle! Ingo and I have referered to each other back and forth for months. Heck, he's even the one that intially got me on Radio. We even spent a night with my Rotor problems via Messenger. I feel like I know him like any of my best friends. Its going to be great to attach a face to his name. It will also be great to see the friends from last year and attach faces to a whole lot of other bloggers.

You bet! It's gonna be fun and I'm really looking forward to meeting y'all.

Anyone makes a sign to put up? "Weblogger's corner"? ;-)

I'm currently doing final preparations for my leave to the biggest .NET weblogger gathering. I'll arrive in Boston, MA on Oct 1st together with my fiancee, and we will stay in this area for three weeks (vacation, attending W/S DevCon, vacation, speaking at WIN-DEV, vacation) before continuing to Orlando, FL. If anyone feels like meeting us during this time, just drop me an email.

A reader just pointed out the he absolutely agrees with my rants about bad web applications.However, I published this rant on a page that uses a fixed layout and a fixed font size, thereby affecting usability as well.

He's right. Guilty as charged.

My problem is, that I'm a software developer, therefore I've been somehow more affected by development bugs than by design bugs. I simply didn't think too much about usability of web pages with fixed layouts and fixed fonts (which is especially bad in my case as in a former life, I've been surfing the web at 1600x1200 with fonts set to "very small").

Thanks for pointing this out to me. It should be better now. That is, if I didn't screw it up altogether ;-) 

Warning. 100% pure rant.

I hate Internet applications. Actually I don't, but I hate applications which had been developed by people who don't care about usability at all. I have some examples:

* My online banking system. This is the trigger for today's post: I just entered a number of transactions which I wanted to batch-confirm as soon as I'm done with all of them. Suddenly the server stopped to react. Logging on two minutes later -> all data is gone. Why the heck don't they store their session-date in persistent memory and store a persistant cookie at my hard disk?

* Austria's largest real estate service: After finding an interesting object, you can send emails containing the relevant information. It does however not remember the following properties: sender's first name, sender's last name, sender's email address, recipient's first name, recipient's last name, recipient's email address. Why don't they even assign a temporary cookie here but instead force me to re-enter all this information for every note-to-self I want to send? Even more important, why don't they create a direct link to their objects? Instead, when reading the email you have to go to their homepage -> Search -> Advanced Search -> Houses (rent) to enter the object's ID contained in the email. Argh.

* Austria's railroad operator. You can buy and print your tickets online (which is fine). However, if you klick back once too often, they will internally create and bill two tickets. This happend to a co-worker of mine - the customer support department refused to refund the money. Why the heck don't they use a hidden form field and simply detect re-submit? Did they ever hear the word idempotency and know what it means? Also, you have to re-enter your payment and address information again and again. Why don't they assign a permanent cookie?

* A certain US Robotics ADSL router. Contrary to most other devices, this router only comes with an "embedded" web application to configure it. No means of telnetting to it. When something doesn't work, you can view a log which shows brilliant information along the lines of: "Dialing started .... Could not connect". Thanks very much. Why don't they at least include an advanced log which really shows what's going on? Note to USR: I returned your device because of this. I'm now running a unixish operating system for connection sharing again - I can now get as much log output as I want.

Finally (aka. "why did I post this rant?"): If you're developer of applications which are used inside a browser, please, please, please care for usability. Save my settings, don't make me re-enter anything. Also please, care about idempotency of web requests. If you're QA tester of one of these applications, please don't let them release it as long as these things aren't considered. Your customers will love you.

Thank you very much for your support. I'm looking forward to using your application!

Dan [1] wonder's why I show "lack of interest in Intentional Programming and [...] praise of System.CodeDom? :-)"

Good point. I definitely thought about it when writing my original post. CodeDom is in my opinion far from the visual, intentional way in which I'd like to think about IP. It's basically a very low-level interface to programming language constructs. But on the other hand - whoever provide IP tools based on .NET should better look into this namespace when providing additional layers of abstraction. At least you don't have to think about the programming language anymore ...

[1] I didn't even recognize that he's running a blog-like web site. Welcome!

Peter's back

[Learning C# and transitioning to .NET] The programming world is primed for a major shift in paradigm (it's been a decade since the OO shift); I suspected that it would be aspect-orientation, but IP [Intentional Programming] is even more potentially dramatic.

In my opinion, aspect orientation will be the next really big thing. IP isn't remotely interesting for me ... I definitely code quicker, with less bugs, etc. the way I do now. It's been about 10 to 11 years now that I touched a BASIC interpreter for the first time - I really can't think about working in an IP visual way. However, I guess the transation from casual user to power user to IP programmer is easier than learning a programming language for casual use. It could therefore be ok for macro-like stuff ... or especially for business logic programming. However, I wouldn't want to develop my next Remoting transport channel in a visual way ;-)

Back home.

Last week's favorite namespace: System.CodeDom

I'll be away until September 15 - consulting gig abroad.

Have fun & don't yet kill Binary XML ;-)

Brad's joining our discussion on Binary XML.

His biggest issues and my proposition (my replies in blue):

- Need some negotiation of sorts to determine who supports binary and doesn't

Content type application/binaryxml. The rest is negotiated out of band (i.e. if a certain host only supports text/xml or also supports application/binaryxml)

- Difficult to grok when problems arise and debugging is required

Absolutely. That's why you can switch back to normal parsers which do text/xml. The only thing you have to trust is the parser. But the same has been true for years of CORBA, DCE/RPC, DCOM, RMI, Remoting ...

- Need to eliminate platform differences (endian-ness, etc.)

Others have done this before - why not just start with any of these? NDR is simple and should be ok ;-)

- Have to be VERY careful not to get a fragile binary representation

True. This is going to be the hardest part. It should also for example support streaming, etc. and not only be optimized for a small message size. This should be possible for input and output, which means that not all elements, attributes and namespaces occuring throughout the message are known right from the start. The protocol must provide the possiblity to "inject" new entries in the element-name table right in the middle of a documents. Things like these absolutely must be considered.

- Are all SOAP parsers using DOM and/or SAX, or otherwise shielding themselves from the on-wire representation?

True, that's a major point. Binary XML will only work for high-level applications which are based on DOM, SAX, or XmlReader & friends. But anyway, there's still XML 1.0 available for all implementations ... this isn't a lock-in or lock-out of anyone. You don't speak Binary XML? Fine, I'll give you XML 1.0.

I took Developmentor's Essential XML course (Aaron Skonnard is very knowledgeable and a great teacher). However, I cringed when I heard him say that the existing textual on-disk representation is an implementation detail. 

Exactly my point. Fortunately it is.

Like it or not, the on-disk format for XML isn't just an implementation detail, it's a way of life right now.

That's basically the same as using SOAP for RPC is the way of life in most architectures today. This is also going to change ...

If the data sees light for a day or more, then it needs to be in text form, for the reasons Clemens sites: binary data formats have short half-lives compared to text formats.

Absolutely. My idea of Binary XML is not for persistent data. It's just for transient inter process messages and RPC. The core question for me is: Why do I have support infinitive time to live for transient messages which are only for a very short amount of time semantically and contextually correct. We're talking about fractions of seconds, seconds or maybe minutes or hours here. Most architectures and implementations won't change that often.

Clemens Vasters and I started a discussion on ADVANCED-DOTNET regarding binary serialization of the XML Infoset during the last week.

Ingo Rammer: we'd need the W3C to come out with a standardized format for binary serialization of the XML infoset as I don't really believe in angle brackets for .NET to .NET communication. Performance still matters.

Clemens: I am strictly against any binary serialization format for XML. Consider this: Hammer an XML document into a block of marble and bury that block of marble in your backyard. With some luck, someone will find that block in 2000 years. They'll be able to figure out your XML document. This wouldn't be true for anything binary. The longevity of binary formats is about 10 years, text works for some 4000 years now.

Ingo: Good point. When using XML as a persistent data format: agreed. But especially for SOAP (be it RPC or message oriented), where a single message has quite a short lifespan, binary serialization would improve performance both in terms of network load and in terms of parsing time. Also I guess the number of times where you would need to get access the exact representation of an RPC call you did some hundred years ago is quite limited. In fact, even if you would be able to read it, you maybe won't have access to its exact semantics or the state of the system at this time.

Clemens: You are leaving out one very important aspect here, Ingo. We need to integrate not only laterally across systems, but also across the time axis. When I write a system today and deploy it, it will have to be integrated into other systems from that point on. The best system will eventually have to be replaced in, say, 7-10 years, max. There is no guarantee any vendor can honestly give you that anything they do in a binary format will be supported in that time frame. Binary formats have severe drawbacks. They depend on byte-orders, data type representations, bitness, etc. It may be okay for today to say that everything ought to be binary for speed, but the fact of the matter is that you are paying for this with integration problems in the future -- as we're seeing at present and which is the primary motivation for people flocking towards text based data representations.

The least that we need is a text-based (XML) manifest that references binary data for any transmission where binary formats make sense: multimedia streams, for instance. So, WS-Attachments (I guess that's the most recent name) makes a whole lot of sense here, but I don't think that a fully binary format does make a lot of sense. In the end, we'd be going back to having a common network data representation format along the lines of DCE RPC and/or CORBA IIOP, which will, in the end, require a huge set of infrastructure to make it work. Interoperability across systems with binary data has failed.

I do agree with you, however, for vertical integration on the same technology stack. For interconnecting backend servers, binary data is the best choice. However, for these high-speed connections, the entire idea of SOAP may not be a good one. Systems with a need for very high speed connectivity and deep integration are typically one system distributed over multiple machines. I think that wiring up components of the same system via DCOM, IIOP or .NET Remoting is and remains a valid choice.

 .... to be continued ...

Just let me explain my basic idea behind this whole stuff: XML 1.0, namespaces and the resulting XML Infoset are kind of well defined and most other specifications (Schema, SOAP, WSDL, foo, bar, foobar...) somehow aren't based on the angle brackets but instead on the infoset's more generic "information items". Therefore, it should be easy to just change the parser/serializer without changing any implementation of these additional specs. This consistency will be even more important when we begin life in GXA times. What I'm proposing therefore is a standardized binary serialization format of the XML Infoset. When designed correctly, this could give us a few very nice advantages:

First, reuse of innovation. WSDL, SOAP and all WS-* specs will be usable either via XML 1.0 + namespaces or via XML Binary. We could basically elimininate the need for proprietory serialization and wire formats if we want to.

Second, as it's a standard, you're in the same way vendor independent as you are now with XML 1.0. If your target system doesn't support XML Binary, fine. Just use plain old XML 1.0 to communicate with it. If Binary XML doesn't become a widely adopted success: fine, just change your parser and you're back online with XML 1.0. If the chosen binary format is outdated in 7-10 years because time showed that genetically engineered carrier pigeons provide best bandwidth but can only carry text data, fine. Just switch back to XML 1.0. So what I'm proposing is not a successor to XML but instead just a different serialization format which reuses every high-level specification in the GXA domain. Just think of text/xml versus application/binaryxml. Your server will only change the parsing layer based on this media type, the rest will stay the same.

Third, it allows for change. Regarding your point of application integration: Whenever you develop a new application, you nowadays basically have the choice between using the development platform's native protocol (DCOM, IIOP, RMI, Remoting) or to think in terms of GXA right from the start. The first one gives you at least one critical advantage: performance. The latter allows you to switch your business logic implementation from one platform to another or to integrate with new platforms unknown of today. So, the question is: what to choose? Or more important: why do I have to choose? Why can't I use the same development model, go for a binary format and get the best performance and infrastructure support of GXA and interoperability when using XML 1.0 serialization? In fact, Remoting allows something similary (although, I'd generally not recommend it for anything but .NET to .NET communication), but wouldn't it be great if it would use a standard format so that I can finally ditch the angle brackets when communicating with my Java backend?

Finally, let me respond directly to one of your points: "Interoperability across systems with binary data has failed.". True. But didn't all interop across systems fail until XML has been developed? I have a theory here as well: XML was the first thing that could be sold to non-technical decision makers (which most of the time are the ones with the final decision making power) because they could understand it. But why the heck was this important? I guess they could draw the conclusion that if even they could understand it, every developer they hire will also be able to grok the concepts. Take this together with its simplicity which allows the company to avoid some sort of vendor lock-in because in the worst case, they could simply develop their own parser. I guess that's why architects, developers, and even CTOs and CEOs responded to the web service hype in the way they did.

And they weren't too wrong here. Even a person who never saw XML before could quite likely interpret the following simplified message and also write a parser for it in less than twenty minutes:

<method name="CreateCustomer">
   <customer>
      <firstname>Clemens</firstname>
      <lastname>Vasters</lastname>
      ...
   </customer>
</method>

This ease of understanding will still prevail with my proposed architecture in which every message can either be expressed in XML 1.0 + namespaces if needed or in XML Binary if supported by both ends of the communication chain. A SOAP router could even translate the message from one format into the other just by using a different parser and serializer. But the real point is that GXA provides a lot of support which could also be useful in classic RPC style communication. We should just be able to use it with a binary serialization format as well.

I just uploaded two new remoting FAQs to dotnetremoting.cc: How to use Interface-based remote objects with config files and How can I get a MarshalByRefObject's remote URL?

Additionally, I finally managed to put a short consulting profile online. To get a overview of my services, please check out the   English language version or the  German one.

Currently working on the redesign of my weblog so that it finally fits the new dotnetremoting.cc.

Today's the day to celebrate a quarter century of Tomas Restrepo. Happy Birthday!

Sam just found these two articles which confirm my performance results and more or less promote the same point of view I have regarding ASP.NET vs .NET Remoting. They are a good read.

[Sam Gentile] MSDN has two exciting new articles on an area that is of confusion to many (myself included): when do you use .NET Remoting and when do use ASP.NET Web Services. Its interesting how they are listed with order reversed in other case. The first is ASP.NET Web Services or .NET Remoting: How to Choose and the other is Performance Comparison: .NET Remoting vs. ASP.NET Web Services.

Fresh chapters of O'Reilly's SSCLI book are online at http://www.oreilly.com/catalog/sscliess/chapter/index.html.

[David Stutz] For those who are interested, the good folk at O'Reilly have posted two new "beta" draft chapters of our "Shared Source CLI Essentials" book. They are Chapter 1, which covers overall rationale for the CLI component model, and Chapter 4, which covers how assemblies are loaded in Rotor. We hope that these will help folks understand more about Rotor.

Great news: Generics support (codenamed "Gyro") is available for Rotor: http://research.microsoft.com/projects/clrgen/

Miguel just talked with me about the X11 license we used for our open source projects. I was wrong: This license is in fact compatible with the GPL.

This is great news because I'm actually an objector to the GPL as it's too restrictive and I therefore wouldn't want to release source code under this license. However, I really prefer that my sources can be used by the widest possible audience.

From time to time I start to wonder again why nobody is working on a standardized Binary serialization format for the XML infoset. Preferrably one which is tuned for performance in serialization/deserialization and not only in regard to message size. Angle brackets are nice but - believe it or not - just too darn slow. And no, Moore's law doesn't count here: In my opinion there's no point in saying that computing power and bandwidht will double every 18 months so we don't need to work on performance. If it's possible to decrease processing time, one should do so.

I have GPRS networks, Pocket PCs and low bandwidth links. I also have applications where thousands of clients are concurrently accessing my server. Sure, I could - and actually have to do right now - throw more hardware at the problem. But why? Is really nobody working on this? Oh, and I also don't think that I'm the only one left wondering ...

It would seem so obvious. Some time ago, XML's maturing process started with namespaces and schema. Now most additional specifications should actually be based only on the Infoset. Don't you think it's about time to let XML grow out of adolescence and get rid of these angle brackets as well?

I'm absolutely interested in your comments and ideas on this. Especially in case anybody knows if work like this has already been started somewhere in secrecy ;). (And no, I'm not talking about the BinaryFormatter here. I'm talking about standards and interop as well.)

Another URL I just received from Richard Caetano which contains a more or less complete list of current demos: http://www.monostep.org. Wow ... I really didn't know that the demo scene is still alive and kickin'.

Christian Weyer just sent me an interesting link to a public domain tool which provides a "Remote Desktop with .NET Remoting". Cool idea! I'd really like to place a link to it but "You may link to this web site from your web site provided you link to the "home page". In other words, you may link to www.<REMOVED>.com. You may NOT link to content inside of www.<REMOVED>.com". I don't want to link to the home page, sorry. When will people finally learn how the web works? I've been online since 1994, but some things still make me wonder.

Ok, here's my link policy: Please don't hesitate to link to everything on this site, directly or indirectly; be it home page, articles, or downloads. You can of course link from a web site, email, newsgroup posts, print magazine, book, or whatever medium you like. If you have some great (open source or at least free) Remoting-related content online, I will happily link back to you. I will however NOT link to any site with a link policy which doesn't allow me to send visitors to the exact page I want to. Sorry folks.

Today I've met one of the most interesting programmers ever. Actually, I'm also currently thinking about resigning from my status as a software developer - I've met a real programmer today, and I'm far, far from it.

To understand what I'm talking about, please go to http://www.theproduct.de/ and download the two graphics demos. Run them (on some fast hardware, with 3D accelerator card and 256 megs of RAM or such). After looking at both demos for the complete duration of about 10 to 15 minutes each, right click on the .EXE file and check the file size. Now repeat my words: "This is unbelievable ..."

I guess I'm no longer calling myself a programmer now that I know what Real Programmers are up to.

Ok everyone, the BidirectionalTcpChannel's success got me into some problems ;)

This channel is an early preview. It contains highly un-optimized and un-scalable code to just prove my concept of a bidirectional channel. I released it early to see if people are interested in a channel like this and to see if others will join me in adding features. Both is definitely true. Josh Prismon is currently working on turning my horrible socket code into something scaleable and I will also change the header serialization format to further increase its performance. Please check back in a week or two to download a more usable and scaleable version of this channel. Summary: Yes, you can download and develop with this channel now. No, you won't be happy if you deploy it now.

Josh Prismon is currently working on improving the BidirectionalTcpChannel. He's about to implement async callbacks for tcp connections, backoff algorithms for reconnection, DNS resolving, and general cure for the threading problems. Wow ... this guy rocks!