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 re-architecture.

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

[an error occurred while processing this directive]

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.

Would you attempt the transition to .Net? TalkBack below or e-mail us.
Builder.com, created by developers for developers, brings you fresh, real-world perspective on programming, architecture, and management.
Join the most insightful software development site on the Web!

Previous page |   1 2 3

[an error occurred while processing this directive]

[an error occurred while processing this directive]