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, Netweaver, JCP, dork, J2EE, JEE, Walldorf, isolates, Java, scalability, JSR 121, Sun, ABAP
Chui says:
July 28, 2006 at 12:15 am
Sometimes, the problem with committees is that there is an urge to create/reinvent something “new” and “innovative”.
It is way easier to adapt an existing solution that works, to J2EE. The multiple process model has been well proven by Erlang OTP, which has achieved high levels of reliability that is required in telephony platforms. If you are interested in the area, have a look at “Crash Only software”.
James Governor says:
July 28, 2006 at 9:44 am
thanks chui -nice tip. crash only huh – will do.
Dan Roberts says:
August 1, 2006 at 10:24 am
On the topic of portability and openness though in a standard, at some point I think we need to do a better job of admitting to and understanding the business cost of switching vs. the technical cost of porting when discussing the value of portability in a standard or language.
How many companies really move their apps from Sun’s, SAP’s, IBM’s, Oracle’s, BEA’s, JBoss, etc.’s Java EE implementation to someone else’s?
For new apps you might choose a new platform, but migrations really are the exception to the rule. The business hurdles (licensing lock-in, risk, compatibility with other 3rd party/custom software that your app uses, enough value to the business to bother, etc.) often far exceed even significant technical porting costs, let alone the relatively minor ones exhibited on the Java EE platform.
The risk averse IT buyer, when making a decision about a technology partner, wants to know they’ll have choice down the road if they find a cheaper price, or if the corporate winds shift they can move to a new partner, or that there’s a broad ecosystem of support available if your vendor of choice fails. So there IS significant value to having portability and maintaining it, but it’s not in the cost savings for simplifying the technical hurdle of migration (don’t tell you’re Engineers that…), it’s in the value of assuaging the customer concerns during the initial discussion and sale.
Proprietary is one of the worse labels to ever have applied to your technology, product or company. Think about how Sun has been viewed as selling ‘proprietary’ hardware due to SPARC. Tell me again why Intel’s or IBM’s chips are not ‘proprietary’? In Intel’s case maybe de facto standard, but none were any different than SPARC in it’s design or control. So, enter Sun’s x64 commodity hardware message with AMD, along with open sourcing our UltraSPARC T1 chip (ask the Intel or IBM guys when they’ll open source their chipsets!), and now we have rising server revenue and sales to new customers that view the boxes for what they are, screaming fast and no longer proprietary. Oh, and these sales are dragging in SPARC hardware sales so the goodness is even spilling over where no changes have really been made.
Compatibility, standards, and openness are all keys to unlocking doors and having conversations. Your blogs are a great example of this very tactic at work and they are working as you’ve intended. As are the free/open source tactics we’ve been driving which hit 60% new customers vs. existing ones for hardware, and get me into all sorts of interesting business conversations on the software side, driven by the massive distribution. Get the risk averse to not worry about that first hit, they’ll open their doors and let you in and then find you’re there to stay, even if you are the portable, open solution.
Ahh the viral business model… which will never be ‘dead’ because a virus is not technically alive either, generally a known requirement for death (http://en.wikipedia.org/wiki/Virus#Lifeform_debate).
Jeremiah Stone says:
August 1, 2006 at 10:25 am
This points to something you should understand about SAP culture – we are definitely a “German consensus” driven organization. The two years of back and forth on the topic, ending in a decision to innovate the way we want while remianing true to the Standard is pretty typical around here. We like to explore every possible option and discuss ad nauseam, but almost always come down on the side of conforming to Standards. This is very expensive internally, but usually results in, as you would put it, goodness. This tends to result in radical new ideas which are gradually workshopped to the point of Market/customer acceptance. It does, however, slow down our time to market. Something we could do better here perhaps is embrace more public betas.
Where we are admittedly weak, from my point of view, despite SDN, is product development and acceptance via conversation with the Market. The ClueTrain stops here regularly, and we are trying to get on, but at the end of the day we are still a huge software house with all that implies. The new Business Process Expert initiative (http://www.sdn.sap.com/irj/sdn/developerareas/bpx) as well as the work around Enterprise SOA are exciting steps in this direction, but we still have a long way to go.