---
title: SAP NetWeaver and the Isolated Incident or Why the JCP works
date: 2006-07-28T01:20:56Z
modified: 2006-07-28T01:20:56Z
permalink: "https://redmonk.com/jgovernor/sap-netweaver-and-the-isolated-incident-or-why-the-jcp-works/"
type: post
status: publish
excerpt: ""
wpid: 670
categories:
  - Uncategorized
timestamp: 2006-07-28T01:20:56Z
tags:
  - Uncategorized
---

Well I guess I needed at least one absurdly dorky post from my two days in Walldorf. This is it.

One of the strengths of SAP’s ABAP programming model is that it supports one process per user. If the server loses a process then only one user is affected.

However, Java is constructed differently, which means that if a process is lost, then many users are affected.

So what could SAP do?

It turns out that there was some talk of new APIs, and possible Java Community Process standardisation through JSR 121 for “isolation”, but in the end, and this is very interesting to my mind, SAP managed to create a structure that would allow the required scale by using the c loader, to enable multiple virtual machine instances without unacceptable management overhead. Because the server is under management and NetWeaver knows exactly what is on every instance, and each instance is the same, there is no need to reload all the class libraries for each one. Load them into memory and share across every instance. This is not a single point of failure though, because each instance is self-contained.

It’s interesting to note that the associated NetWeaver app server scale improvements only work if JEE best practice is followed. That is, if the developer doesn’t use best practice, with absolute separation between application and management classes, then the application won’t perform any better. In other words unless you use JEE best practice the server advantages don’t work. You could practically use it as part of the certification suite. 😉

Why is this so interesting? After two years talking through approaches on the JCP – which might have led to new APIs and so on – which \*might\* have been standardised through the java community process, SAP took an approach that works with existing APIs and so on. A nabob of negativism might say this showed the JCP doesn’t work. I think the opposite is true. The fact is SAP got what it wanted, it has a differentiated scalable JEE implementation, with no need for proprietary hooks. Nice.

Hopefully I can get a chance to talk to some production customers when product ships in six months or so. Performance matters. But then, so does portabilty.

Tags: [SAP](http://technorati.com/tag/SAP), [Netweaver](http://technorati.com/tag/Netweaver), [JCP](http://technorati.com/tag/JCP), [dork](http://technorati.com/tag/dork), [J2EE](http://technorati.com/tag/J2EE), [JEE](http://technorati.com/tag/JEE), [Walldorf](http://technorati.com/tag/Walldorf), [isolates](http://technorati.com/tag/isolates), [Java](http://technorati.com/tag/Java), [scalability](http://technorati.com/tag/scalability), [JSR 121](http://technorati.com/tag/JSR+121), [Sun](http://technorati.com/tag/Sun), [ABAP](http://technorati.com/tag/ABAP)