Kiss of Death for Web Dynpro Java The Follow-Up Questions
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 Geek’s 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.
BPM interoperability
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?)
Conclusion
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” (Geek’s 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.
on the BPM part:
- In CE 7.2, you can also use VC and Adobe Offline Forms with BPM
- Using the Task API available with CE 7.3, you can also integrate the other UI technologies you mentioned such as JSF or JSP. Granted, it will not be as simple and straightforward as with WD or VC, but nevertheless possible.
Regards,
Christian
Thank you for pointing that out. I wanted to leave out all the UI technologies that you could only integrate with glue code, such as VC and Adobe Interactive Forms in CE 7.1.1, but I forgot that these have become straightforward to integrate in CE 7.2.
Cheers,
Thorsten
If we're talking about model-driven-development then there is gread gap in this new world. On the other hand I hope that the new APIs that are included in CE 7.3 will give us more ways to work with alternative UIs. But anyway we will miss the generator for fast ui development from inside BPM-tools.
Thomas
I totally agree that fast UI development/generation is very important for BPM from a tooling perspective.
As with the WD toolset itself, the generation functionality in BPM will stay and can continue to be used.
In addition, BPM may also offer the option to generate for example JSF UIs in the future.
Regards,
Christian
I also have mixed feelings about the "kiss of death" as you describe it so nicely. Like you, I have also done quite some development in Java webdynpro and really don't like to see these investments go haywire.
On one hand I count my blessings that SAP is not dropping it entirely and still keeps on supporting it. On the other hand, I would still like new things to be happening at the WDJ side of the house too. It would be great to see e.g. floorplan manager, ALV and POWL appear on he Java stack as well, but have the feeling that it didn't appear, because SAP has cut-down resources quite some time ago already.
The current position of SAP feels a bit like a stab in the back, as I can still remember the vivid speeches in which SAP explained that for once customers had a choice on whether they would use WDJ or WDA and that both technologies were future-proof. Most folks that I spoke to at that time, were in the opinion that it would be inevidable that SAP would drop one of the technologies at a certain point. To them it didn't make sense that SAP would have two plaforms to achieve the same goal (to build Webdynpro application), and would keep on investing in both of them. It seems that their fears have become reality.
At that time, it was unfortunately impossible to guess which of the two technologies would be the one to bet on, and I'm afraid that a lot of folks betted wrong. For them it means that now SAP doesn't innovate on the WDJ platform anymore, innovation also won't be as easy in their applications as well. This might only leave them one option: write-off the investment in those applications and start over either in WDA or HTML5 (Phoenix).
As I mentioned before in an earlier chat we had, I do beg to differ about the current WDJ stability and scalability. Besides the hospital with hundreds of concurrent users that I was talking about, I have also seens WDJ perform in a Dutch utilities company with thousands of users running WDJ concurrently. I do believe that esp. with the improvements that I've seen in the J2EE engine in 7.2, the platform is rock-solid.
Regards,
Jan
PS.: The Petó de la mort picture is a very nice choice. Although it maybe a bit too dramatic for this topic, I do understand the symbolism that you've tried to put into your message with it. Oh, and Azathoth is probably a cust-cutting finance guy 😉
Thank you for responding to this! I'm all with you: The investments customers have made do not lose their value immediately, but it will go down over time as ABAP and Java UIs drift apart and the look and feel loses consistency.
Also, please not that I am with you regarding the current stability and scalability of Web Dynpro - I make it a point that this is probably the area where SAP has the best answers regarding the maturity of the platform.
Cheers,
Thorsten
1. Very good blog post. Picture a bit melodramatic, but it does the work 🙂
2. I disagree with the "Very discreetly" at the beginning of the post. Our messaging around Web Dynpro Java & Visual Composer has been in all the relevant sessions - CD201, PMC161, CD250, CD256 (just to name the ones which I have been doing). This messaging I think is very clear and the fact that we did the podcast / interview with John as well as the slides which we've shown as anything but "Discreet".
3. Furthermore - The indication towards this direction has also been evident since last TechEd. If you go back to the UP104 session (I think it was recorded) where we already stated clearly that the we have completed the VC roadmap, etc.
4. Last but not least - Regarding the decision itself. This is probably a longer discussion, but I would agree to one point - we currently have no replacement to the capabilities that WDJ + VC offer. The new direction we are investing in (e.g. the HTML5 Lightweight UIs) is seen as complementary and not a replacement.
Thanks for commenting here. It's good to see that my blog - perhaps thanks to the admittedly melodramatic title 🙂 - draws some attention to a discussion that might have otherwise gone unnoticed by many in the general buzz of SAP TechEd.
I know from your continued presence at SAP TechEd and from your involvement with the Mentors as well as Karin Tillotson and the ASUG Influence Council that you're always open to discussing stuff with the community.
So let's find a modus for the discussion of Web Dynpro Java, the new direction (HTML5 et. al.) and how the two can complement each other. It will be my pleasure if I can support the process by bringing in my experience and perspective from working on both an ISV/partner-created industry solution and custom development projects for end customers.
Cheers,
Thorsten
I would be happy to engage in more lengthy discussion, but here is what 'bugs' me.
[Remove SAP employee badge, enter Yariv the developer]
I think that as technology geeks we tend to over-dramatize changes where some cold-headedness (is that even a word?) would serve better.
The fact that SAP is investing more into different directions and less into Web Dynpro Java does not equate "Web Dynpro Java is Dead". Sorry. only in a hyper world with an ADD induced attention span does this hold true. Once SAP releases NW 7.3 there will be almost a *decade* in which you can develop WDJ UIs with ease. So for a developer starting a Java based project today reading this post and asking himself what to use? I would for sure recommend WDJ.
It seems like that favorite past time of geeks is to say "X is dead". I know its fun. However - I just downloaded the other day the new Evernote 4 and its written in C++ and not WPF/.Net. As a C++ boy myself (Real programmers manage their own address space) I have been told that C++ is dead five years ago. So?
I think the discussion around the future direction of where WDJ / VC should go is an important one. I just wish it would take place in a bit less dramatic sense of urgency as if the sky is falling.
[Back to being an SAP employee]
I understand and agree with most of what you say. Maybe it' an intercultural thing: it appears that I didn't get an important aspect of my message across. Like you, it annoys me to no end when people overreact by saying "X is dead" at the slightest sign of something else showing up on the horizon - for example, last year or so an analyst wrote "SOA is dead" and that headline got passed around IT departments without much thought or reflection. I tried not to make myself guilty of the same mistake and write a nuanced blog that doesn't omit the important facts:
* SAP will keep maintaining Web Dynpro Java
* It is indeed mature in many important aspects, so no reason to call it a stillbirth or anything along those lines.
On the other hand, I wanted (and still want) to share my sense of alarmment about one fact that is also important.
* Web Dynpro Java is a key component in SAP's UI and technology strategy that cannot be meaningfully replaced by something else anytime soon.
* The day you stop innovating in a particular technology, it begins to wither away.
This is why I chose the image of a kiss of death, which for me symbolized the beginning of a slow and gentle dying, as opposed to, say, a bullet in the head.
If SAP stops innovating in Web Dynpro Java it won't hurt in the beginning, but eventually Web Dynpro Java will wither away.
One way to prevent that would be a serious commitment by SAP not only to fix bugs but keep the feature list and scope frozen at the 2010 level but to allow Web Dynpro Java to at least stay in the race with Web Dynpro ABAP, even if it may not be SAP's only or favourite tool in the Java world.
I could write so much more, but I hope this time I got a key part of the message across better. 🙂
Cheers,
Thorsten
I do know that we all could endless talk about this topic.. There are so many things behind this decision made by SAP, but I want to move a bit forward: "how much effort will I need to adapt to this new reality?" - or even the company I work for.. It looks I have a new opportunity in hands, which is learning WDA - it can't be that bad, I'm a developer "first", I won't TAG myself with just language A or B.. (thou we may specialize in one!)
Going down the rabbit hole.. I think ABAP and WDA can really "benefit" if another group (and I would say JAVA now) comes into play: "there is a lot to share" - I will keep trying to see this change not as negative as it looks like..
But again, I'm very fresh in SAP world, so my perceptions may be wrong..
Cheers,
Daniel
I am a bit surprised and disappointed at the trends that are going around SAP's BPM and its connectivity with UI technologies.
I am surprised because, SAP almost steps over its promised strategies on WDJ to WDA, as it is the WDJ development investments are already heavy, ask the customers.
As I can see that WDA strategy is infact an overly unesessary step, as there is a seamless integration between WDJ and RFC and all the benifits can be fetched by WDJ from the RFC integrations without under mining the proximity of ABAP with the enterprise processes.
I am dissappointed because UI technologies such as JFaces, JSPs and Servlet are so widely used and implemented even by WDJ and WDA.
So, why exclude them ? I see no point on this.
I hope that SAP would like to rethink on these aspects of and come out with a more open strategy
that would benifit all actors in this play.
Best regards,
Ajeet Phadnis
My personal past experience was using out of the box WDJ for the travel solution; it was troublesome, and tough for a development team that only new WD for ABAP.
I remember your saying the "kiss of death" discussions at TechED last week.
Azathoth? I am not well-versed.
Great to see you at SAP TechED.
Tammy
Here's my limited response. I come from a mid-size company. We have no desire to support multiple languages. It just is not cost effective. (That being said we do support some different technologies. Just not WDJ.) We only support minimal JAVA in our PI environment.
So - I can understand moving forward with WDA, and supporting / maintaining WDJ. We had to pick one, and with our experts in ABAP, not JAVA, we choose to go with WDA. We did look at WDJ as it had some nice features. IE use on a mobile device
SAP is “old”. So it makes sense that they are starting to improve their languages / features. It may be too much to ask to have them improve everything at once. So a decision is made. It makes sense that they would pick WDA, as ABAP is the "SAP Language". However, it sounds like they are only picking WDJ for limited upgrades. I know I’m still uncertain about workflow – we do have that one. (Oracle adds a little more weight into the decision as JAVA is no longer as “open” as before.)
And I agree – no programming language is “dead”. COBOL, FORTRAN, PL1, RPG… Need I say more?
Nice meeting you!
Michelle
Let me try to recap from my perspective: several sessions of SAP TechEd 2010 talked about the maturity and future of VC and WD4J. Based on this info, SAP Mentor Karin Tillotson and Yariv Zur - as ASUG UI Influencer Council rep and SAP UI Strategist - were interviewed by Jon Reed (JonERP.com).
Thorsten just picked up the topic and drew his conclusions in a logical manner.
The ecosystem/community has been wondering about the SAP UI strategy for months now and the question popped up more than once...
So, if you ask me, it boils down to the question whether or not SAP did a good job on the public communication on this topic prior or during TechEd?
What about the business scenario concerning creating a web interface on top of legacy systems, e.g. mainframe?!? Certainly you do not think that WDA should be used for this? In addition, precisely this would be one of the key strengths of BPM, so its very disappointing that you choose to discontinue WDJ...............