Porting Using Mainsoft s Visual MainWin for Java EE

Porting Using Mainsoft's Visual MainWin for Java EE

Mainsoft has a solution for porting applications from C# to Java EE called Visual MainWin for Java EE. It is a cross compiler plug-in for Visual Studio.NET that allows the user to take C# code and compile it into Java bytecode for deployment on a Java platform. To understand how it does this, one must first understand, from a high level, the similarities between the .NET architecture and the Java EE architecture.

Whenever an application is built in .NET using C#, VB.NET, or any of the other languages that .NET supports, the compilation process generates a language called Microsoft Intermediate Language (MSIL), which normalizes the high-level language. In other words, if the same functionality is developed in C# or VB.NET and compiled, the MSIL for the two will be the same. MSIL is a CPU-independent language, which is converted into CPU-specific language at runtime by the .NET runtime using Just-in-Time (JIT) compilation. This is very similar to the Java concept of generating Java bytecode from source code, which in turn is executed by the Java Virtual Machine.

Visual MainWin for Java EE, at compile time in Visual Studio.NET, translates the MSIL into Java Bytecode. This bytecode can then be JAR'ed or WAR'ed up and deployed on an application server. When Visual MainWin for Java EE is installed, the desired application server must be specified (it presently supports WebLogic 8.1, WebSphere 5.1, JBoss, and Tomcat), and the process of compilation and cross compilation will deploy the application to its destination.

To support the .NET Framework, Mainsoft has provided a number of the .NET class libraries, based on the Mono project, as Java implementations, and the supporting JAR files can be installed on the application server. These namespaces are

• System.Web

• System.Web.Services

• System.Data

• System.XML

• System

• Mscorlib

• Microsoft.VisualBasic

This creates a unifed architecture for running .NET and Java EE applications within the same virtual machine. For more on this unifed architecture, see Chapter 15, "Managing Java EE .NET Interoperability Applications."

Translating the WS-I Scenario

If an application uses only these class libraries, it's not necessary to install any further dependencies. In following along with the application that was built in this chapter, porting to Java didn't present a challenge, based on the WSI SCM sample application.

Indeed, when using Visual MainWin for Java EE, an option is available upon right-clicking the solution in the Visual Studio.NET solution explorer to "Generate Java EE Project." This invokes the Java EE Project Wizard (Figure 16-6).

Figure 16-6. Visual MainWin Java EE Wizard

This wizard creates a Visual Studio workspace for containing the Java references to the converted .NET namespaces and sets up the properties for deployment to the application server, which is specified on the next step of the Wizard (refer to Figure 16-7). Note that this Figure shows that only Tomcat is available as an option. If the machine being used has BEA WebLogic or IBM WebSphere installed, they will show up also.

Figure 16-7. Java EE Application Server selection

Once the Wizard is complete, a new Visual Studio workspace is opened that contains the existing C# code; only now it is rebounded at compile time to the application server that was specified. In many cases the code can even be debugged as it runs on the application server using the Visual Studio debugger.

If the example code from this chapter is used and the wizard used step by step to create a Java EE application from it, it will execute without warning, without error, and most importantly without modification! Figure 16-8 shows the resulting Web service running on its test interface.

Figure 16-8. Warehouse Service running on Java EE with Visual MainWin test harness

Going Beyond the WS-I Scenario

Of course, not all scenarios are as straightforward as this one is to port. However, the tool is a full extension to Visual Studio.NET so a full debugging facility as well as the ability to manage references to Java Libraries and EJBs is provided.

As an example, consider the Retailer aspect of this scenario.

A simple Web application to consume the Warehouse Web service can be built in Visual Studio.NET as a Java EE project using Visual Mainwin for Java EE. Figure 16-9 shows this in the Visual Studio page designer. If the developer is familiar with Visual Studio.NET, he or she will notice that nothing has changed, and he or she can design the app without any changes to the methods of work even though it's going to run on Java EE.

Figure 16-9. Visual MainWin for Java EE in Visual Studio

This application has a Web reference to the Web service that was built earlier, which is running on the Java EE platform. Visual Studio.NET generates the proxy to the Web service and automatically generates asynchronous stubs, used by the Web service consumer.

Figure 16-10 shows the application running on Java EE using the Visual Studio.NET debugger to capture the asynchronous callback from the Web service.

Figure 16-10. Using Visual MainWin to debug a Web application running on Tomcat

This provides a useful alternative to straight porting because many of the .NET-specific features can be kept on the source-level of the application (such as ViewState and Asynchronous Web services callbacks), and yet run and debug them on Java EE. In addition to this, the namespaces that it supports, as outlined earlier, reduce the need to port a number of dependencies.

For example, consider the System.Data namespace. The implication of this is that the ADO.NET class libraries for accessing SQL Server and Oracle are already available, and no extra JDBC drivers are required when something is cross-compiled. If any of the other databases are used, then a number of options are available. Should the database driver for ADO.NET be open source (as is the case with MySQL), this can simply be cross-compiled with the rest of the code. For dependencies that do no have .NET source code available, the environment allows the developer to import Java or EJB references and code to themand the code will be ported. In this case, deployment needs to be able to talk to those references too, and one would use the administrative tools on the application server to set that up.

Finally, if there are already assets deployed on Java, such as JARs of class libraries or Enterprise Java Beans, references can be added to them to consume them from the Visual Studio.NET-developed Java applications, [MORO1].

If the goal is migrating applications from .NET to Java, the Visual MainWin significantly simplifies the migration process.