Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Intrinsyc's Ja.NET—Extending the Reach of .NET Remoting  : Page 2

Java/.NET communication just got easier. Intrinsyc's Ja.NET tool lets you make remote bi-directional calls between Java and .NET applications, either through HTTP/SOAP or the faster TCP/binary channel. Even in this initial version, you can pass objects both by reference and by value. It's a great start, and with a little work, the next version will be killer.

I started out with the following set of Java classes. Listing 1 shows a factory class (MyFactory) that creates CustomerManager objects (see Listing 2), which manage Customer objects (see Listing 3) each of which may contain an Address class (see Listing 4). These four classes are sufficient to test server-side functionality.

I'm really looking forward to receiving the next version, because the announced features will make Ja.NET a killer application.
Using these classes, you can check the two most important features of .NET Remoting: passing objects by reference, which is implemented as a factory design pattern from within MyFactory, and passing nested object structures by value, implemented by the CustomerManager.GetCustomer() and CustomerManager.StoreCustomer() methods.

After compiling the example you need to take two underdocumented steps.

First, you must generate the .NET proxies that will allow the client to access the remote objects. To do that, switch to a command prompt and start the GenNet proxy generation wizard by running the following command line from the directory where your .class files reside:

java -classpath c:\janet\lib\gennet.jar;. com.intrinsyc.janet.gennet.GenNetApp

Second, wrapper generation does not occur within a Java process; it occurs in a Windows Service installed during the setup of Ja.NET. You must supply the connection information to the service. The manual contains an incorrect URI; the correct URI is tcp://localhost:8001. After adding the classes for which you want to generate proxies, you must select which classes you want to pass by value (as a copy). For the sample above, these will be Address and Customer.

On the next page of the proxy generation wizard, specify the destination assembly name and path for the .NET proxy assembly. Note that you must specify the .DLL extension for the assembly here! In this example, I used the assembly name FirstDotNetProxies.DLL.

GenNet stores your settings in a file so that you can invoke it with a —nogui parameter. This lets you regenerate the proxies directly from your build environment without going through the wizard each time.

Creating the C# client
After creating the .NET proxy assembly, you need to create a client side application (see Listing 5) to test the process.

This sample first creates a proxy to the remote factory object and acquires a new object reference for a CustomerManager object. It then fetches a populated Customer object, changes it, and passes it back to the server. It's important to note that the behavior of the new operator in .NET changes after the call to RemotingConfiguration.Configure(). Using new no longer creates a reference to a local object, it creates a so called TransparentProxy object instead. The proxy forwards all calls to the remote object.

To make this sample work, you also have to supply a .NET Remoting configuration file (see Listing 6). The configuration file specifies that whenever you create an instance of the class MyFactory using the new operator from the client side assembly FirstDotNetProxies (no .DLL here!), the framework should instead create a proxy to a remote object, located at http://localhost:3456/MyFactory.rem.

You also have to configure Ja.NET. Intrinsyc supplies a tool named Janetor that lets you create and edit Ja.NET configuration files.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date