Why migrate from J2EE 6.20 to 6.40?

Of course, SAP could just order its own employees to migrate SAP apps to the latest and greatest no matter what. But for developers outside of SAP that’s no answer – and even for SAP applications, it is clearly better to understand how 6.40 can help than just to migrate because 6.20 is being replaced with a newer release in SAP’s marketing slides.

This blog doesn’t focus so much on new features in the J2EE engine. If you have been waiting for these, for example for J2EE 1.3 support, it’s obvious that you want to go to 6.40 as soon as possible. But what if all the functionality you need has already been implemented nicely on 6.20? Here are some key considerations that might help you plan.

Yes, there is a difference between applications that are meant to be used by many customers as a standard product, and customer specific developments that will only run in one particular environment. But in my opinion, the key benefits of J2EE 6.40 for both types of existing applications are the following.

1. Improved stability and scalability

Behind the scenes of the J2EE APIs large parts of the engine architecture and implementation have been reworked to improve the scalability and stability of the engine. And first tests (for example, of the EP 6.0 in a lab stress test, or of a real life customer application in realistic stress tests before the go live) clearly indicate that J2EE 6.40 scales better and is more robust than 6.20 with many users and under high load.

The migration effort to profit from this is very limited. Yes, the 6.40 engine implements J2EE 1.3 instead of 1.2, but the J2EE APIs have mostly been extended, so everything that worked on 6.20 should continue to work on 6.40 (provided you have worked with the official J2EE APIs only).

The 6.40 engine also runs on JDK 1.4 instead of 1.3, so if your code happens to depend on some things that were changed incompatibly between these JDK releases (see Sun’s documentation) you may have to make corrections. From what I’ve seen so far the only area that needs major efforts here are Swing UIs, the other incompatibilities are rather minor, rarely used details.

Of course, all this is only an issue if your application’s user load profile does at least sometimes make the 6.20 engine hit its limits, so it will only be worth the effort in special cases.

2. Platform independence, especially via Open SQL

One of the reasons why J2EE apps become platform dependent despite Java’s “Write once, run everywhere” promises is that you start storing persistent data in some database and use database specific SQL code, JDBC drivers etc.

With the Open SQL infrastructure of the 6.40 engine you can change that – just like in ABAP, Open SQL gives you a platform independent set of SQL statements, and a database interface that hides all DB-specific details from the application.

You even get an SQL trace thrown in (try calling the URL http://[host]:[J2EE port]/SQLTrace and login with the engine’s Administrator user).

To profit from this, you do have to change your application by replacing the DB specific JDBC and SQL code with Open SQL. Again, this is only an issue if you do want to make your application platform independent – if you are happy to program and run on one particular DB only, Open SQL is not a top priority.

3. Supportability

The 6.40 engine comes with additional features that make it easier for the engine administrator (and SAP support) to monitor and troubleshoot the engine. Some of these features (heartbeat and other monitoring data that can be fed into CCMS) only need to be configured, others (for example, centralized logging and tracing using a new SAP logging&tracing API, distributed statistical records for analysis of performance problems) require that applications are instrumented to use the new APIs.

This is definitely worth a look for all applications bar the smallest ones. In fact, some of these supportability features have even been downported to 6.20, so you may want to look at implementing these features in any case.