Net DDE to DOT NET Remoting

 

 

Abstract

This article travel through time to trace the genesis of Dot Net Remotingright from RPC to RMI till SOAP.

Prior Art

Sun innovated the concept of RPC (Remote Procedure Call), this was furtherrefined by DEC (Digital Equipment Corp. of the VAX fame. Now it is a partof Compaq), and was called COM (Component Object Model). COM was an object-orientedadaptation of Sun RPC. For it?s OLE (Object Linking and Embedding) technology,Microsoft adopted COM as the base architecture.

Prior to OLE, Microsoft used a form of inter process communication calledDDE (an acronym for Dynamic Data Exchange).  With the introductionof WFW (Windows for Workgroup), Microsoft also introduced a remoting versionof DDE called ?Net DDE?. Soon thereafter, OLE was introduced with manyfanfares.

OLE was much shunned by the Windows programmers, as it was bulky, slowand difficult to code. Those were the C++ heydays. Microsoft and Borlandwere competing with each other for a GUI framework. Borland called itsframework called OWL (Object Windows Lib.), incidentally Anders Hejlsberg,the C# architect, used to work for Borland then! The Microsoft introducedMFC (Microsoft Foundation Classes), which ultimately became the de factoWindows API for Windows GUI programming. WFC, which was introduced in J++,was the avatar of MFC. WFC is also retained in C#.

As MFC stabilized, and ActiveX controls emerged, a consensus was buildamong the Microsoft teams, that OLE needed to be replaced by a lighteralternative. OLE was GUI intensive, with many layers applied over COM.These layers were stripped down to reveal COM API, and its remoting versionDCOM (Distributed COM) was introduced to the Windows programmers. However,all this time it was possible to use COM API through ?C? or C++ programming,but Microsoft never publicized this fact beyond the MSDN commune. MSDNwas not freely available on the Internet as it is now!

Lawsuit and Remoting

Java introduced RMI (Remote Method Invocation), though DCOM was a candidatefor remoting, it was discarded after a brief deliberation. To popularizeRMI Sun made it as a core API in it?s JDK 1.1, making it mandatory forall it?s licensees to implement it. Microsoft refused to comply, and Sundragged it to court. On an interim order, Microsoft started to distributean unsupported version of RMI, which was not part of the Microsoft?s JavaSDK standard package.

Till the introduction of .NET architecture, a Grand Canyon like divideexisted between the Java world and the Microsoft platform languages. CORBA(Common Object Request Broker Architecture) was an option for bridgingthe divide, but due to its heavy baggage, and lack of vendor interoperabilitycould not succeed. Java 2 (JDK 1.2 and above) has a full support for CORBA,including IIOP (Internet Inter Orb. Protocol) transport layer support,yet it failed to fire the passions of the Java lovers. I think, this maybe due to lack of syntactic sugar.

SOAP (Simple Object Access Protocol) is the default remoting protocol,used by .NET framework.

SOAP was accepted as politically correct remoting solution, since itwas based on XML and HTTP, both very popular and widely used, having supportof all modern languages. IBM implemented a Java SOAP server and donatedit to Apache, under the Apache open source license. This move bridged theJava and VB (Visual Basic) divide.

Genesis of RMI

Lets figure out how RMI evolved, to speculate where it might go tomorrow?

The famous paper inspired that inspired the RMI design was a Sun MicroLab. Internal report titled:  ?A Note on Distributed Computing? (Documentreference:SMLI TR-94-29). This paper was internally published in 1994. Ann Wollrathwas one of its authors.

The milestone paper argued that, remote objects? method calls shouldnot be transparent to the programmers.

Like C#, OAK (the Java predecessor) too had a transparent remoting mechanismbuilt into its virtual machine. This was wrenched out soon after beingrenamed as Java, since it fell into the local/remoting transparency trap.Ann Wollrath got the prestigious job of the Java remoting architect.

Rubbing the Lamp

Jini predates Java. It was first implemented using Modula 3, then OAK andfinally in Java.

Sun wished Jini to be the pervasive ?Plug and Work? distributed platform,to provide reliability over unreliable networks. But Jini proved much fatterto fit in a lamp.

Jini, like most cutting edge technologies, left its developers bleeding.I will exorcise Jini in the next section.

There is not genie inside the lamp, so stop rubbing it! Microsoft isoffering to exchange it for a new soapbox called Dot Net. I think it mightbe a good bargain.
 

Putting the Jini Back into the Bottle

Jini is an extremely well engineered distributed computing framework. However,it failed to be a commercial success, much like Oak (Java is the Oak?savatar), due to 4 main reasons.

First, the spin-doctors at Sun hyped Jini beyond proportion. They signedin one and all device manufacturers, without much real commitment fromthem except for a tangy quote by the CTO (Chief Technical Officer).

Second reason, for demise of Jini, was that for announcing service itused by default was UDP multicast. This is not Internet routable, causingJini effectiveness to be blocked across routing borders and confining itwithin LAN segments.

Third, Jini was touted as being lean and mean by its evangelists, inreality when we looked seriously into Jini, to implement a distributedinter-city radio Paging message routing system, spanning 10 cities, overa VPN, we found it rather bulky. We had to start more than six servicesfor it to begin working. This made us drop this idea like a hot brick,at the proof of concept level itself.

Finally, I think it had a branding problem. Unlike other Java products,it used a different logo. Not much promo budgets could be assigned forthe brand building exercise. A generic sounding name and an Aladdin?s lamplogo did not help the recall factor either. Many NON technical projectmanagers, probably associated Jini with the Walt Disney's cartoon striprather than a serious distributed computing environment.

I will share with you a real life situation about this branding issue.I personally presented a proposal for funding a proof of concept studyof a distributed application, to one of our important and friendly clients.The technology projects manager, specializing in radio paging networks,commented more or less as follows: "Ash, it seems that you have been watchingtoo much Cartoon Network lately, but we are discussing serious stuff here,so lets stick to Java". This made me conclude that some people, outsidethe Java commune, did not perceive Jini having any relationship with Java.This factor deprived Jini, the benefit of Java?s goodwill.

 However, after a three hour long arm twisting session

he fina
llygave in, but then, most of the time you can not bully your customers. Iam sure other software developers, trying to sell Jini, might have hitsimilar speed breakers.

The Sun marketing gurus are back to their renaming game. They seem tryingto put back Jini into a new bottle, aptly called, Jxta (pronounced as JUX-tah,probably shortened from Jini eXTrA or may be an acronym for Jini XML TransactionArchitecture) is the new avatar of Jini. And spin-doctors are out on thecircuit, hounding for a Grand Prix. I hope that the sprit of Jini willnot haunt Jxta.

What more can be Jxta, than the old genie in a new bottle? I will findit out once I open the bottle. But, for now I am playing it safe.

Tail Piece

Dot Net remoting architecture is truely revolutionary.

.Net has a layered architecture which provide the following servicesin each layers:

  • Application Layer: Activation and lifetime support. Two activationtypes are provided, namely client activated and server activated.
  • Messaging Layer: provides message formating, SOAP and two otherformatters are provided by default and you can add your own.
  • Transport Layer: Channels, provides transport layer services, fortransporting messages to and from Remote Objects.

With SOAP specification being put into public domain through W3C,Sun has now started the community process to evolve a standard API anda reference implementation of SOAP remoting. Visit http://jcp.org/jsr/detail/101.jspfor details.This should build the confidence of the programmer community on DotNet Architecture.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

No comments yet... Be the first to leave a reply!