As some of you probably noticed, the number of my weblog & newsgroup posts decreased whereas the average time to answer my emails increased during the last weeks.

There's been a very good reason for this. More infos tomorrow. Stay tuned! You'll love it!

Upcoming Microsoft webcast on .NET Remoting:

How to Develop Distributed Applications using NET Remoting
http://microsoft.com/usa/webcasts/upcoming/858.asp
June 4, 2002 - 11:00am to 12:30pm Pacific Time
Sean Campbell, Microsoft Partner, 3 Leaf Solutions

Sam Ruby was just elected to the Apache Board of Directors. Congrats!

Robert Scoble posted some great thoughts on Conference Speakers and Weblogging. I fully agree with his points re live IRC-chats and live speaker-rating during the talks. I guess I too would turn these off during my talks - not just because it could make me nervous but because it would distract me from delivering my content. Just image a speaker who stops during the talk to read IRC message - I guess this really wouldn't be that great for the audience.

But I'd really love to see the "arrange a BOF" and "arrange a meal"-application.

I guess I have to announce such a thing when doing my talks in Florida in October. I'd also love to do it for the talks in June but unfortunately the schedule is quite constrained as I have to board the plane nearly right after my talks to fly to the next city.

Some updates on my speaking schedule: I'll do a little tour for Microsoft Research at the beginning of June. We will provide four full-day .NET Crash Courses at four Universities in Europe (Free entrance, registration required):

• Technical University of Vienna, Austria @ June 3. [registration]
• University of Graz, Austria @ June 4. [registration]
• University of Frankfurt, Germany @ June 5 [registration]
• University of Milan, Italy @ June 6 [don't have the link yet]

Sam Ruby found A short parable on XML [via Ugo Cei].  An entertaining and insightful view on many of the issues driving people to document literal as a common base.  And in the process, partially answers Ingo's question on messaging vs distributed objects.

You're right, that's a nice read! I guess we all tend to see new things by comparing them to what we already know ...

To further clarify my original intentions: I like to play devil's advocate from time to time (just ask Miguel about it ;)) and this was also what I did here. Why did I do it? Because I believe that the current ideas about using doc/literal are far from enough and because I had the impression that most people only used this term because it's en vogue right now. After posting my original question, I even received the response that the difference between distributed objects and messaging is to be found in the WSDL.

I nevertheless think that just using doc/literal formatting instead of rpc style encoding doesn't change too much. This was what i was alluding to when I talked about those two things being equal.

Instead, one would have to think differently. It's not about objects, it's not about endpoints, it's definitely not about WSDL anymore. All those things are just intermediaries when going to really scaleable and extensible message passing. You'd have to think publish-and-subscribe eventing, workflow, transformation, routing, semantically compensating transactions, security, and so on.

Only after we addressed all these points, we can really talk about living in a message based world - before, it will only be RPC - no matter if it's encoded doc/literal or not.

[via g. blog radio] Thinking In C# :  a free online book for C# programming by Bruce Eckel. 

Yes. You read that right. It's a free book on C#.  Bruce started doing it when he wrote Thinking in Java about 4 years ago. The electronic version is free and the dead tree version is available in your nearest online bookstore. It doesn't seem to hurt the sales of his book much.

He's the author of the excellent Thinking in Java and Thinking in C++. It's really worth checking out. I've read some part of it and no, it's not an extension the language reference materials. Good quality stuff.

Full Ack! I also highly recommend his (free as well) "Thinking in Patterns".

Following his general discussion of formatters in the .NET Framework, Tomas posted an excellent article on the design principles behind "Formatters and Remoting". We talked about this for some time and the resulting article is a definite must read for anyone interested in the issues of message formatting in the remoting framework.

A reader of my blog just pointed me towards the following post about REST vs. SOAP by Paul Prescod: http://groups.yahoo.com/group/rest-discuss/message/1301. I think you can already guess my opinion on this topic - but anyway, the article explains the ideas behind REST in an excellent way. No matter if you agree with it, it's worth the read. Thanks Dilip for pointing me to it!

Nevertheless, I think judging SOAP as a bad thing because it doesn't fit a seven layer network model is an interesting way of proving one's point ;-)

Anyone still remembers the pearl of wisdom that a development tool which advertises to "reduces your project costs by 50%" can be nothing but a silver bullet - simply because of the fact that the act of software development only accounts for a small percentage when compared with the total costs for a project? Let's say development accounts for 30% of the project's costs, even if the tool slashes this by 50%, the whole project only saves around 15%.

Today, CNET.COM published an interview with Tom Siebel, the CEO of Siebel Systems. The funny thing is, he doesn't announce a 50% cost savings, he actually goes for a 99% savings: "It lowers the cost of application integration by probably a factor of 100. We've built a very elegant architecture that reduces the effort involved in application integration by an order of magnitude."

Isn't this brilliant? ;-)

Let's say you calculated the cost for application integration at around 2.000 person days. Using Siebel instead of your current CRM package will slash this down to 20 person days.

Hmmm ... I remember a project where we've been doing integration workshops taking several days with around 5 to 10 people in the meetings. I guess following the Siebel approach, we must have been finished before even writing the first specification as we already spent around 20 person days in the first three days of meetings.

Heck, this is great! We really should have used Siebel. ;-)

[via Scripting News, from Slashdot] Alan Cox [Mr. Linux Kernel] said in an interview: "The more dangerous parts of all this are not so much .NET but chunks of the model that not only the .NET product and the Java standards rely on. Things like XML-RPC, SOAP and the stuff on top of them are designed to 'interwork through firewalls'. A better phrase would be 'go through the firewall like a knife through butter in a way that prevents the companies involved monitoring the activity.'"

Interesting point. As far as I know, HTTP is the thing that traverses the firewall. SOAP is only the payload.

Let's simply imagine the following: how about a piece of software that tunnels data, for example IP packets, via HTTP (no SOAP involved, really ;-)). This way, someone from inside the company could easily access all services of the outside world by opening a connection to his home PC which in turn dispatches the IP-packets to the Internet. What do you think? Such products already exist? On gnu.org? And still, a GNU evangelist complains about SOAP ... ;-)

"httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests. The HTTP requests can be sent via an HTTP proxy if so desired.

This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall. "

Hmmm ... now imagine putting an SSH tunnel on top of the httptunnel and running this beast from inside the firewall on a machine which has NAT/routing facilities. This way, one of your employees can open an IP-tunnel to the outside world and later access any internal network resource from his home PC. Via outgoing HTTP packages, sent from inside your network!

Sounds like it would 'go through the firewall like a knife through butter in a way that prevents the companies involved monitoring the activity.'. In fact, if I were the person responsible for a company's IT security, this would scare me a lot more than any SOAP or XML-RPC.

[via Sam Gentile, via The Wagner Blog] Here is an update reg. MONO : We are able to retrieve simple data from the database using our ADO.NET like functionality. Only string and integer data types are supported right now but more are in the works. You can find more information at The Mono ADO-NET Page.

Sam: I didn't think they were going to achieve anything outside the CLI, FCL and CTS. If they get DataSets, this will be huge. Good job guys!

Full ack!

I also didn't believe that they'd head for more than CLI, FCL & such until I talked with Miguel for some hours some weeks ago. They really aim for the big picture including System.Windows.Forms compatible bindings and such. That's really going to be interesting ...

Devx.Com just put my review of Intrinsyc's Ja.NET online at http://www.devx.com/dotnet/articles/ir051402/ir051402-1.asp.

Intrinsyc's Ja.NET—Extending the Reach of .NET Remoting

Java/.NET Communication just got easier. Intrinsyc's Ja.NET tool lets you make remote bi-directional calls between Java and .NET applications, either through HTTP/SOAP or the faster TCP/binary channel. Even in this initial version, you can pass objects both by reference and by value. It's a great start, and with a little work, the next version will be killer.

I'll unblog until Sunday, 12th. No more news to expect until after the weekend as I will spend the time away from my machine ;-)

Peter Drayton found a very interesting paper:

On my explorations I ran across an interesting paper done at USC entitled "A Comparison of Alternative Encoding Mechanisms for Web Services". [...]  done using .NET Remoting! I'm looking forward to them releasing the bits, so I can try out the XMill formatter. If it doesn't happen soon, however, it would be almost no trouble to whip one up myself. Hmmm... Something to do during my South African vacation in 2 weeks...

I'm finally about to summarize the opinions on message passing versus distributed objects. This is somewhat delayed partly due to UserLand's crash, my DNS-problems, and partly also due to the wonderful weather during the last days. I hope you understand ...

The $ 1,000,000 question was: Where would you draw the line between a distributed object system and message based one?

Whenever I'm working on some posts which cry for a response, I already hope for some possible reactions while writing. This time Justin Rudd stated what I was thinking about: In closing - remember in the good ol' days of OOP programming (as told by one of my professors), no one called it "calling a method".  They called it "sending a message". 

He also said that in his applications he receives packets (messages) from a GPRS network, shoves them through queues until they may finally reach a distributed object system which processes the message. Ok, you're absolutely right here - the GPRS system definitely doesn't know anything about your objects so I guess you can clearly identify the border line in this application.

Sam touches this issue on a very different level:

Perhaps a concrete example would help.  In a distributed objects/RPC world, one would code counter.update(0101679).  In a message passing world, there would be a message that indicated the event that took place (user 0101679 updated his weblog) with no pre-conceived notion as to whether this is relevent or what actions the receiver (or receivers) may take based on this information.

The former is code.  The latter?  Well, It's just data.

That's a great example. When looking at it like this, it might actually make very much sense.

But on the other hand, the first example (counter.update(0101697) will eventually also emit a message which looks exactly the same as the one from the second example. Just think about our SMTP/POP3 channel for .NET Remoting. One could even use generic mailinglist management software to implement publish/subscribe semantics for these messages or use some rule-based toolkit to route messages to the correct receipients based on header or content.

When doing this, the implementation of an application will look exactly the same as when using a synchronous RPC protocol like the TCPChannel. From a developer's point of view, one is still working with a distributed object system.

Guido also isn't very fond of RPCs:

SOAP RPC may not be the most scalable approach in the world. But what it does a good job at IMHO is providing a migration path technologically and for developers' minds.

I don't really agree with RPC being only a migration path but I'm fully with you that it's for developer's minds. This is basically the same what I said above: no matter if you use async messages or sync RPC, for the developer it might look like the same thing. Anyone still remembers queued components with COM+?

The real problem I see with a pure message based system like the one proposed by Sam is about reliability. To clarify this point, let me first define how I'd see a pure message based system: each sender will post notifications to a general queue without specifying the final receipient. Some queue management software maintains publish- and subscribe semantics so that other systems can decide to listen on and process specific kinds of notifications.

This of course raises some follow-up questions to all proponents of pure message based systems: How would you determine the success or failure of a complete transaction? How would you implement support for clean rollbacks given the fact that the receivers don't have to be available at all times? Would your solution be feasibly for a general business environment where transactions should normally be guaranteed? And finally ... why would this be more scalable than RPC-style approaches?

Thanks again for your comments.

Disclaimer: Right before Userland's crash, I've seen answers from others as well but couldn't find them again. Be sure that I'll reply to your points as soon as you turn up in my referrer logs again!

It seems that most weblogs - at least the ones I'm reading - managed to recover from the recent problems at UserLand. This somehow gives me the chance, to finally summarize the thoughts on distributed objects versus message passing. More to come in some minutes ...

Update: My DNS problems should be solved in a few days as a friend of mine emailed me and offered to host the nameserver records for this domain. Thanks!

Sorry guys, dotnetremoting.cc was unreachable for the last 8 hours or so due to a failure of the leased line to our offices where I host the DNS. As this has happend for the third time now, I guess I'll finally move the DNS out of our offices and into the matrix ... will look into DNS-hosting providers during the weekend.

Rickard Öberg [via Sam Ruby who got it via Guido Casper]: "The first rule of distributed objects is ... drumroll ... don't use distributed objects".

Hi, my name's Ingo. I still believe in distributed objects.

By the way, for everyone who hasn't heard about Rickard before, he's actually the author of a book on RMI - which is somewhat in the same way about distributed objects as .NET Remoting is. [his original post can be found here]

It seems that nowadays everyone agrees on message passing == good & distributed objects == bad ... but where do you draw the line? In Remoting, distributed objects just means that something like a class factory which is accessed using a standard URL and maybe even SOAP as a protocol returns a dynamic endpoint's URL which identifies a single instance of the desired class. When accessing methods of this object, you just send messages to this dynamic endpoint.

So, where would you draw the line between a distributed object system and message based one? ;-)