Ingo Rammer's Weblog

Richard's having a blast on

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

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

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.

Aspect Oriented

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

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 ... ;-)

Web Services-Based Business Processes and Callbacks

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.

SOAP is a first-tier technology!

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

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

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

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!] ;-)