|
Introduction
Portability is a feature that can notably improve the market share of a software product.
The ASP.NET technology allows the development of web applications that are browser independent
but it limits the application to running inside an IIS web server.
The Mono project allows the
execution of these applications on other web servers. It implements a Common Language Runtime
that allows the execution of these applications on non-Microsoft systems without re-compiling
the code. Mono does this by implementing a custom application server and as a result
doesn't allow the execution of these applications inside a 3rd party application server.
Enter Visual MainWin from Mainsoft. Visual MainWin introduces a new C# or VB.NET compiler
that allows the generation of Java bytecode. In this way these applications can run inside
the traditional applications server (JBoss, WebSphere, etc.) increasing notably the
application portability.
What is Visual MainWin?
Visual MainWin for J2EE Developer Edition, also known as "Grasshopper", is a Visual Studio .NET
plug-in that Mainsoft freely delivers through its own site devoted to the developers:
http://dev.mainsoft.com.
Visual MainWin enables developers to create applications for the J2EE platform using C# or VB.NET
that reference the ASP.NET and ADO.NET class libraries. It is a complete development solution that includes:
- A development environment integrated into Visual Studio .NET that can be used to develop, deploy, and debug J2EE applications.
- A set of Java runtime libraries (mainly derived from the Mono project) that enable applications to run on a J2EE application server.
The commercial version of Visual MainWin, named Enterprise Edition, supports more application servers, allows the
debugging of the native Java library, and presents other advanced functionalities. MainSoft guarantees and supports
only the Enterprise Edition. For further information about the differences between the free and the commercial versions,
see http://www.mainsoft.com/products/vmw_j2ee.aspx.
During the tests I have used the trial of Visual MainWin Enterprise Edition rel. 1.6.0.56 on Windows XP using SQL Server 2000.
Visual MainWin allows the development of C# or VB applications in two ways:
-
Native J2EE: the C# or VB code is compiled only for J2EE platform; to do this, we have to open a new "Visual MainWin C # or VB for J2EE Project" using the wizard shown in the following figure:
- Single Source Development: this way allows the generation of executable code for both the .NET and J2EE platform.
During the tests I have used the 2nd way.
Visual MainWin supports the main J2EE Application Servers (the possible use of EJB is limited to JBoss, WebSphere and WebLogic)
and several DBMSs: Oracle, SQLServer, PostgreSQL, DB2, Sybase.
How Does It Work?
Visual MainWin introduces a patent-pending technology, that enables the binary compilation of Microsoft Intermediate Language (MSIL)
into standard Java bytecode. Developers can write programs in C# or VB and then compile their source code directly into standard
Java bytecode.
The following figure (derived from the Mainsoft documentation) shows this compilation process.
Binary compilation from MS Intermediate Language to Java bytecode
Practically, the binary compiler then reads the .NET assemblies and generates Java bytecode.
Unlike the standard Microsoft compiler that produces a single DLL for each project, this new compilation process
produces one DLL (and then a class files) to correspond to every C# source files.
Subsequently, these class files are linked inside a single Jar, War or Ear file. For more information about
the compilation process, please see: http://dev.mainsoft.com/Default.aspx?tabid=32&src=Overview.html
The Visual MainWin compilation process produces an application (Jar, War, Ear) structurally equal to what
we can get with the compilation of a Java source file. The only difference is the language used to write it.
Nevertheless, the transformation of the DLLs into Java byte code is not enough to produce a working application.
In fact the original application references several class libraries that are not implemented in the J2EE platform.
Therefore, Visual MainWin provides a Java implementation of the ASP.NET and ADO.NET class libraries based on the
Mono project. Mainsoft also developed a thin hosting layer on top of J2EE in order to bind the Mono class libraries to the services supplied by the J2EE platform:
- ASP.NET HTTP layer uses servlets
- ADO.NET database connectivity uses JDBC
- Web service clients use Java sockets
- Web services use servlets
The following figure (derived from the Mainsoft documentation) shows the class library architecture.
Runtime libraries stack
Visual MainWin uses some Mono components, but it is very different from Mono.
In fact, Mono offers the partial implementation of the .NET framework class library and provides a custom
version of the Common Language RunTime for the execution of .NET applications. Practically, Mono implements
a its own custom Application Server. Contrarily, Visual MainWin produces J2EE applications whose execution
uses the traditional J2EE Application Server.
Single Source Development
After having opened an ASP.NET solution, we can select the project folder in solution explorer and then we
can run the option "Generate J2EE project".
This option creates a second project with the J2EE extension inside the same solution.
All the references of the original project (aspx pages, web-reference, etc.) are cloned in the second project.
Additionally, it creates some new folders that contain specific files for the J2EE platform.
Particularly:
- the "assembly" folder contains the temporary class files;
- the "Web-INF" folder contains the web.xml file for the application configuration for Tomcat;
- the " bin_Java" folder contains the war file for the application deployment (we have a jar file if the .NET project produces a simple DLL library).
The option "Generate J2EE project" produces a second project inside a single solution.
The source files are physically shared, but the project files are separated; this means that if we
add a web page in the original project, we must repeat this operation inside the J2EE project.
As a rule, the addition of library references should be performed twice for both the .NET and J2EE projects.
In the case of a .NET application we add a reference to a DLL; in the case of a J2EE application we add a
reference to a JAR. Obviously this JAR library could be developed using native java source files or using Visual MainWin.
Practically, if the ASP.NET application references a DLL assembly, the new J2EE application will have to
reference the same library in JAR format. If the source files of this library are available, we can use
the Visual MainWin compiler (in a separate project) to get the JAR library. Contrarily, if the source
files are not available, we need require a JAR format of this library from the provider.
To this intention, MainSoft signals the availability of the Infragistics controls for the J2EE platform.
Unfortunately, Visual MailWin doesn't allow us to get a Jar library directly from a DLL assembly without
using the source code.
As a rule, a traditional ASP.NET project can reference only the resources involved in the compilation process:
aspx pages and C# or VB source files. The other files (bitmap, CSS, client-side script, etc.) could be copied
to IIS without being referenced in the ASP.NET project. Contrarily, a J2EE application is entirely stored in
a single war file that holds the whole application. This means that we must reference all the resources before
creating the war file. Besides, the "Deployment Packager" option (show in the following figure)
allows us to produce a deployment file that includes the whole Run-Time components, including the Visual MainWin
framework library.
Debug and Execution
The compilation process is very slow and, for the complexes projects, can require several minutes.
Before activating debugging, Visual Studio deploys the application on Tomcat and then actives Internet Explorer.
The debugging of a J2EE application has a similar behavior to that of a tradition ASP.NET debugger.
The execution of these applications on Tomcat is equivalent to the execution of the applications
written with native Java code. The ".aspx" extension of the Web pages is the only indication
that the application is derived from a .NET solution.
Database Access
Visual MainWin maps the open and close statements of the Database Connection with the equivalent JDBC
statements without requiring the change of the original ConnectionStrings. In this scenario, the
application execution effects the physical open and close of the DB Connection corresponding
to these JDBC statements without using the ConnectionPooling managed by the application server.
The following figure shows the performance graph of a simple application that reads data from a database
table and populates a dataset using a traditional ADO.NET ConnectionString:
Alternatively, Visual MainWin allows you to use the JNDI DataSource defined on the Application Server.
This option requires some modification of the configuration files; for more details see:
http://dev.mainsoft.com/Default.aspx?tabid=32&src=ConfiguringForJndiDataSource.html.
As a rule, if the application holds the DbConnectionString in a configuration file (such as Web.Config),
to use JNDI DataSource we don't modify the source code; it is enough to modify these configuration files: web.config, web.xml, etc.
The following figure shows the performance graph of the same application using a JNDI Database connection.
The use of the DataSources JNDI allows a notable increase of the performances, while the SQL Profiler
comfirms the use of a single DB connection during the execution of the whole test.
Workaround
Visual MainWin doesn't implement the namespaces OracleClient or ODBCClient; to access to an Oracle Database we
need to use the classes of the namespace OleDb (that introduces evolved functionality) implemented in the
System.Data.jar library.
The official MainSoft documentation exposes other limitations
(see: http://dev.mainsoft.com/Default.aspx?tabid=32&src=Limitations.html);
some are mandatory, other limitations are due to inefficient java bytecode.
We can use conditional compilation in order to implement different behaviours between the .NET and J2EE releases:
#if JAVA
...// do something
#else
...// do otherwise
#endif
The tests I have run have indicated that it is unlikely that you'll be able to port a real world application to Tomcat
on the first try due to several problems. These problems could be tied to the limitations described above
or other limitations imposed by the new system. For instance, Tomcat is case-sensitive while IIS is case-insensitive;
therefore we need to verify the case of all URLs used by the application.
Unfortunately, we may also run into other problems that are difficult to predict due to typical defects of the system.
This situation shouldn't be a since it is part of the natural life cycle of every software product.
Performance and Scalability
The tests were run on a system that was not specifically configured for offering high performances.
However these tests have verified the application scalability:
- the increase of the number of connected clients doesn't have to decrease the server availability
- the increase or the persistence of the client requests doesn't have to presents pauses or system blocks
The tests were performed using Microsoft Application Center Test rel. 1.0.536 simulating a increasing number
of client for 60 seconds.
As we have already seen, the use of the JNDI DataSources guarantees better performance and has good scalability.
The following tests perform a Web Application that reads the data from several tables, inserts the data into
a DataSet and then exports it as an XML stream. The following figure show the performance graph of this
application using a JNDI DB Connection.
The execution on IIS of the .NET version of the same application allows better performance. This result doesn't
really surprise us: it is known that the .NET applications are generally faster than Java applications.
As a rule, the J2EE technology is normally used to port the application in situations where .NET technology is not available.
Now we can ask: what is the performances comparison between a J2EE application developed with Visual MainWin and a similar
application written with Java? To answer this question I've implemented the same application using the Java language.
The following figure show the performance graph of this native Java application that underlines a slight increase
in performance:
Conclusion
Visual MainWin is a very special product because it stands at the crossroad between two very popular technologies.
Therefore it will probably have a meaningful evolution in the coming years. Nevertheless it is unlikely that Visual
MainWin will be able to support the technological evolution of both the Java and .NET. platform in a timely fashion.
Therefore, this product probably won't be used by developers that are interested in a single platform.
Contrarily Visual MainWin is an essential tool for those who need the highest portability for their applications.
About the Author
Marco Nanni is an Italian developer with experience in Web technology used for implementing enterprise solutions.
Marco can be contacted at: mnanni (at) lycos (dot) it
|
