At SAP TechED 2010, SAP announced very discreetly that Web Dynpro Java had reached the state of maturity. Video Blog: The Future of SAP Java UIs - Breaking News and Customer Dialogue from SAP TechEd Las Vegas In the SAP software lifecycle, this means that they will keep responding to OSS messages and fixing bugs, but will stop introducing new features and withdraw all development resources except the minimum needed for bugfixing. (I jokingly call this type of announcement Geeks Dictionary: What is the Walldorf Kiss of Death? because it sounds so nice and gentle when executives say things like “Web Dynpro Java will stay with us for a looong time.")
Fig. 1: Kiss of Death for Web Dynpro Java
As a keen user of Web Dynpro Java, I was hit hard by this announcement. It didn’t come completely out of the blue, though, because the speed of innovation had been very slow lately, indicating that SAP had already retracted many development resources from the framework. Compare that to how Web Dynpro ABAP has been flourishing, which saw a rush of new features and integrations into other frameworks in recent releases.
However, at this moment I do not understand the step to discontinue Web Dynpro Java because it raises a number of questions I don’t see the answer to yet. Let’s look at them one by one.
Before release NetWeaver 7.3. (which is not available yet), Web Dynpro Java was the only (!) user interface technology you could use in BPM processes. It wasn’t and still isn’t possible to use any non-SAP-proprietary UI technology such as plain HTML, JSF, JSP, or any of the others, even though all of these run on the same server and are supported by the NetWeaver Developer Studio. You had to use Web Dynpro Java. Starting with NetWeaver 7.3, we will be able to use Web Dynpro ABAP user interfaces in BPM processes.
Consistent user experience
NetWeaver Java, CE, and BPM run mostly at customers who run SAP’s ABAP-based business applications also. The idea is that with your Java-based CE/BPM system, you create an outer ring around the ABAP systems with their business applications. Processes that change frequently should have a smaller footprint in the ABAP system, thus upsetting and disrupting it less. You achieve this by building those quickly-changing processes in the CE/BPM systems and let them consume web (or other) services exposed by the business application. So much for the theory.
In practice, frequently the UIs in the ABAP system will be so rich and complex that it makes no sense to rebuild them in Java because it will be too expensive or futile because the screen is already quickly-changing in the ABAP system. So frequently, the user experience in an ABAP – Java landscape will involve jumping from ABAP to Java screens and vice versa. Web Dynpro was originally designed to look identical in ABAP and Java so that the user experience would be consistent. The idea was to seamlessly connect ABAP and Java screens so that the user wouldn’t even notice that she had navigated to a screen in an entirely different technological world.
This seamlessness might be gone very soon if Web Dynpro Java remains frozen in its current (NW 7.3) state and Web Dynpro ABAP keeps evolving at even a fracture of its current pace. It is already quite easy to tell the two apart, but if Web Dynpro ABAP keeps evolving and the look and feel drifts more and more apart, we won’t be able to create a seamless user experience across Java and ABAP systems anymore.
Technical, non-functional maturity
Software takes a long time to mature until it is really robust, scalable, and rock-steady. At the time it appears to be ready for shipment to the developer, it is still full of bugs and unfinished corners. When it looks ready to product management and they ship it to customers, it is often now robust and scalable. And long after mass adoption, customers still run into scalability issues and cause sometimes massive architectural changes that are needed to resolve the issue.
As an example, think about how old the NetWeaver ABAP server and the Remote Function Call (RFC) are. Just a few years ago, they had to introduce an entirely new type of RFC call, the bgRFC, to enable business scenarios that would otherwise be impossible to implement. Like a true master never stops being a student, a true platform never reaches maturity.
I wonder if Web Dynpro Java has already had the chance to technically mature to the extent that is required for serious enterprise use:
- scale well with thousands of users
- scale well in growing server clusters
- highly extensible, allow software vendors to place enhancement points and customers to create enhancements
- highly personalizable by the end user
The scalability question is probably the one for which SAP has the best answers. I know of live installations where hundreds of users run Web Dynpro Java at the same time (out of thousands of users), generating significant server load, and the system handles it well. But when it comes to extensibility and personalization, I think Web Dynpro Java has (or had) a long way to go.
Speaking with people in the field and listening to Karin in Jon's video, I get the impression that more customers and users will go live with Web Dynpro Java in the near future than have gone in the past. If SAP freezes Web Dynpro Java now, all the experiences, problems, ideas, and feature requests resulting from these project will never lead to the platform getting better.
The Mobility Question
Of the Web Dynpro family, only Web Dynpro Java is mobile-enabled. It has got special UI elements suited for mobile use (such as RFID and barcode scanning) and the rendering is optimized for some mobile devices such as the BlackBerry.
Web Dynpro ABAP, on the other hand, runs on some mobile devices because it renders for the Safari browser, but because it is released for Safari on the Mac only, you’re technically without OSS support if you do that. Proceed at your own risk here.
I know that SAP is currently presenting Sybase as the answer to all questions mobile, but that is quite overweight for quickly-implemented, always-connected scenarios. SAP just gave their best answer to those questions the kiss of death.
The Rightful Successor
The people at SAP would probably agree that you cannot stand still in the IT industry. Requirements change all the time, and SAP needs a living UI technology with good adoption they can enhance as required in order to stay in the game.
Being frozen in maintenance mode, Web Dynpro Java will not be able to take that role – it will start to look outdated once the first one or two waves of requirements have gone over it, leaving it unchanged. (If it hasn’t already happened.)
So where in the SAP user interface world will the change happen? Firstly, SAP will concentrate more on Web Dynpro ABAP in the future. Secondly, SAP needs an answer for user interfaces that run locally on the CE server. It appears that a combination of HTML5 and JSF will become their favourite Java-based UI technology, but we will see. They will have to do their homework first:
- a BPM adapter for JSF so you can use JSF screens in BPM processes
- get that JSF Web Dynpro bridge UI element to work or provide some other means of back and forth navigation to and from Web Dynpro
- a HTML5 rendering engine on the server
- libraries for Web Dynpro like UI elements to use in HTML5/JSF projects for a consistent look and feel
- libraries for lightweight mobile applications
- design-time integration into the NetWeaver Developer Studio
- support for service consumption using server-specific features such as JCo connection pooling, web service groups, destinations
- maybe better JSF-specific integration with the SAP component model (JSF plugs in DC public parts?)
Listening to Jon's podcast, I can partly understand SAP’s decision to put Web Dynpro Java in maintenance mode, but it leaves many questions open because especially in these times of rapidly-changing technologies, business requirements, and technologically heterogenous but closely-knit landscapes, Web Dynpro Java offers key strengths that I don’t see anywhere else in this field in this combination:
- offers a consistent user experience across technology platforms (ABAP, Java, mobile)
- limited set of UI controls, building-block principle spares developers from using HTML and accidentally deviating from the standardized design
- model-driven rendering approach allows for device-independent development and presentation (browser, mobile, NetWeaver Business Client)
- completely model-driven design in Visual Composer
- renders as Flash
- model-driven programming model allows for rapid development and refactoring of applications with less coding that usual
- integration with NetWeaver-specific server features such as connection pooling, RFC consumptions, service groups
I’m not idealizing Web Dynpro Java and I’m not saying that there isn’t a long list of weaknesses; but I would like to see a stronger commitment on SAP's side to incorporate the feedback from customers going live in 2010 and 2011 into Web Dynpro, and a long-term commitment to the UI consistency between Web Dynpro ABAP and Java. Providing that will require more effort from SAP than they usually afford when a component is in maintenance mode.
Let's hope that this "Walldorf Kiss of Death" (Geeks Dictionary: What is the Walldorf Kiss of Death?) will leave some lifeblood in Web Dynpro Java, so that the words of the mad Arab scholar Abdul Alhazred shall apply, immortalized in the Necronomicon and relayed to us by H.P. Lovecraft:
That is not dead which can eternal lie.
And with strange aeons even death may die.