View source for Java RMI vs .Net Remoting

'''A comparison of middleware technologies<br>
Java RMI vs .Net Remoting<br>
By Nathan Wood<br>
UPI: Nwoo050, ID: 4331210<br><br>'''

Pdf version: http://www.geocities.com/giant_stone_soldier/SE325Assignment2Nwoo050.pdf

==Introduction==

The SE325 course has covered the general concepts regarding distributed object middleware, and how it is used, and has gone into some depth about Java RMI. However, distributed object middleware is a competitive environment with many different technologies available for use. Because of this, there is a need to go into depth about other middleware technologies available as well as looking into the differences between them.<br>

This report will start by going over what has been taught about Java RMI. This is done so that the reader has a basis of which to compare Java RMI to other middleware technologies. It will then look into .Net Remoting, and how it works, so that the reader has some background from which to draw his or her own conclusions<br>

Finally, this report will make a comparison between Java RMI and .Net Remoting in order to flesh out the pros and cons of each and state the differences between the two approaches.

==Why this Topic Was Chosen==

This topic was chosen because it provided a means of using the course material (for the basis of the comparison) and reading beyond the course materials (for the technology chosen to be compared) together in such a way that the reader could easily gain further understanding with only the knowledge gained from the course as a basis.<br>

Another reason this topic was chosen over others is that there is a large amount of information about the various implementations of distributed object middleware. This allowed for a good selection of resource materials and information.<br>

.Net Remoting was chosen for the comparison as opposed to Web services, Enterprise Java Beans or ICE because the MDSN library contains a lot of information about .Net and its features, much more than other approaches like ICE which seemed to have very little information (or little that was available/easy to access).

==Java RMI==

The SE325 course has gone into depth explaining Java RMI, so this is basically just a rehash of the concepts introduced in order to provide a comparative basis when looking at other RMI implementations.

===Similarity to CORBA===

One of the main concepts important to discussing Java RMI is it’s similarity to CORBA. Java RMI borrows the following concepts from CORBA:

* Proxy Objects ‐ A proxy object is a local representative of an actual object which sits transparently between a client and an accessible object and monitors it’s state. The proxy then forwards any calls to that object to the object itself, as long as the object being called has not been destroyed or changed.
* Generated Stub and Skeleton Code ‐ Stub and skeleton code is responsible for marhalling/unmarshalling method arguments and return values into CDR form. The interface for a remote CORBA object must be defined exclusively in IDL – so a CDR form describes only IDL data. This is automatically done in Java RMI.
* Remote Objects and Object References– This allows an object on one Java virtual machine to invoke methods on an object in another Java virtual machine.

===Simpler to Program===

Since the entirety of Java RMI is written in java, the only language which is required is java. This is mainly due to the fact that Java already offers cross platform compatibility as one of its design features.<br>

Java RMI also offers much less in the way of server‐side APIs, associated resource management and services, and so is relatively easy to learn and use.<br>
Java RMI’s only services are a basic naming service and a minimal object activation service. 

==.Net Remoting==

.Net Remoting is a middleware technology developed by Microsoft. Its main feature is “the separation of the remotable object from a specific client or server application domain and from a specific mechanism of communication.”[2] This allows it to focus on flexibility and customization, and allows the programmer to swap protocols and formats around without changing the existing client or server.

===Configuration===

.Net Remoting needs to be told specifically how to work in order to run smoothly and effectively. This is done through the use of configuration files. This is done either through configuration methods stored remotely on a server(programmatic configuration), or by making a XML configuration file.

===Channels===

.Net Remoting uses special objects called channels to transport messages between domains, processes, or computers. A channel can listen on an endpoint for inbound messages, send outbound messages to another endpoint, or both. This enables you to plug in a “wide range of protocols”, “even if the common language runtime is not at the other end of the channel.”[3]

===Architecture===

.Net Remoting offers a special type of approach, which allows objects to be either passed by value or copied. These objects can then be automatically passed between any process or computer or domain. In order to do this, classes are marked as serializable.[4]

===Copying===

.Net allows the copying of objects over a channel. This is not always safe however, as large objects are not easily copied, and due to other considerations such as security issues and locks on objects.

===Simplified Version===

Since .Net Remoting has many complicated processes and methods attached with it, it also offers a much simpler procedure, where only need to create a new instance of the remote object using new. This allows it to have a system which is easier to use than Java RMI, with the flexibility of the channels system and other components.

==Differences between Java RMI and .Net Remoting==

This section details the some of the important differences between Java RMI and .Net Remoting and the pros and cons each of the differences provides.

===Distributed Directory===

Java RMI uses a RMI Registry, which is a sort of directory service of names and addresses (like a phonebook). With this directory, clients and servers can register their “address” and this can be distributed throughout the system. .Net Remoting uses the “Windows native register”, which can’t be distributed. Because of this, there is no distributed directory within the .Net framework. This means that if the system is to be kept simple, addresses and names must be hard coded. Java RMI is much superior in this case.

===Available protocols===

'''Java RMI'''

*HTTP
*FTP
*IIOP
*JRMP
*ORMI
*+ more

'''.Net Remoting'''

*HTTP
*TCP
*SOAP

Java has a better choice in protocols for RMI, which means it offers much better compatibility.

===Proxies===

With .Net Remoting, proxies are created during runtime. Java RMI uses stubs and skeletons which are automatically created during compile‐time. This means that Java RMI offers a lot in performance over .Net Remoting, but loses some of the flexibility which comes with the ability to change during runtime.

===Typing===

Java uses primitive typing (int, char, etc) whereas .Net does not. .Net does however have a system called “Boxing” which allows all types to become objects, making it fully object oriented. This again increases flexibility with a loss to performance. When it comes to distributed object middleware, naturally the more types that can be considered objects, the more remote objects can be referenced, and the more objects can be distributed.

===Simplicity===

Java is very simple to use, and Java RMI is also simple to use by extension. .Net Remoting has a simplified version for new programmers (or programmers who do not want to delve too deeply into middleware) but this does not offer the range of abilities which are inherent in Java RMI. 

==Conclusion==

In conclusion, Java RMI and .Net Remoting each have their good and bad points. Java RMI is superior in ease of use, amount available protocols. The use of a distributed directory is an interesting case, because although Java RMI is superior in the fact that it is able to use a distributed directory, the increase in resource use when using one may have a large impact on larger systems, also, if a distributed directory is not needed, the fact that Java RMI forces you to use one can be a bad thing.<br>
When it comes to proxies, both Java RMI and .Net Remoting have advantages in different areas. In a system where performance is tight, Java RMI is the superior choice to .Net Remoting, as the reduced resource use during runtime can be important. However, since .Net Remoting has much more flexibly with proxies, it is clearly superior if resources are not an issue.
Typing brings up the same issue. The fact that all types in .Net are able to become objects means that .Net Remoting has much more flexibly in remote referencing and other key components of distributed object middleware. Again this means that .Net Remoting is superior in a system where resources are not an issue.<br>
These effects are shown clearly in the “Java RMI and .Net Remoting Performance Comparison”[6] where Java RMI outperforms .Net Remoting in every test which was run. This does not mean that Java RMI is overall superior to .Net Remoting though, as in some systems the flexibility offered could make .Net Remoting the better choice. In the end it comes down to the system being used and what priorities performance and flexibility are given.

==References==
[1] SE325, Lecture 7, “Distributed Object Middleware” (used throughout report)<br>
[2] http://msdn.microsoft.com/en‐us/library/kwdt6w2k(VS.71).aspx “.NET Remoting Overview“<br>
[3] http://msdn.microsoft.com/en‐us/library/aa719689(VS.71).aspx “Channels“<br>
[4] http://msdn.microsoft.com/en‐us/library/2e7z38xb(VS.71).aspx “.NET Remoting Architecture”<br>
[5] http://www.omg.org “The Object Management Group” (used throughout report)<br>
[6] http://www.cs.ru.nl/~marko/onderwijs/oss/RMI_and_Remoting.pdf “Java RMI and .Net Remoting Performance Comparison” (used throughout report)<br>