Abstract
This article travel through time to trace the genesis of Dot Net Remoting right from RPC to RMI till SOAP.
Prior Art
Sun innovated the concept of RPC (Remote Procedure Call), this was further refined by DEC (Digital Equipment Corp. of the VAX fame. Now it is a part of Compaq), and was called COM (Component Object Model). COM was an object-oriented adaptation 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 called DDE (an acronym for Dynamic Data Exchange). With the introduction of WFW (Windows for Workgroup), Microsoft also introduced a remoting version of DDE called "Net DDE". Soon thereafter, OLE was introduced with many fanfares.
OLE was much shunned by the Windows programmers, as it was bulky, slow and difficult to code. Those were the C++ heydays. Microsoft and Borland were competing with each other for a GUI framework. Borland called its framework called OWL (Object Windows Lib.), incidentally Anders Hejlsberg, the C# architect, used to work for Borland then! The Microsoft introduced MFC (Microsoft Foundation Classes), which ultimately became the de facto Windows 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 build among the Microsoft teams, that OLE needed to be replaced by a lighter alternative. OLE was GUI intensive, with many layers applied over COM. These layers were stripped down to reveal COM API, and its remoting version DCOM (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. MSDN was not freely available on the Internet as it is now!
Lawsuit and Remoting
Java introduced RMI (Remote Method Invocation), though DCOM was a candidate for remoting, it was discarded after a brief deliberation. To popularize RMI Sun made it as a core API in it's JDK 1.1, making it mandatory for all it's licensees to implement it. Microsoft refused to comply, and Sun dragged it to court. On an interim order, Microsoft started to distribute an unsupported version of RMI, which was not part of the Microsoft's Java SDK standard package.
Till the introduction of .NET architecture, a Grand Canyon like divide existed between the Java world and the Microsoft platform languages. CORBA (Common Object Request Broker Architecture) was an option for bridging the divide, but due to its heavy baggage, and lack of vendor interoperability could 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 may be 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 it was based on XML and HTTP, both very popular and widely used, having support of all modern languages. IBM implemented a Java SOAP server and donated it to Apache, under the Apache open source license. This move bridged the Java 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 Micro Lab. Internal report titled: "A Note on Distributed Computing" (Document reference: SMLI TR-94-29). This paper was internally published in 1994. Ann Wollrath was one of its authors.
The milestone paper argued that, remote objects' method calls should not be transparent to the programmers.
Like C#, OAK (the Java predecessor) too had a transparent remoting mechanism built into its virtual machine. This was wrenched out soon after being renamed 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 and finally in Java.
Sun wished Jini to be the pervasive "Plug and Work" distributed platform, to provide reliability over unreliable networks. But Jini proved much fatter to 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 is offering to exchange it for a new soapbox called Dot Net. I think it might be 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's avatar), due to 4 main reasons.
First, the spin-doctors at Sun hyped Jini beyond proportion. They signed in one and all device manufacturers, without much real commitment from them except for a tangy quote by the CTO (Chief Technical Officer).
Second reason, for demise of Jini, was that for announcing service it used by default was UDP multicast. This is not Internet routable, causing Jini effectiveness to be blocked across routing borders and confining it within LAN segments.
Third, Jini was touted as being lean and mean by its evangelists, in reality when we looked seriously into Jini, to implement a distributed inter-city radio Paging message routing system, spanning 10 cities, over a VPN, we found it rather bulky. We had to start more than six services for 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 for the brand building exercise. A generic sounding name and an Aladdin's lamp logo did not help the recall factor either. Many NON technical project managers, probably associated Jini with the Walt Disney's cartoon strip rather 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 study of 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 watching too much Cartoon Network lately, but we are discussing serious stuff here, so lets stick to Java". This made me conclude that some people, outside the 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 finally gave in, but then, most of the time you can not bully your customers. I am sure other software developers, trying to sell Jini, might have hit similar speed breakers.
The Sun marketing gurus are back to their renaming game. They seem trying to 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 Transaction Architecture) is the new avatar of Jini. And spin-doctors are out on the circuit, hounding for a Grand Prix. I hope that the sprit of Jini will not haunt Jxta.
What more can be Jxta, than the old genie in a new bottle? I will find it 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 services in each layers:
Application Layer: Activation and lifetime support. Two activation types are provided, namely client activated and server activated.
Messaging Layer: provides message formating, SOAP and two other formatters are provided by default and you can add your own.
Transport Layer: Channels, provides transport layer services, for transporting 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 and a reference implementation of SOAP remoting. Visit http://jcp.org/jsr/detail/101.jsp for details.
This should build the confidence of the programmer community on Dot Net Architecture.