ZDNet UK

CNET NETWORKS UK BUSINESS SITES:
atlarge.com
BNET UK
silicon.com
SmartPlanet.com
ZDNet.co.uk

ZDNet.co.uk - Winner of Best Business Website 2007

You are here: ZDNet.co.uk > News > Software

Office applications Toolkit

Migrating to .Net?

Godfrey Baker Tech Republic

Published: 11 Sep 2002 09:44 BST

4. No support for Container Managed Persistence

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 organisation 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.

Have your say instantly in the
Tech Update forum.

Find out what's where in the new Tech Update with our
Guided Tour.

Let the editors know what you think in the
Mailroom.

1 2

Did you find this article useful?
110 out of 206 people found this useful

More In Office applications

Featured Talkback

Why do so many (virtually all) software packages think that they are so important that they have to be started automatically every time the computer boots? What is the largest number of "speed access", "update check", "camera download" and whatever other background programs you have ever seen running? Of those, how many did you really need?