#radio Radio Serbia by EnjoyIT 1.0 http://t.co/nGQFvX2E
10 minutes ago by RealTonyRocha on twitter
Breaking News: CFOs increasingly involved in IT investment decisions
ZDNet / Techguide / Web Development
Five reasons against migrating Java EJB applications to .NET
Summary
Migrating from Java to .NET is not an easy task, and you may just be better off with your exisiting application. These five reasons spell out why you should stick with Java.
Events
Echelon 2012
June 11 and 12, 2012
University Cultural Centre, National University of Singapore
Startup Asia Jakarta 2012
June 7 and 8, 2012
12th Floor, Annex Building, Wisma Nusantara Complex, Jl. M.H. Thamrin No. 59 Jakarta 10350, Indonesia
MMA Forum Singapore
April 23-25, 2012
Grand Hyatt Singapore
The .NET Framework has been touted as the next big thing for the distributed
computing community. Redesigned from the bottom up, Microsoft’s newest offering
has made marked progress in areas such as XML
integration, error handling, component processing, and reusable frameworks. The
promise for Web development is clear: faster development, less custom coding,
and increased stability.
But what if your current application is currently a Java EJB implementation? Is it worth the cost and effort to migrate to Microsoft’s new platform? While the benefits of .NET over Java EJB certainly will be debated for years to come, the difficulties involved with such a platform port are a little more predictable. Even assuming a compelling technical or business reason driving the requirement, here are five good reasons not to migrate your Java or J2EE applications to .NET.
1. CLR does not support Java
The first stumbling block on the road to .NET is its set of supported languages. The .NET Framework relies on a Common Language Runtime (CLR) that promises compatibility with multiple languages, but this compatibility is limited currently to C#, C++, VB, and (soon to come) J#. Not surprisingly, Java is not a supported language in the CLR.
It's possible to migrate the Java application tier to .NET without rewriting the application code in a CLR-supported language by using a Java COM bridge or Web services. Java COM, however, relies on third-party applications to create COM DLLs directly from pure Java code. Difficulties in debugging the resultant binary, as well as increased complexity in the environment, illuminates why such heterogeneous application development should be approached with caution, or avoided completely.
An alternative strategy is to port your Java code to C# code. In theory, you can translate Java code directly into C# (and J#) code through automated applications. For example, ArtinSoft's Java Language Conversion Assistant Enterprise Edition (JLCA EE) promises up to 99 percent automatic conversion from Java to C#. However, such products have yet to prove themselves in the marketplace, and experience argues against believing in automatic code conversions. Whether through an automated processor or done manually, a language port will undoubtedly require associated architectural changes. Depending on the implementation specifics of your application, significant refactoring may be required when rewriting a Java application to VB, C++, C#, or J#.
2. IIS does not support JSP
As if an application language port from Java to C# is not daunting enough, .NET will also require a presentation language port. JSP is not supported by IIS. Moving from JSP to ASP.NET is a significant undertaking and will demand a complete rewrite of the presentation layer. Additionally, major architectural models, such as code reuse through tag libraries, are not supported in ASP.NET. Tag libraries must be converted to server controls or server side includes (ssi). Interestingly, Java classes written to support tag libraries conceptually match .NET’s code-behind classes. Significant work, however, will be required for the actual conversion.
3. Server controls require redesigns
As mentioned, new architectural requirements will undoubtedly surface during a language rewrite of your code base for .NET. This will become immediately evident if the implementation of .NET server controls is planned. ASP.NET server controls are one of the biggest advantages offered by .NET. By utilizing prebuilt server components, developers can reduce repetitive coding and easily access functionality through objects. Taking advantage of server controls during a migration to .NET will most likely entail removing custom presentation, application, and database code and replacing it with a server control and required database logic.
When upgrading from an existing Microsoft application, this code extraction will not be difficult, especially if good coding practices have resulted in cleanly partitioned and well-organized code. However, when moving from a Java EJB application, server controls require deep vertical migration and may simultaneously impact the data, application, and presentation tiers of the application. Not only will the stored procedures, Java objects, and JSP files require porting to Microsoft-supported standards, they also will have to be modified to support the Server Control.
For example, the DataGrid object provides complex table functionality to display a set of data records. Row and column selection, header styles, and paging functionality are just a few of the properties available for customization. The DataGrid object is more functional and maintainable than any custom or proprietary code base is likely to be. But to take advantage of this control during a port from a Java application (assuming you're moving an Oracle data tier to SQL Server), it would require:
Assuming that the existing Java application is supported by a non-SQL Server database, migrating the application will most likely require either porting the database over to SQL Server or integrating the proper drivers to allow your .NET application to persist data through a non-SQL Server database. In either case, you'll need to rewrite your JDBC connection classes to ADO.NET and migrate your Java ResultSets to ADO.NET DataSets. This task in itself is not overly difficult. DataSets and ResultSets are similar mechanisms and beyond implementation specifics should not require significant rearchitecture.
Migration difficulties will start to surface when the dev team begins porting object persistence from Java to .NET. .NET has no support for Container Managed Persistence (CMP) and no similar mechanism. If your application relies on CMP for object persistence, you'll be forced to rewrite these object classes with the embedded logic for data retrieval and loading.
5. Different session handling implementation
The EJB standard does not specify the handling of session data, so EJB session-handling implementation becomes completely application server specific. Since differences in session-handling implementations can have a profound impact on performance, scalability, and network design, you must understand the implementation details of your application’s session-handling mechanisms.
In .NET, Microsoft introduces a distributed session model that makes session data available over multiple application servers in a Web farm by using Microsoft SQL Server to store the application state. Since .NET relies on embedded functionality within SQL Server for sessioning, heterogeneous applications using Oracle or other non-SQL Server databases will be required to implement a SQL Server instance solely for distributed sessions. Additionally, since large amounts of session data will reduce overall system performance, prudent use of session storage is a necessity.
Uphill battle to parity
The .NET Framework represents Microsoft’s latest effort to function in the world of highly available, enterprise-level applications. Many features long absent from previous versions of IIS, Visual Studio, VB, and SQL Server are now available on the new platform. Microsoft developers and users can start to feel parity with other industry competitors in realms of scalability, extendibility, security, and performance.
Industry hype aside, the key point is that .NET represents only parity with EJB solution providers—there is no overriding indicator that the .NET platform is superior to WebSphere, WebLogic, or any other EJB application server. For existing IIS/ASP solutions, the benefits to migration are clear. For new initiatives, depending on staff skills and organization orientation, .NET may be the framework of choice. But for existing Java EJB applications, unless you want to fight an uphill battle to parity, leave them right where they are.
But what if your current application is currently a Java EJB implementation? Is it worth the cost and effort to migrate to Microsoft’s new platform? While the benefits of .NET over Java EJB certainly will be debated for years to come, the difficulties involved with such a platform port are a little more predictable. Even assuming a compelling technical or business reason driving the requirement, here are five good reasons not to migrate your Java or J2EE applications to .NET.
1. CLR does not support Java
The first stumbling block on the road to .NET is its set of supported languages. The .NET Framework relies on a Common Language Runtime (CLR) that promises compatibility with multiple languages, but this compatibility is limited currently to C#, C++, VB, and (soon to come) J#. Not surprisingly, Java is not a supported language in the CLR.
It's possible to migrate the Java application tier to .NET without rewriting the application code in a CLR-supported language by using a Java COM bridge or Web services. Java COM, however, relies on third-party applications to create COM DLLs directly from pure Java code. Difficulties in debugging the resultant binary, as well as increased complexity in the environment, illuminates why such heterogeneous application development should be approached with caution, or avoided completely.
An alternative strategy is to port your Java code to C# code. In theory, you can translate Java code directly into C# (and J#) code through automated applications. For example, ArtinSoft's Java Language Conversion Assistant Enterprise Edition (JLCA EE) promises up to 99 percent automatic conversion from Java to C#. However, such products have yet to prove themselves in the marketplace, and experience argues against believing in automatic code conversions. Whether through an automated processor or done manually, a language port will undoubtedly require associated architectural changes. Depending on the implementation specifics of your application, significant refactoring may be required when rewriting a Java application to VB, C++, C#, or J#.
2. IIS does not support JSP
As if an application language port from Java to C# is not daunting enough, .NET will also require a presentation language port. JSP is not supported by IIS. Moving from JSP to ASP.NET is a significant undertaking and will demand a complete rewrite of the presentation layer. Additionally, major architectural models, such as code reuse through tag libraries, are not supported in ASP.NET. Tag libraries must be converted to server controls or server side includes (ssi). Interestingly, Java classes written to support tag libraries conceptually match .NET’s code-behind classes. Significant work, however, will be required for the actual conversion.
3. Server controls require redesigns
As mentioned, new architectural requirements will undoubtedly surface during a language rewrite of your code base for .NET. This will become immediately evident if the implementation of .NET server controls is planned. ASP.NET server controls are one of the biggest advantages offered by .NET. By utilizing prebuilt server components, developers can reduce repetitive coding and easily access functionality through objects. Taking advantage of server controls during a migration to .NET will most likely entail removing custom presentation, application, and database code and replacing it with a server control and required database logic.
When upgrading from an existing Microsoft application, this code extraction will not be difficult, especially if good coding practices have resulted in cleanly partitioned and well-organized code. However, when moving from a Java EJB application, server controls require deep vertical migration and may simultaneously impact the data, application, and presentation tiers of the application. Not only will the stored procedures, Java objects, and JSP files require porting to Microsoft-supported standards, they also will have to be modified to support the Server Control.
For example, the DataGrid object provides complex table functionality to display a set of data records. Row and column selection, header styles, and paging functionality are just a few of the properties available for customization. The DataGrid object is more functional and maintainable than any custom or proprietary code base is likely to be. But to take advantage of this control during a port from a Java application (assuming you're moving an Oracle data tier to SQL Server), it would require:
- Rewriting P/L SQL to Transact SQL while formatting the queries to support the DataGrid.
- Rewriting the Java application code into a .NET-supported language to invoke the SQL or stored procedures and to support the event model of the DataGrid.
- Rewriting the JSP templates to ASP.NET while removing the code supporting the existing, custom data presentation objects.
Assuming that the existing Java application is supported by a non-SQL Server database, migrating the application will most likely require either porting the database over to SQL Server or integrating the proper drivers to allow your .NET application to persist data through a non-SQL Server database. In either case, you'll need to rewrite your JDBC connection classes to ADO.NET and migrate your Java ResultSets to ADO.NET DataSets. This task in itself is not overly difficult. DataSets and ResultSets are similar mechanisms and beyond implementation specifics should not require significant rearchitecture.
Migration difficulties will start to surface when the dev team begins porting object persistence from Java to .NET. .NET has no support for Container Managed Persistence (CMP) and no similar mechanism. If your application relies on CMP for object persistence, you'll be forced to rewrite these object classes with the embedded logic for data retrieval and loading.
5. Different session handling implementation
The EJB standard does not specify the handling of session data, so EJB session-handling implementation becomes completely application server specific. Since differences in session-handling implementations can have a profound impact on performance, scalability, and network design, you must understand the implementation details of your application’s session-handling mechanisms.
In .NET, Microsoft introduces a distributed session model that makes session data available over multiple application servers in a Web farm by using Microsoft SQL Server to store the application state. Since .NET relies on embedded functionality within SQL Server for sessioning, heterogeneous applications using Oracle or other non-SQL Server databases will be required to implement a SQL Server instance solely for distributed sessions. Additionally, since large amounts of session data will reduce overall system performance, prudent use of session storage is a necessity.
Uphill battle to parity
The .NET Framework represents Microsoft’s latest effort to function in the world of highly available, enterprise-level applications. Many features long absent from previous versions of IIS, Visual Studio, VB, and SQL Server are now available on the new platform. Microsoft developers and users can start to feel parity with other industry competitors in realms of scalability, extendibility, security, and performance.
Industry hype aside, the key point is that .NET represents only parity with EJB solution providers—there is no overriding indicator that the .NET platform is superior to WebSphere, WebLogic, or any other EJB application server. For existing IIS/ASP solutions, the benefits to migration are clear. For new initiatives, depending on staff skills and organization orientation, .NET may be the framework of choice. But for existing Java EJB applications, unless you want to fight an uphill battle to parity, leave them right where they are.
Resource Centre Useful content from our premier sponsors
Web Development TechGuides
Creating a liquid layout for an Agile Platform theme
Working with Visual Studio 2010 from command line
Key to making applications discoverable
Easily connect to RavenDB data via C#
Use qTrace to replicate errors for QA testing
Tips on making sure your apps work for mobile users
RavenDB, a database alternative for .NET developers
Importing existing database schemas as Agile Platform entities
5 persistent Web application myths
Improve page performance with Microsoft Ajax Minifier
ZDNet Asia Live
Rise in <b>Chinese</b>-funded acquisitions could trigger more hurdles http://t.co/0pXBS1HR
40 minutes ago by GeorgeHAllenGA on twitter
Rise in Chinese-funded acquisitions could trigger more hurdles: By Ellyne Phneah , ZDNet Asia on May 22, 2012 (6... http://t.co/W3SOdw2c
40 minutes ago by MergeAcquire on twitter
RT @zdnetasia: CFOs increasingly involved in IT investment decisions. http://t.co/8QrfwOSb
55 minutes ago by 666hellscream on twitter
CFOs increasingly involved in IT investment decisions http://t.co/XD1LerFq via @zdnetasia #PrivateCloud #SC2012 #CAPEX
1 hour ago by HarishAitharaju on twitter
Rise in Chinese-funded acquisitions could trigger more hurdles. http://t.co/VC3G3m3o
1 hour ago by zdnetasia on twitter
RT @zdnetasia: Rise in Chinese-funded acquisitions could trigger more hurdles. http://t.co/VC3G3m3o
1 hour ago by wrikent3500 on twitterSo much as we know , MTK6575 extremely integrated frequency1GHz ARM Cortex-A9 processor, the superiority of 3G / HSPA Modem, and help the...
1 hour ago by y15822137359 on 5 SaaS adoption speed bumps to avoid
Rise in Chinese-funded acquisitions could trigger more hurdles - ZDNet Asia: Rise in Chinese-funded acquisitions... http://t.co/bZaAQnRL
1 hour ago by MandAWorldwide on twitter
Rise in Chinese-funded acquisitions could trigger more hurdles http://t.co/mIsuZjnU http://t.co/erFX4aVv #arcavir
1 hour ago by V_RaV on twitter
http://t.co/VNaZtseV Rise in Chinese-funded acquisitions could trigger more hurdles: "Cash r... http://t.co/N0gZZEdR http://t.co/wiqY9ktt
1 hour ago by RavtachSolution on twitter
Rise in Chinese-funded acquisitions could trigger more regulatory clearance issues overseas http://t.co/cvLSpTwo #in
1 hour ago by EllyZDNetAsia on twitter
Alibaba seeks $2.3B from shareholders for Yahoo deal. http://t.co/qLRAhRQk
1 hour ago by zdnetasia on twitter
CFOs increasingly involved in IT investment decisions. http://t.co/8QrfwOSb
1 hour ago by zdnetasia on twitter
Official UEFA #EURO2012 app with Orange 2.0 http://t.co/yoAOXTI1 #hotpeopleifollow
1 hour ago by JohnReporter on twitterI reckon your view: "CRM is strategy, not software", if a company replicating the approach uses in ERP implementation into CRM, what they...
1 day ago by wykoong on Gartner: Mobile CRM gives better ROI than socialThis video will teach you about the Excel fill handle but also provide you with a workook to download... http://www.youtube.com/watch?v=...
1 day ago by TradeBrother on A quick fill handle trick for Microsoft Excelwaiting...
3 days ago by eapete on What should count in a company's market value?Boy, you've opened a can of worms now.
Wait for the rants & raves.
I was puzzling before this whether to replicate the success formula we executed for a financial institute, and come out with a standard s...
4 days ago by wykoong on Drop the egos, copy ideas, then innovateKeep up with ZDNet Asia
Facebook 
RSS Feeds 
Newsletters 
Twitter Whitepapers
Downloads
Web Development News
Inside ZDNet Asia
Sponsored
Echelon 2012 - The Awesomer Tech Event in Asia
Echelon 2012 – SEA’s longest running tech startup event goes Awesomer. Catch 50 of Asia’s most promising startups & over 40 international speakers on June 11-12.
Startup Asia Jakarta showcases new product-ready tech startups. Plus: hackathon, exhibition, and speakers. Use promo code CBSi50 for 50% discount.
ZDNet Asia Intelligent Singapore video series
Featuring inteviews with CXOs who define "intelligence" in their markets and reveal how their companies drive business efficiencies through ICT.
