Summary


There are a number of good reasons to consider porting from a .NET-based environment to a Java EE-based one, particularly in the light of the growth of Linux and service-oriented applications. These reasons include cost drivers, thanks to Linux as well as open source application platforms such as JBoss; security considerations for applications on IIS and Windows; and scalability and reliability considerationsfactors that Java EE can give "off the shelf" without requiring manual coding. This chapter looked at an example module from the WS-I SCM example and at the implications of porting it from a C#/.NET to a Java/Java EE implementation. This example covered a broad area of technologies, including XML, databases and Web services. The likely issues to be faced when porting code were explored, and the specific issues when porting the example code were outlined. In addition, the alternative, a post-compile harmonization by translating the .NET MSIL to Java Bytecode using a commercial tool, Visual MainWin for Java EE, was also explored.

The conclusions that can be drawn from this are many. Despite the similarity of their language syntax, Java and C# (the most widely used .NET language) are dissimilar enough to make porting a project from one to the other a difficult task. This is because language is only the surface layer. The class libraries that a framework supports and the underlying architecture that runs applications built on that framework are more important factors to consider when translating from one to the other. In this case, the frameworks are drastically different, and as a result, the underlying architecture is also fundamentally different, leading to complexities when porting. It is up to the architects and owners of the application to decide whether these costs are worth it and to factor those costs into the overall effort of moving platforms.

In addition, there are a number of challenges that development management faces when building on dual platforms, not the least of which is having an acceptable pool of development skills that will allow both platforms to be sufficiently covered. The solution where a single skill set can be spread across both platforms to ease migration and support is a very desirable one, and it is in this case that the Visual MainWin for Java EE toolkit can really assist one's efforts. As it manages the porting of code in the post-compile stage, it means that your developers can concentrate on developing with one technology (in this case C# on .NET), and deployment can be on either platform without worrying about difficult migration factors. In a survey of their customer base, Mainsoft (producers of Visual MainWin) found that the average amount of code changes necessary to get the average C#/.NET application to run on Java EE was around 1 percent of the overall code.

On the whole, it can be understood that porting from a .NET to a Java EE environment can be a very valuable exercise, depending on the needs of the company and the architecture, but it isn't without its inherent expense. The decision comes down to the architects and the technologists, if there is porting across platforms, and whether to do it by rewriting the source code or by trusting in a cross compiler that handles it alone. Each has its own intrinsic costs, and it is worth thoroughly investigating the impact of both before a decision is made.




Java EE and. Net Interoperability(c) Integration Strategies, Patterns, and Best Practices
Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices
ISBN: 0131472232
EAN: 2147483647
Year: N/A
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net