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.
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 VB.NET 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 VB.NET.
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. Visithttp://jcp.org/jsr/detail/101.jsp for
details.
This should build the
confidence of the programmer community on Dot Net Architecture.