Skip to Content

Is Web Dynpro for Java dead? Good question or an irrelevant one. Well, I have been inspired to blog about this after I came across two forum queries (Is Web Dynpro for JAVA DEAD? and Re: Is Java Web Dynpro going to be scrapped in future? discussing the same issue) both appearing just a couple of days apart from each other. For someone who has been involved with Web Dynpro Java for more than half of his career, it was rather painful image

Some have reached to this conclusion because SAP has either started migrating most of its applications or has already migrated a few of them from Web Dynpro Java to Web Dynpro ABAP. Apparently, nobody has yet tried to figure out the reasons behind the step and I am also not the right person to comment on that. The decision can surely be supported by a more plausible explanation. But I am sure it was not done to “KILL” Web Dynpro for Java!! From what I have understood and from whatever I have read about it, this migration was done as part of a complete redesign of the system and considering the advantages that Web Dynpro ABAP has over Web Dynpro Java and as far as I am concerned, this decision makes complete technology and business sense. Wouldn’t you choose the best technology to build your application with?

 

Some have reached to this conclusion based on rumors; something which may have started as a mere coffee corner discussion has just been blown out of proportion. I guess we cannot help here much, except to request everybody to get their facts right and if required, clarified from appropriate sources. I suggest everyone go through Is Web Dynpro for JAVA DEAD? reply by Chris Whealy, an SAP veteran and a Web Dynpro Java Expert. I personally loved his “Cat is a dog” scenario image

Moreover, as Jochen Guertler, another SAP veteran puts across clearly in his reply to the same forum thread, “Web Dynpro for Java is still the first option to build java based UIs within the SAP eco-system”.

 

Some more have apprehensions about Web Dynpro Java’s future after Sun Microsystems was acquired by Oracle. I am sure “Continued Investment” in Java will benefit Oracle and it is intelligent enough to understand that. I guess this acquisition by Oracle poses more threat to Microsoft rather than the Java community. Hence, if the future of Web Dynpro Java depends upon what Oracle does with Java, then it is not only true for Web Dynpro Java but an entire “Composition Environment” that SAP ships based on Java. So is true for a lot of other vendors with a lot of products based on Java.

At the end of the day, let’s face the fact that developing in Web Dynpro Java is much more user-friendly than doing the same in Web Dynpro ABAP. Personally, I wouldn’t want it to die as long as I have to develop SAP UIs. An ABAP Editor on eclipse might still go a long way in making my life easier, but for the time being Web Dynpro for Java is my first choice for developing user interfaces within the SAP world.

What does the future hold…..

SAP has recently released Composition Environment 7.2 and along with it has been shipped a number of new features and quite a few enhancements that make application development using Web Dynpro for Java so much more pleasant and user friendly. I suggest users have a look at this demo kit by Jochen Guertler to know more about these features. I don’t think SAP would approve of such an investment into a technology that is dead.

Apart from the above arguments, there is also the advent of newer UI technologies such as Adobe Flex, Microsoft Silverlight and HTML5. Obviously and understandably, these technologies pose serious threats to the existence of Web Dynpro. But then, this is true for both Web Dynpro ABAP as well as Web Dynpro Java. And if I may add, Web Dynpro has a very robust programming model to support the UI rendering which could be the added advantage. Yet I do agree that, with Javascript becoming the de-facto programming language of the future, it would be great if we could have more support for scripting in Web Dynpro in general and Web Dynpro Java in particular.

 

If “good-looking” and responsive UI is what users are looking for, Web Dynpro for Java already provides Flex and Silverlight integration capabilities apart from JSF and AJAX support. Check out this link for more details. Let me also add that I am not trying to do a comparative study between the various UI technologies here. I am just trying to find a place for Web Dynpro amongst them all. And this is where, the customers/users of Web Dynpro for Java will have to come in. Their feedback is very important for the improvement of the technology, both in terms of integration capabilities as well as feature enrichment. Hope they listen to us as much as we do to them !!

Moreover, I assume there are discussions going on regarding the pros and cons of making the technology Web Dynpro for Open Source. Opening up the technology may not be an easy thing to do with the programming model being shared between WD ABAP and WD Java apart from controlling the runtime aspects of it. Just opening up the tool would hardly help. This concept will definitely take some time to mature, but holds a great deal of potential.

 

I guess I have made enough and more arguments in trying to justify the invalidity of the subject line. I could go on further but the arguments trying to justify the validity of the subject line could also be manifold, but that stands true for any technology that’s as old as Web Dynpro. Well, let me wrap up with what Chris describes Web Dynpro Java as i.e. a mature and stable technology and if I may optimistically add, more acceptable.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Jan Penninkhof
    In all SAP’s previous messages, they have been consistently been saying that ABAP and Java webdynpro will coexist and that they will leave it up to the customer to choose his own technology for custom development. Having gained some experience with both ABAP and Java, it is getting clearer and clearer when to choose which. I really like the fact that the choice is up and to me and is not predetermined by SAP (for a change 😉 and would like this to stay this way.

    I trust Chris Whealy’s comment on Is Web Dynpro for JAVA DEAD? that Java isn’t dead. If anyone knows best what the future of Java webdynpro holds, it’s probably Chris.

    (0) 
  2. Jan Galinski
    I am under the impression, that SAP tried to make a great leap towards Java with the NetWeaver / Platform, the Portal and exchanging SAP GUI with Java Portal Applications (WD4J).

    But when customers noticed, that they would have to build up new skills, run new systems, hire new personal or consultants, it was hard to explain to them, why they could not just go on with the ABAP suite they got used to.

    So in my opinion the question is not “is web dynpro dead”, its “how do you sell it”.

    (0) 
    1. Pradyut Sarma Post author
      Hi Jan Galinski,

      Web Dynpro Java was created to cater to those customers who wanted to develop web dynpro applications on Java. I would expect customers to first decide whether they would want to use Web Dynpro Java or ABAP for development and then hire the necessary consultants, developers etc. The decision to choose between Web Dynpro Java or ABAP should be made after judging the merits/demerits provided by both along with the infrastructure available. Web Dynpro java is not a replacement for the ABAP suite but a similar tool based on Java, complimenting the one on ABAP.

      Best Regards,
      Pradyut.

      (0) 
      1. Markus Doehr
        I have to disagree.

        Many (smaller?) customers don’t develop much but just use the functionality that is there. When we upgraded from 4.7 to ERP 6.0 we suddenly found out that we had to implement a whole bunch of new systems and technologies just to run the ESS/MSS which was/is now based on Java.

        If we would have wanted to implement all the extended functionality, that was developed already and present under 4.7 in classical ABAP, we would have had to recode everything in Java under a complete new environment – just to do the same thing as we did before.

        I, as an administrator, am utterly happy, that most of the ESS/MSS functionality is “backported” to ABAP so we can use our infrastructure, our change management etc. as we did before without having to implement a whole zoo of systems and learn new environments which we basically don’t want.

        Your statement may be true for the big players but is wrong for the average 4.7-to-upgrade-customer base, the technology used is imposed by the application you want to run, not by what the customer wants.

        (0) 
        1. Pradyut Sarma Post author
          Hi Markus,

          That’s exactly what I meant. When you decide to adopt either WD Java or ABAP, you check whether the technology, either of them works for you(i.e. the customer) and then go ahead.
          Upgrade scenarios like the one mentioned in your case can be tricky, especially when there is existing infrastructure and expertise already available.

          Best Regards,
          Pradyut.

          (0) 
      2. Jan Galinski
        I agree with you. But I think you didn’t get my point. SAP tried to push WD4J by migrating Software towards Portal Applications.
        If you wanted to use ESS/MSS, you were forced to set up at least dual stack app servers and a portal.

        Customers rightfully complained about this so now pushing of WD4J is slowed or even halted.

        That has nothing to do with “which tool will I use for my next custom project”, its more of a political topic.

        I myself am a big fan of WD4J, once you got a hold of it, it has many really cool solutions for common Java GUI and Java Enterprise challenges.
        The context as a Model container in the MVC, the usage of View-Layout and View-Controller as View and the strict separation of Controller concerns is still a great approach.
        Using Development Components you get an OSGI like behaviour out of the box and building SOA systems is enhanced rapidly.

        So I would like to see WD4J develop and maybe some day leave the SAP-only universe and become a competitor for JSF, wicket, and such …

        But the question remains: If you are SAP, and your customers tell you: we dont want to get into java, how do you sell it?

        Hope things are getting clearer now.

        Jan

        (0) 
  3. Gilles Godart
    My opinion is Web Dynpro Java is a front end technology, it’s the same as Web Dynpro Abap, a non flexible UI, not really RIA and Hard to Design.
    SAP needs at meast a real RIA technology(Flex, Silverlight and HTML5) and these technologies will replace Web Dynpro Java.
    In my opinion SAP has stopped improving WD Java to invest in new technologies like real RIA.
    (0) 
    1. Pradyut Sarma Post author
      Hi Godart,

      I agree Web Dynpro does not actually support RIA development. But it does offer a number of integration capabilities with RIA technologies such as flex and silverlight. SAP’s investment into RIA technologies will definitely increase as we go ahead.

      Best Regards,
      Pradyut.

      (0) 
  4. John Moy
    Hi Pradyut, thanks for an interesting post.  From my perspective, I am wondering whether the question is not about what the future is for Web Dynpro Java, but what the future is generally for Web Dynpro.  After all, one of the primary benefits of Web Dynpro was to ‘future proof’ the UI investment.  That is, it abstracts from the client layer and we were to wait for SAP to provide new client rendering engines for alternate client platforms (eg. HTML, Flex, Windows clients) over time.  However, Web Dynpro has been around for many years now, and yet the only real client that is supported is a HTML browser client.  Furthermore, now with the explosion in interest in mobile clients, instead of extending Web Dynpro to render clients for iPhone and Android etc, SAP seems to have taken the easier option of acquiring an external solution from Sybase.  Also with the advent of Gateway, this means that instead of abstracting the client layer, SAP is to some degree outsourcing the client layer to whatever programming model the UI developer wishes to take on.  So what does that mean for Web Dynpro in general?  It will have an important place given the SAP investments in it, but I think it may not be the dominant UI technology for SAP solutions that SAP had hoped for it originally.
    (0) 
    1. Pradyut Sarma Post author
      Hey John,

      You are probably right about whether the focus should be on Web Dynpro for Java or on Web Dynpro. What I was trying to focus on through my post was on Web Dynpro Java as a tool rather than on Web Dynpro as a UI technology.
      Well, to follow up on your point, Web Dynpro can still be used for mobile application development but yes, it is definitely not the Android or IPhone kind of rendering…..more so it is HTML rendering, browser based.
      I guess Sybase and Gateway make sure data is available through a trusted and robust source to be consumed by any UI, including web dynpro. I would term it as a strategic decision rather than an easy option. I wonder if it would be a great idea to extend web dynpro for mobile clients when you already have so many good ones already out there 😉 What if I could decouple the programming model further from the rendering?
      SAP’s investments in Web Dynpro would definitely be controlled but yet important.

      Thanks and Best Regards,
      Pradyut.

      (0) 
  5. Tobias Hofmann
    User-friendly and Web Dynpro in one sentence. Isn’t that a little bit too far?

    What’s missing is the freedom to choose my UI. I cannot use my AJAX language or simply show plain HTML.

    I want to use NWDI, NWDS and the wizards for consuming BAPIS, but I want to be able to choose between or combine WD UI and YUI or JQuery.

    br, Tobias

    (0) 
    1. Pradyut Sarma Post author
      Hey Tobias,

      Maybe I should rephrase myself. Developing web dynpro UI is more user friendly that it was previously with more modelling support and a lot of new features thrown in.
      What you suggest is the support for users to be able to create UI mashups. Maybe the “Islands” concept partially supports what you are looking for. But yes…I agree, there is a lot of scope for improvement.

      Thanks for posting your view,
      Pradyut.

      (0) 

Leave a Reply