Richard's having a blast on this project: [his] Remoting Cache project is coming along smoothly.

He also posted some code that shows how to use caching with .NET Remoting - you should really check this out! Wow! I guess I should finally update the "Modules"-pages ;-)

Charles Cook released version 0.5.0 of XML-RPC.NET which contains XML-RPC client and server formatter sinks. These enable the .NET remoting infrastructure to be used to implement both XML-RPC clients and servers.

Congrats! You've beaten us in time-to-market! ;-)

Ok, but we've been running with a different focus. We're currently in progress of extending the formatter to include the ability to marshal ISerializable and [Serializable] objects in addition to structs for a better compatibility with the general Remoting framework. Tomas is also about to change the serializer to implement IRemotingFormatter - maybe we can merge some code later on!

I guess John Lam has savely arrived back in the US after demonstrating CLAW: I was weaving a trace aspect into a Hello World program using a System.* pointcut. Please don't try this at home. This was done by a professional programmer on a private computer.

And by the way, for all regular readers of DotNetCentric: I stopped all my work on this JIT-interception technique. Even though I have to admit that it's been an interesting thing to do, I'm just no C++ [1] guy and I guess professional programmers can do these things way better than I can ;-). I'll focus on Remoting instead!

[1] Yes, I survived several years in this business without touching C++. Fate or Fortune.

I normally keep it with Peter and don't re-post any articles without comment, but this time Richard just did it. There's nothing to add:

What if...
you could take this piece of code:

public void Before( CallContext context )
{
  Console.WriteLine( "Method was called at: {0}", DateTime.Now );
}

and wrap it around a method within a piece of compiled code:

using System;
public class Application
{ 
  public static void Main()
  {
    /* ... do stuff ... */
  }
}

With a little assistance from this definition:

<weave>
  <aspect pointcut="Application.Main"
    adviceType="before"
    advice="MyAspect.Before" />
</weave>

Imagine the possibilities!

This is an approximate example of how one might use John Lam's aspect weaver, CLAW. Recently he demonstrated it at the AOSD 2002 Conference. He has a really neat approach to weaving aspects in .NET. Since .NET just-in-time compiles code, he was able to weave the aspect just prior to compilation of the target method.

To clarify my point of view on SOAP a little: I'm not saying that I wouldn't like to see WS-Routing allowing us to "reply" to messages. Instead I just wanted to answer Joel who thinks that SOAP needs support for callbacks before being usable.

Quite contrary, I guess it's pretty usable right now ... ;-)

While writing my thoughts about SOAP being a first-tier technology, I hoped that someone would catch up on it and think through my ERP example. People did this and responded to me by email: What if the customer wants to be notified as soon as the order is fulfilled? What if the manufacturer wants to notify the vendor or shipper that the order isn't ready to be picked up on the planned date? Isn't this something that calls for callbacks?

Maybe, but do we really need protocol-based callbacks for this? I guess not, but let me state my reasons for believing this:

The supply-chain management examples from above describe two new business cases: 

• Notify the customer that his order is about to be sent
• Notify vendor and shipper that this order is delayed from the originally planned date

The handling of these would really be possible with SOAP callbacks - that is, if there were a thing like this.

But what happens if or when your customer's VIPs call your staff from their mobile phone while travelling through the country? My co-CEO does this all the time: He spends a lot of time on the road and to do something reasonable with this time, he calls the various vendors to talk about some issues and maybe places some orders as well.

In this case, the vendor wouldn't get the callback-pointer to which they should send their SOAP messages when the orders are about to be fulfilled.

So, the point is: using callbacks to map business processes to a procotol will trash your supply chain as soon as you accept orders by out-of-band channels like a phone or email. Oh, this isn't a problem for you as you don't accept orders by phone anymore because all your customers already switched to placing them via Web Services? Thought so ...

So, I guess that Web Services will just be yet another means of triggering a business process but you will still have to support all your other channels like fax, phone or email.

So, let's look again at the "notify customers of order fulfillment"-business process. How can this one be designed? I guess it goes something like this: check our database for the chosen means of notification for this customer and do whatever is appropriate: send and email, send a fax, ...

Every time I talk about business processes I somehow start to sound like those three-letter-company consultants who don't care too much about the implementation, so I better go back to technology again:

You have this ERP application which allows your staff to enter an order and you now implemented an additional SOAP endpoint so that your customers can place orders automatically. In any case, you will want to send a confirmation back to your customer as soon as the orders is about to be shipped.

You will quite certainly also have a database which specifies how your customer wants to be contacted. This however is a second-tier decision which has nothing to do with either the GUI or the SOAP endpoint in the first tier. No matter how the order enters yours system, the way of contacting your customer should be the same. At the end of the day, this means that you will have the customer's email address, fax number, etc. in your database. As you also allow notification by SOAP web services, guess where the SOAP endpoint address for the customer should go ...

So, once again, do we really need protocol-supported callbacks to make Web Service based business processes a reality? I still guess not. Quite the other way round, they will probably make things worse.

Will we need callbacks for LAN-based applications? Yes, I guess so - but this isn't a problem because you will be using a real distributed application protocol like .NET Remoting, DCOM (and COM+), RMI (and EJBs) or CORBA for these parts of your apps.

Today, Joel posted some strong opinions about SOAP:

The real problem with SOAP is that it's a completely inadequate remoting system. It doesn't have events (which makes it useless for large classes of applications). It doesn't support references (ditto).

Well, I guess at least for .NET there's Remoting which takes care of this issues.

That said, I have to affirm you that I Like Web Services.

I just see the applications somewhat differently than some people want you to see them. For me, a SOAP service only provides an interface to some backend tiers, compareable somewhat to the GUI of a classic application. Let's say you write an ERP software: what services would you publish via SOAP endpoints? Your complete internal object model or parts similar like the ones which are accessible for your users by using the GUI?

I guess one should only publish services which have a somewhat closer resemblance to business processes (BP). That is, for example, Google published a SOAP API which allows you to access the same BP which you would normally access using your web browser (it's "fetch a list of pages which match my query"). Google definitely wouldn't allow you to access their internal object models or databases.

So, back to the ERP system. In this case, you'd probably publish interfaces that allows the automated entry of orders by identified customers. Again, that's something which would normally be done using your GUI - but this time with the instant benefit that your customers can now place the orders themselves.

When now thinking about Joel's comment again, I guess the question is: Are events necessary in Web Services?. I guess they aren't. Web Services are fine for cross-company computing and cross-platform computing (ever used a DCOM component from an application developed in Perl running on Linux?). For intra-company, LAN based computing with its rich GUIs and fixed sets of application development platforms, there are better ways.

The fine thing is that you can use whatever your platform offers: Running on .NET you have the feature-rich System.Runtime.Remoting and Enterprise Services, on Java there's RMI, EJB and such. If you're still on VB 6 or VC++, go for DCOM/COM+ and if you want cross-platform you could also choose CORBA. The best thing about it: You can still use SOAP endpoints to publish entry points for your business logic, no matter what distributed application platform you chose for implementing them inside your LAN.

To summarize my point: most of the time, a SOAP web service should be a first tier implementation - just like a GUI. An exception can be seen in the integration of programming languages which couldn't work together before. But that's a different story ...

Today, Richard posted the article Remoting Matters in which he states "that as the software we write today becomes more distributed the pieces that connects them will become increasingly more important."

He also says why .NET Remoting can help take some complexity out of this issue by providing an easily extensible framework. He should know; he's contributor to our projects.

The important thing for the pieces that connect them is that the business developers for example (which I guess write most of today's distributed applications) shouldn't have to know about the internals - they should just be able to use them.

Around the web, our projects still get mentioned:

Joe Gregorio: Peter Drayton, Simon Fell and Ingo Rammer have announced a remoting project which includes an SMTP channel. Cool.

Brad Wilson: Ingo, Peter and Simon have gotten together and made a site for Open Source .NET Remoting projects. Their first contributions include the well-received JabberChannel that they demoed at the Web Services DevCon.

Thanks everyone. By the way, Richard Caetano started to work on the caching channel sink and John Bristowe from the Melbourne .NET User Group is also going to join us. I'm also currently talking with two or three other people about contributing to the project ...

I guess I'll setup a mailing list. Simon, Peter: ok?

Sam Gentile: "It's the runtime stupid": I think C# is the VB of 2002 [...] We now have a whole lot of people, like the VB days, that have no idea what they're doing. [...] Forget about learning C#. Forget about learning VB.NET. Learn about the CLR and the BCL FIRST. [...] I honestly don't read C# books. [...]

Ack & dito! Not much commentary need, is it? [Hey, and by the way: I've been a VB hacker back then, and I very well knew what I was doing!] ;-)

[Teaser removed at 01:00 a.m.].

More to come in the next days!

Thanks to everyone who mentioned our efforts to show the world what can be achieved with .NET Remoting!

Sam Gentile: Way Excellent! Terrific Threesome create OS .NET Remoting Site

Sam Ruby: Ingo, Simon, and Peter announce .Net Remoting related Open Source projects.  First two are Jabber and SMTP support.  Bidirectional TCP, XML-RPC, MSN Messenger, Caching, and other ideas are planned.  Excellent license.

Dave Winer: Sounds like Peter Drayton, Simon Fell and Ingo Rammer are adding all kinds of rest-of-the-world friendly bits to Microsoft's .NET, which would be totally welcome news, of course.

The interesting thing is: these three people are coming from totally different backgrounds: Sam Gentile is a die-hard .NETter (or at least it seems so from the book he has written and the links he posts ;-)), Sam Ruby evangelizes (in the best sense of this word) SOAP and Dave Winer is the scripting and XML-RCP community's voice. Everyone seems to like our idea ...

Of course, others mentioned the project as well. But they had the unfair advantage of knowing upfront ;-)

Thanks also for the congrats and offers to contribute which I received by email!

Peter Drayton, Simon Fell and I are proud to announce a set of open source .NET Remoting projects. We have planned this for some time now and after Simon created the CVS repository last week, I finally got the time to create a web site about them.

http://www.dotnetremoting.cc/projects

We have currently implemented a JabberChannel which allows .NET Remoting messages to be transferred via the Jabber protocol and an SMTP/POP3-channel which uses standard internet email to transport the requests and responses. Both channels come with full source code, sample clients and servers and are covered by a very liberal open source license.

One of the reason for kicking this off right now is that we want to provide a collaborative environment for remoting-related developments. At the current time we are about to implement the following (parts of them will be available in the CVS in a week or two)

* An XML-RPC Formatter for .NET Remoting
* A bidirectional TCPChannel which avoids the problems with callbacks, events and sponsors which are used from clients behind NATs or firewalls.
* A caching channelsink (based on this idea)
* A framework for the development of feature complete custom channels
* An MSN Messenger channel

Further ideas which we think about are
* A document/literal encoding SOAP formatter
* A DIME/TCPChannel
* and finally, an implementation of the GXA-specs (WS-Routing, WS-Security)

This post is also a call for action!

If you already implemented channels or sinks or have some great ideas about doing so, please don't hesitate to contact me privately or - even better - post them to the project discussion forum. Also please check the licensing information before submitting any source code to this project as we definitely don't want to infringe of any existing copyrights.

Thanks for your support. I'd really like to hear your opinions on this. Please blog, email or post at them the forum!

Happy coding!

Today amazon.com raised the prize on my book back to the original list price of $49.99. I therefore just wanted to inform you that you can also get it at B&N for $39.96: here. [Not that it wouldn't be worth the $49.99 but you might as well save the ten bucks ;-)]

Please mind that the information on BN.com isn't 100% correct. For the up-to-date TOC please refer to this page.

You can also order it at BookPool for $32.95 although they don't have it in stock right now: here.

[and no, this was not yet the interesting thing I announced earlier ... ;-)]

I'm currently preparing something very interesting for you. Check back in about an hour or two for the release note ;-)

-Ingo

Tomas' copy of Advanced .NET Remoting has arrived yesterday. His first comment to me by email: "Love It! It absolutely rocks! (and yes, you can quote me on that one ;))"

Great to hear that you like it! Thanks.

Hello Austria!

Tomorrow I'll be at the local .NET User Group Vienna with a session about .NET Remoting and ASP.NET Web Services. If you're in Vienna, it would be nice to meet you there: http://www.globalknowledge.at/dotnetug/workshops.htm! [Oh, and yes, entry is free. Snacks and drinks will be available ;-)].

Peter Drayton managed to post the following at 5:21 AM: Google2RSS is a command-line tool that runs a query using the Google Web API and spits out an RSS 0.91 feed containing the top 10 hits.

If you for example want to subscribe to the top ten hits for .NET Remoting, you can do this using the following RSS: http://www.dotnetremoting.cc/DotNetCentric/google_remoting_rss.xml

Richard's new Brain teaser: Flower Logic. Done.

Peter's latest book, C# in a Nutshell, is available. Congrats!

I came across several unknown-to-me tech weblogs today: Developmentor Niels Berglund, Microsoft Consultant Chris Hollander (who has a fine collection of links to other tech blogs), C# fan Joe Gregorio and .NET Magazine columnist Steve Makofsky.

Richard Caetano: Solve the magic square. Done!

For everyone interested in Remoting who did not yet receive my book [1]: Christian Weyer just sent me this URL which I really have to share: http://www.gotdotnet.com/userfiles/toub/SecureRemoting.zip. It's a new example from Microsoft that contains a .NET Remoting channel which uses encryption and which can be employed without relying on IIS. [But mind that the current version only supports synchronous processing of messages; async is not yet supported ... but it wouldn't be to hard for you to add this as well ...]

[1] ;-)

For those of you who wondered why I haven't been posting lately: three words. Too Much Work.

I'm in dual-mode again: earning money with coordinating the architectural decisions for a somewhat big integration project [six or seven systems, two platforms, four standard software packages, five programming languages and thousands of planned person days of work] and having fun by working with the unmanaged .NET profiling API again [well, actually the big project is fun as well]

I'm currently about to rewrite the JIT-Interception stuff to be a lot more generic when emitting new IL codes. Right now i'm about to figure out how to reuse code from corhlpr.h & co to save me some work (in the first run I did it the hard way, decoding the IMAGE_COR_ILMETHOD on my own which is certainly _not_ recommended ...)

Sam found a nice sample: Creating and Using Custom SOAP Headers.
This quick demo shows you how to create and consume a .NET Web Service using a custom SOAP Header.

If you're new to .NET and currently trying to integrate it with another platform using custom SOAP headers, this sample might give you a quick start. I only wonder where Sam always finds those new articles ;-)

I already knew that my book will be available at TechEd but due to the time constraint, I didn't expect my copies to arrive earlier than in about a week or two. It's been quite a surprise for me to receive them today!

Tomas just told me that there is a tool called FSUTIL.EXE which can create short filenames for existing files on Windows XP. Sam, could you check if this works for you?

Sam's Rotor woes continue but we finally found the reason for his problems. Here's the thing everyone should check before playing around with Rotor .... else you might end up with some mysterious error messages.

[WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Neither Microsoft nor I can guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. ]

Start RegEdt32.Exe and go to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\FileSystem. Check the entry NtfsDisable8dot3NameCreation. It should be set to 0 [zero]. If it has been set to 1 while installing Visual Studio.NET, you may be out of luck with Rotor.

To make sure, you should open a command prompt, go to C:\Program Files (or wherever you installed VS.NET) and run "dir /x micro*". If a line like this is included in the output, everything should be ok:

20.01.2002  13:01  <DIR>  MICROS~1.NET  Microsoft Visual Studio.NET

If you don't see anything that looks like "MICROS~1.NET" next to "Microsoft Visual Studio.NET" you might have the problem.

In this case you should change NtfsDisable8dot3NameCreation to 0 [that is: zero], reboot, de-install Visual Studio.NET, manually delete \\Program Files\\Microsoft Visual Studio.NET (if it still exists; but backup anything interesting before doing so). Then you can re-install it and the necessary short name (DOS-style 8.3 file name) will be created for this directory.

I'm currently looking for a better solution to this problem: Does anyone know any tool that allows to create a short filename for a file or directory that already exists?

Today morning (from 1:00 a.m to 2:00 a.m CET) Microsoft hosted a .NET Remoting chat.

The development team answered questions from users and told us about the features which are planned for future releases. The official chat transcript isn't online yet, so I quote from what I remember:

• Microsoft will release a sample application which provides authenticated Remoting for objects hosted outside IIS. In my opinion, this has been the missing feature #1 and some others in the chat agreed with this. Tomas and I therefore will focus on a different area and not implement the SSPI channel. Mike Woodring (who's been working on such a channel independently from us) also announced to stop the development of his channel.
• Microsoft will look into improving the performance of the HTTPChannel when hosted in IIS.
• The context implementation might be changed. This means that ContextBoundObject and things like context properties, context attributes and the interfaces like IContributeObjectSink, which aren't yet documented might be different in the next version.

This is not an official statement, it's just what I remember from the chat.

By the way, has anyone saved a log of this chat? If yes, could you please send it to me by email (rammer@sycom.at)? Thanks a lot!

I'm on http://www.go-mono.net! Advanced .NET Remoting from Ingo Rammer is now available. Ingo helped us to implement the proxy support and the book is a valuable resource for anyone interested in remoting.

You're welcome and thanks for the link!

Simon: Congrat's to Ingo, his .NET Remoting book is released today!. Thanks!

By the way, I just checked with my publisher and the first copies will be available at TechEd as initially announced. 

Today at 3:00 to 4:00 pm PST (6:00 to 7:00 EST), Microsoft will host a .NET Remoting chat with the following people from the development team: Jonathan Hawkins, Peter de Jong, Manish Godse, Manish Prabhu:

The .NET Remoting development team addresses your questions about .NET Remoting, including how .NET Remoting can be used to create distributed applications with .NET and how it can be extended with pluggable channels, formatters and other powerful extensibility points. The chat will also cover security, configuration and versioning.

More information can be found at http://msdn.microsoft.com/chats/. Yes, I'll also be there ;-)

Sam just pointed to a very interesting article: The Implementation of Model Contraints in .NET.

The great thing is that it is actually possible to implement the scenario shown in this article by tapping into the unmanaged profiling and debugging API, using GetILFunctionBody() and SetILFunctionBody() to replace the IL body of the method right before JIT compilation. In fact, it's what I have been dreaming about and what John is about to implement right now.

The funny thing is that while talking with Dietmar today we agreed that implementing support for behavior like this in Mono would be great!

I just came back from a great evening with Dietmar from Ximian who has in the past implemented as trivial things as the JITter for mono. Right now he's about to implement Remoting and he really had some tough questions for me. Well, I guess we sorted them out - but it's really hard to do when you have to obide the laws of not showing any sourcecode to him.

He already got most of the TransparentProxy and StackBuilder parts ready in the runtime so that the rest will mostly be work in managed code. Anyone here who dares to implement a SoapFormatter who has not yet looked at the Rotor-sources or at the IL?

Use the (shared) source, Luke!
                --Yoda (kinda)

Peter Drayton put some cool code samples online which show how to extend the SSCLI [aka. Rotor] to implement new IL opcodes. [yes, I took the Yoda-quote from his slides ;)]

On April 16 at 5:30 pm, I'll speak at the .NET User Group Austria in Vienna about Remoting vs. ASP.NET Web Services. After introducing both technologies, I'll focus on issues like platform independence, performance, extensibility, and the question: "Why the heck are there two different SOAP stacks in .NET?".

I guess someone really liked the prerelease copy of my book which I handed to him some weeks ago: http://www.go-mono.com/books.html ;-)

Hmmm ... I just thought about implementing SSPI based security in a custom channel sink instead of a custom channel. This would allow us to reuse this authentication scheme with every channel (yes, and it would also reduce our development effort)

Tomas and I started working on the secured TCP channel. While he is writing a managed wrapper for SSPI (so that we can write the real Channel in C#), I'll be working on a cleanroom implementation of a TCP channel. This shouldn't take too long as I already implemented a Remoting channel from scratch before ;-).

This somehow triggered an idea for me. How about hosting all those custom Remoting projects (like Peter and Simon's Jabber Channel, my SMTP/POP3 Channel, some additional channel sinks, etc.) in a publicly accessible form like CVS or Subversion? Any takers? Anyone has the servers - or the knowledge ;) - to set this up? Peter & Simon: What's your opinion on this idea?

I just read that Tomas is about to start developing a secured TCP Remoting channel (using SSPI). Hey, if you plan to somehow open source it, I'm ready to join you (that is, if you want me to ;-)).