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.
In particular, those projects that started out small (say, with a quick and dirty JDBC app using whatever database the developer happened to know and have handy) and then grew into a bigger applications with more widespread use than originally anticipated. And when you do find an application outgrowing its quick-and-dirty origins, I believe it is better to port it to Open SQL once, than to port it from one JDBC platform the the next, and then have to deal with it again as the DB platform is upgraded or changed again later.
for customers as end user you are true. But there are also partners and software houses who work under same conditions as we do: they have to deliver on their customers platforms.
On the other issues let me give you a very clear statement: I personally promise you a product that is as scalable as the well known ABAP server and as stable as a Java Virtual Machine can get. And the year after we will go even beyound that.
Promised.
I bet my personal reputation on this.
So, when does 640 become a supported platform? Any talk of migration is pointless until this is known – no enterprise will run on unsupported software.
Growing our bananas in customers garden is not quite popular these days and guess what SAP’s point of view was about this for a long time.
Why then do we talk about this here?
Large projects which will start in 2004 have to be planned today. We want to make sure they consider our new kid on the block for this point in time.
It will be very interested to find more info about performance of the WAS 6.4, especially in a cluster setup – we are using BEA Weblogic today, version 6.1 and 7.1.
And performance, runtime as well as management is a very important issue for us.
B’regards
Jens Jakob
informed of the release yet. It is available now?