In my recent tour of the local university campuses giving talks and presentations, I noticed that most of the students find my talks hard to digest and understand. This is not surprising since I have always been known to be a server guy and not much of a tools person. Actually I used to be a client-tools person BUT have since spent the last year or so dabbling in distributed computing protocols.

This is not just associated with students, BUT some of the younger folks that I had a chance to engage as well. This goes really far to show how old I am. It is very hard to extol the benefits of XML/SOAP and Services if the younger folks dont understand and appreciate the history of COM, MTS. Pretty soon, when Indigo matures from the wild, technologies like COM+ and .NET Remoting will become legacy as well.

Everyone who grew up in the .NET era never knew about DLL Hell in deployment. Those things I need to do at 12 midnight when everyone is asleep and I am given the safe-clear command to do a regsvr32 for a 10KB Win32 COM DLL and then reboot the servers after...and I have not even mentioned about those nightmarish versioning problems when someone else's DLL is installed over mine....

Well, it is good for those folks just like it was good for me not to have gone through Yourdon's Structured Programming era. Now thinking about it made me realize that maybe I would have appreciated object-abstractions better if I had.

Anyways, since I was very focused on distributed computing protocos and XML SOAP Services in my talks and since the audience were mainly younger students who had no professional experience, I tend not to dabble too deep into BEST PRACTICES in Deployments, Versioning and Interoperability scenarios. I am sure most of them would rather poke a needle into their eye than to watch me write angle brackets, do some xsd typing, and then import namespaces before binding them all together in a WSDL file. Therefore, I usually give a more general broader overview of the industry, how come we have what we have today and what are we getting tomorrow. The history part usually sits well with them and so most of the questions that came up usually relates to that.

Since most of their curriculum and labworks never went back to technologies that were more than 2 years old, I do find it useful sometimes to show them how COM, MTS and DCOM was done last time. That usually catches their attention although I think it was more of an amusement to them more than anything else.

"Now, see this black thingy, we call them vinyl in our days and we put this needle-like shaped thing on it so that music can be piped out from this trumpet-like thingy...and we have to put it carefully on the edges so that it starts from the first tune...and if we want to repeat the same tune again, we have to sit up, go back to the machine, lift the needle up, squint our eyes on the vinyl so we can pick out the correct sequence of the groove on the vinyl that the song starts on and put it carkefully and slowly on that groove and VOILA, we have replay....What ? Oh, we have to do that everytime we want to replay that song...Whats that ? Shuffle, Random --- What's that ?"

So, running DCOMCNFG.EXE and OLEView is not something I would do too often just to get a chuckle from the student audience

However, I promise some of them I would blog about XML-RPC in relation to (W3C) SOAP and that is what I intend to do. There are still more than a few implementations out there in the real-world that are happily humming along with XML-RPC. I had done a couple of them before using MS SOAP Toolkit to XML-RPC with an apache server. I dont see them clamouring after SOAP so soon as those functionality are pretty straight-forward Request-Response endpoint invocations. In fact, the banner hanging in their server room reads: "NO SOAP, NO Problems" which I thought was quite cool even though I am a big fan of SOAP.

Anyways, how can a Web Service history lesson be complete without XML-RPC. Dave Winer, who came up with XML-RPC amongst other things is still one of the key guys today, in my mind, who has shaped the landscape of distributed computing today. There is no doubt that SOAP has its roots in XML-RPC. XML-RPC is sort of an early generation of Web Services and it went a long way to define one of the principles of Service-Orientation which is to create as little shared abstractions as possible. In fact, there are so few primitives and types in XML-RPC that there is so little to agree and disagree on which, in turn, sets a positive tone in integration and interoperability. Incidentally, that was one of the reasons why SOAP 1.1 Section 5 Encoding was taken out in SOAP 1.2.

I would try to see what I can come up with to write some XML-RPC scripts on .NET, just for the fun of it. I dont see any scenarios that I could use it unless one needs to write a .NET client to connect to a UNIX XML-RPC Server. Extensibility could be an issue as I could not route those messages, at least, not easily. On the other hand, because XML-RPC is slightly simpler (XML-RPC = SOAP++), it may pose less of an interop hazard.