The Generated Proxies API

This document explains how .NET classes are mapped onto Java proxies. This process is performed by the GenJava tool, which requires a .NET assembly as input and generates Java source code.

In connection with this document you may also like to read the section Type Mapping Between Java Types and .NET Types.

Classes

There is a direct one-to-one mapping between .NET classes and Java classes. For example, a .NET class called "C" in the namespace "A.B" will generate a Java class "A.B.C". The most important point to realize is that J-Integra for .NET maintains the class hierachy between .NET and Java classes. This means that Java proxies for the super classes and the implemented interfaces of a .NET class are also generated. However, Java proxies are generated only for .NET classes with public access.

In order for a .NET class to be accessible via .NET Remoting , it must either derive from System.MarshalByRefObject, in which case it can be "marshalled-by-reference", or it must be marked with the Serializable attribute, in which case it may be "marshalled-by-value". The proxies generated in these cases are different and are discussed below.

Marshal By Reference Classes

Instances of marshal by reference classes represent remote objects. Each access to such a proxy incurs a remote access to the original remote object. The proxy is a reference to the remote object.

Constructors

J-Integra® for .NET supports constructors with parameters. For each public constructor in a .NET class, two constructors in the Java proxy are generated. For example for the following .NET constructor:

public MyClass(String s)

Two Java constructors are generated:

public MyClass(String s) throws RemoteException

and:

public MyClass(String s, String URI, String format, boolean clientActivated) throws RemoteException

Both of these Java constructors use the same .NET constructor, but the difference is that the configuration parameters for the class are read from the configuration file in the first case, whereas the second constructor allows the configuration file settings to be overridden. The settings can be overriden by specifying the configuration details, such as the URI of the remote object, the format (binary) for the remote object communication, and whether it is client or server activate, as parameters.

Methods

For each public method in a .NET class, an equivalent Java method is generated. More information on the mapping of parameters types can be found in the section Type Mapping Between Java Types and .NET Types. As with constructors, each method can throw a RemoteException in case of a communication failure, or an exception being thrown in the remote method itself.

Fields

.NET Remoting provides no means to access a marshal by reference object's fields directly across the application domain. Since J-Integra® for .NET adheres to the .NET Remoting standard, it also has no means to do this. The proper way to expose fields is to use .NET properties, which J-Integra for .NET does support.

Marshal by Value classes

Marshal by value classes are serialized and sent over the wire. The Java proxy for a marshal by value class contains all the fields of the .NET class along with get/set methods for each field. Access to these fields does not incur any extra remote access, as these objects are not proxies and actually "live" on the Java side. Marshal by value objects are used when the class is a container for data.

Interfaces

For each .Net interface, two Java source files are generated - the actual interface and a proxy for that interface. The Java interface is for use by the Java client code, whereas the Java proxy is used by the runtime to marshal calls through that interface. Methods in the interface are mapped as described above for marshall by reference classes.

© 2007 Intrinsyc Software International, Inc. All rights reserved. Legal