“Why ABAP Performs Better in Portal Development than Java” – Hmmm
I ‘just’ saw the article on the front door of SDN. ‘Why ABAP Performs Better in Portal Development than JAVA’ Suffice to say.. I am speechless.. I am opening this weblog so we can have a discussion of the merits of the article, and we will have a record of our discussion.
I was only able to read the FIRST 3 PAGES until I go so frustrated that I am red in the face. As a Web Architect who has experience developing large scale .COM applications and have been working with SAP since 3.1, I have been telling everyone how impressed I was that the SAP community is actually embracing the rest of the web community by focusing on Java development, now someone decided to post this article and the untrained person will look at it as SAP gospel.
I just wanted to start with the premise of the article stating that web development in ABAP (via BSP) is a more sound STRATEGIC decision then JAVA. The authors then decide to backup that premise with an argument based around DAY TO DAY CODING practices.
If this paper was intended to help managers and architects make a strategic decision, the paper should have focused more on the higher level issues like:
- SAP Strategic Direction
- Industry's Strategic Direction (really .NET vs
J2EE)
- Interaction with other vendors and systems
within a company's enterprise
- Availability of skilled resources
- Availability of a global development community
All which focus on JAVA.
Also, I was shocked to see that example was based on JAVA support of EP5.0!! ( 6.0 was mentioned and 'seemed' to improve robustness ) And as for the comments of JAVA being 'young'. I think that comment speaks for itself..
Enought of my ranting.. for now.
Hi,
I totally disagree with this article. Did you know that SAP is pushing WebDynpro for JAVA and ABAP? The article you wrote is meant for somebody(sap clients) whose portal contains only application that talk to R/3 . I would not recommend developing a brand new application in ABAP(BSP) that has no relationship to R/3. Java gives you so many options. Have you heard of Hibernate where you don't need to write a single line of SQL statement?
Thank you.
Prakash Singh.
Hi Prakesh,
I appreciate your comments......obviously the article was aimed at applications only talking to R/3. It would make no sense trying to get a BSP application talking to SQL Server etc, the article clearly stated that Java is much more flexible that ABAP but since (in my experience) the majority of Portal applications have been made around R/3, I have definelty found BSP's to be easier to maintain and develop than Java....period!!
I'm all for WebDynpro, I've developed one or two on WAS 6.40 and they look really cool in Java. Yes I have heard of Hibernate.......great thing to use BUT you must remember that the article was written looking at more than just "syntax" but also into SAP transport, version control etc and I'm sorry but Java don't even come close in this regard.....
Have you developed in both languages for the Portal?
Regards
Lynton
Hi Lynton,
I have nothing against ABAP. I used to be a abaper and I have written internet application in ITS(html business language), BSPs , WebDynpro & Portal Components( JSP & Dynpage). I agree with you that ABAP development environment definitely has better version control and navigation (editor). Supposedly DTR for Netweaver Developer Studio is going to come close to giving the java developers version control similar to ABAP world. I was SAP employee until recently and most of the information I got from developers in Germany, Israel & India was that SAP is pushing WebDynpro real heard. BSP are not going to be around in couple of years. In fact they don’t want people to develop stuff in even in HTMLB for JAVA(for Portal application). The idea is to keep the UI separate from business logic. If you have business logic in R/3 or BW then you will use WebDynpro to connect to RFC function module or web services that belong to RFC function module. If your application sits outside SAP world then you will write a EJBs or web services which will then be called by WebDynpro.
Thank you.
Prakash Singh
If you are going to throw comments out on SDN about product X not being supported anymore, please back them up with confirmable documents or sources. Otherwise we are really just starting rumors.
IF WebDynpro supports all the features that BSPs do and IF there was a mechanical way to migrate BSP to WebDynpro they might let it go but not before.
Best regards
Dirk
I've not read the article but to be honest all the arguements being presented here are all one sided or the other. The author didn't place the article on the Front Page SDN did. Perhaps after SDN reads all these comments they may adjust their stance of the article but perhaps not.
In terms of SAP, the Java framework is realtively new. ABAP has been around awhile now. But taken out of context I can see where one could misunderstand that.
What they stated and found with the Java in EP 5.0 is all correct, however, a responsible person would have performed the testing of the two applications within a short time period of the other and both using realtively new frameworks from both sides.
As a quote from the document on page 3, "Under the code name “Unbreakable Java”, SAP is currently putting in a great deal of effort in order to build a new J2EE framework on top of the reliable ABAP engine. Subtitled as the “Always On Java” initiative, it addresses and critiques the robustness of the J2EE implementations. But it will take some time until it is available to the public, so it is still worthwhile to concentrate on the current J2EE releases."
Having only read the first few pages of the document as it is late here, I must say that the only thing that bothers me other than what I just pointed out is the title they used and not using a stronger discolsure than "This article describes the experiences of implementing a nearly identical SAP Portal application, first in Java, and two years later, in BSP. This article attempts to give a practical viewpoint on Java and BSP development in the Portal production environment. It has not been written to promote Java over BSP or vice versa, but rather to distil some “ground level” insight into how the languages compare in complexity and “user friendliness” from a development perspective—while still being able to get the job done!"
But as I mentioned about the two years, any good and responsible - manager, developer, person will see that time difference and know that the comparison is not exactly the best done. The tools for both languages have changed drastically in the last two years.
All in all I would say the paper is good and it makes you start thinking, I personally would use their examples and do something similiar myself to give my developers the chance to decide which way is better for them, because in the end it's not what language you use it's how well you use it and as Thomas mentioned your "But like so many SAP shops, our developer's skill set pool isn't really deep enough to support two major development platforms. I know that I already have to have ABAP skills to support custom development in the R/3 backend. Therefore in the end just about any technical argument in the ABAP v. Java war really doesn't mater because they are close enough in the SAP environment that you can make the decision based upon what skill sets you have available".
Now once again as I just read through the thread to see if I missed anything and Prakash has responded again.
You might have worked for SAP you don't anymore, you might have heard something about something from someone these RIG's but unless you can without factual hard written proof back something up such as this statement "BSP are not going to be around in couple of years" DO NOT POST IT!!! Period!! You have just done exactly what you have been trying to codeem from this article you have thrown something out there that someone is sure to read and now have/may have gotten several people nervous about their current "STRATEGIC" position in terms of development within SAP. This of course is no better than what you are saying the article has done. This is irresponsible from you, unless you can show hard proof that this is a factual statement. To date I have seen nothing from SAP stating what you have just said and therefore unless you can show otherwise there is no point in bringing it out, it confuses and adds unneccssary concerns to those reading and coming to SDN for "solid" information.
Craig
Hopefully you all understand that i don't speak for SAP. I am no longer a SAP employee. SAP has not made an official statement about BSP and its future. I have posted basically an inside news thats i have heard many times. Craig, don't get offended. Think abou this. If BSP is here to stay then there was no need for SAP to release WebDynpro for ABAP. I also want to mention that ABAP is not going away. What i am trying to say is WebDynpro for ABAP might be the replacement for BSP.
Now it has it pluses because of this - such as deployment to different client platforms with out changes to your coding. However this also means that you can't include your own HTML, JavaScript, and ActiveX controls. You also can't, with the current tools, run stateless. Therefore there are things that BSP does and does well yet WebDynpro doens't. The opposite is true as well.
Now I'm not an SAP employee, nor have I ever been one. However I am a SAP customer. I have spoken with many people within SAP, from Developers to Product Managers about BSP. Let's just say it's not keeping me awake at night, wondering if SAP will support me on the development tools I am using.
But beyond it all there are some simple facts. BSP is a supported part of NetWeaver04 WebAS 640. Counting Extended Maintenance, the NetWeaver 04 stack and its included development tools are supported until 2013 according to the PAM (Product Availability Matrix) available on the Service Marketplace. That's eight more years of support and eight years is a heck of long time in the ever changing IT world.
With that now being said, and I think both sides of the "article issue" being discussed I would think this conversation is now over.
Oh and did zou ever get the author|s permission to post their Email messages between the two of zou here? I certainly hope so!
Craig
My main issue with the article is that you are trying to determine 'The Right STRATEGIC Choice for Portal Development' and I also have a HUGE issue with the article appearing on the front door of this site. I have spent the last year speaking with many EP6 clients who are having issues understanding SAP's J2EE position.
Now, I honestly don't care 'which is easier' to develop in. Whatever language you know is easier ( like learning Spanish or English ).
However, when you introduce the premise of proving a STRATEGIC direction.. that has nothing to do with how easy the language is. Heck, send developers to a 3 week training class and BAM! they're experts.
Also, as for the transports and management of JAVA code. Those tools do exist, just not in the SAP JAVA realm ( look at Websphere or WebLogic )
Once again I did not choose for it to appear on the front page of SDN...
As far as strategy goes well what does a company do who has an entire pool of ABAP developers and wants to go EP6 etc. You try take an "old school" ABAP guy and put him on a Java course and see what sort of quality you get on the Portal. Changing someone's mindset is far from easy and if a company already has the ABAP skill, why not let them know that BSP is also out there and that it does a VERY good job as well...
Once again it's not just about syntax - so lets look at the SAP WAS as well then...this is unbelievably STABLE and is definetly a force to be rekoned with when comparing it to J2EE and .NET. But that is an entirely different topic.
On the "transport and management" of Java code...ok, this is getting MUCH better but come on...be honest, the SAP transport and management system is simple unmatched in this area!!
Regards
Lynton
Let's see, there are die hard supporters of both Java and ABAP (BSP) in the SDN community. Many people on both sides of the fence have had the opportunity to work in both environments. To me that means that both sides are wrong and both sides are right 🙂
My how I wish I had the luxury of making such a decision. But like so many SAP shops, our developer's skill set pool isn't really deep enough to support two major development platforms. I know that I already have to have ABAP skills to support custom development in the R/3 backend. Therefore in the end just about any technical argument in the ABAP v. Java war really doesn't mater because they are close enough in the SAP environment that you can make the decision based upon what skill sets you have available. And frankly I am happy to have that flexibility.
I did want to comment on the following statement: "I would not recommend developing a brand new application in ABAP(BSP) that has no relationship to R/3". I don't know if I completely agree with that. To me such a development doesn't seem far fetched, especially now on 640 with very good ABAP WebService Proxy support (functionality that looks and feels very much like its Java counterpart I might add).
I wouldn't have believed it a few years ago, but SAP has done an excellent job of bringing the best of the ABAP world to Java and Java to ABAP. In the end both tool sets have been made stronger over the years thanks to the inclusion of Java in the SAP ecosystem.
One doesn't need to see it as black or white as if you need to select only one technology.
In fact, I will show next week at SDN meet Labs that even plain ABAP can do the job, since there are/were good reasons for it. It will also show that it even lives in peace together with BSP and external tools/technologies.
Some people might find it not sexy enough or whatever, but it works perfect (for us within that particular project).
I really like the way you think...I'm hoping that in future the Java and ABAP guys will mix and match the two languages as need be to find the best solution to a problem - I'm very happy with that sort of scenario and flexiblity it gives a developer. With the very OO way that ABAP is going, it's just a matter of time before many SAP developers become fully "bi-lingual" in BOTH languages - that sure will have its advantages!!
And yes, SAP has done an EXCELLENT job in bring ABAP and Java under ONE SAP "umbrella". ABAP / BSP is sure to only get stronger and stronger with its strong OO/Java influence 😉
Regards
Lynton
First of all I did NOT put the article on the front page of SDN...I appreciate your comments and can well see why it may "throw a spanner in the works" but let's be a bit more "open-minded" here...who really cares what technology you use (Java, .NET, BSP etc), you want to get the job done. We went through very much of an "unknown" period at work not knowing if we should skill the ABAP guys up in Java or what all this "BSP" stuff was about and in the end we actually have BOTH running on our Portal - it just so happens that the BSP developers can produce solutions (connecting to R/3...) much faster etc than the Java guys (although I think the .NET guys are going to suprise us all soon!!) I think one thing that should have probably been pointed out MUCH earlier was that this article was written in a "pure R/3" environment...I see no real point in getting BSP talking to an SQL Server etc, I agree (as the article states) that Java is FAR MORE FLEXILBLE than ABAP...but in our R/3 centric environment that didn't matter.
To those of you who have had experience in BOTH Java and BSP for the SAP Portal I think you'll all agree that BSP is really great. I admit, I am NOT up-to-date with all the latest and greatest Java stuff on the Portal, but I do keep pretty informed...You have some valid point on the "global development community" etc and although that is true I don't think it needs to blond the fact that BSP will work perfectly well in numerous situations.
We are not hear to point fingers at all or get this massive comparison on Java VS BSP...we just feel Portal developers should be more "open-minded" to their development choice - It's not just Java or .NET for the Portal...BSP is also a VERY strong player!!
I also think one needs to see this in the "bigger picture" as well, I mean the framework must work well in the Productive environment and that means a big challenge:
+ Being able to service thousands of user requests simultaneously
+ Linear scalability of the runtime environment
+ Easy debugging in productive environments
+ Being able to fix coding errors in minutes
+ Having a reliable change management and deployment system (TMS is unbeaten!)
+ and many more
Thanks for your comments anyway...
I cannot answer to all of you, but I like to comment on Craig's opinion, that the decisive arguments are all in favour of Java.
- SAP Strategic Direction
Brian McKellar already answered this one: there is no strategic decision to favour Java over ABAP. It were indeed absolutely unwise to do so, because ABAP is the industry standard in enterprises (not Java). The big majority of support people and in house staff in large enterprises are trained in SAP® R/3 and ABAP development. There is no industry need to abandon ABAP, so customers would understandably ask where there ROI would lie when they have to switch to Java and another development platform. Currently there are no arguments besides the enthusiasm of a group of young developers. So a strategic decision to abandon the ABAP line would definitely lead into an uproar amongst SAP® customers.
“The limits of your language are the limits of your world!” This is true in real life and for developers as well. There will both languages and frameworks around fro a long, long while and they will both service their clients. Currently we simply see that J2EE (besides the Webshpere variant) is not yet mature enough.
- Industry's Strategic Direction (really .NET vs J2EE)
As said above: I know a lot of SAP® customers that experiment with SAP® Netweaver J2EE, but I cannot see a major SAP® shop to make a strategic decision to abandon the ABAP platform in favour of J2EE. Those who would will already have a focus on Java from other areas, mostly likely they are focussed on IBM Websphere and Oracle.
- Interaction with other vendors and systems within a company's enterprise
I think this addresses the whole EAI issue. It is a pure fact that some major EAI middleware is implemented in Java and relies on adapter development mainly in Java as XI does. But this is not an argument for Java, many would have loved to see XI completely implemented on top of the reliable ABAP engine.
- Availability of skilled resources
What is a skilled resource? What the market needs are developers with a sound and thorough understanding of the business processes. Currently you find them particularly in the ABAP, Visual Basic and Delphi sectors. Java resources with a high understanding and long year experiences in business processes are extremely rare and if you find them, they are just as competent in ABAP. Honestly, a good developer does not even care what language he/she is writing in. The question circles around the available utilities, development environment and libraries. The development environment of the ABAP workbench combined with the TMS change management and the script-like just-in-time compiler are unbeaten. In large scale implementations they are so utterly helpful, that I cannot endorse a system that does not deliver something alike or even better. Eclipse simply does not!
- Availability of a global development community
Yes, they are helpful. But in enterprise daily work, they are not so important as you think. Changes are slowly and mostly they are very trivial. The communities have a high academic value, but I can tell you that not many of my fellow enterprise architects make actively use of the community resources. Such communities are helpful, but i enterprise support organisation will rather pay for a resource that can give a clear guarantee on the work.
The list is not truly complete for a decision making process. All the arguments circle around the developer's point of view. But even more important is to look on maintainability for the support staff, agility when changes are required, and scalability of the application.
Assistance of Support and maintenance and change management
A typical enterprise application has to deal with thousands of simultaneous requests at peek times. The underlying framework must absolutely be capable to reliable service these requests. All of the ABAP community knows that it is practically impossible to bring the ABAP runtime down due to a buggy program. There is some serious doubt that you cannot write code that brings down the J2EE runtime. SAP is preparing for the “Unbreakable Java” to deal with this important and decisive issue, which will bring Netweaver J2EE to the same level of IVBM Websphere that uses its own runtime for the execution of Java code.
Then there is the issue of support in general: ABAP guarantees that source code is available for debugging in production at any time. That is an indispensable feature. Java unfortunately still allows to deploy -code without the source to a production environment. An changes made in development are not automatically traced as they are done in ABAP TMS.
Readability of the code
We had this discussion already many years ago when talking of the advantages of C versus PASCAL. While the C protagonists stressed the flexibility and alleged performance of C they always ignored that performance is a unimportant feature in most practical cases. A clearly understandable code, that allows a later developer to easily enhance the program written by someone else is the highest goal. The Java-only guys often cannot understand: Java is not readable at all for someone, who does not use it every day. ABAP and Visual Basic are. Even if you have not dealt with ABAP or VB for a good while, you will be able to read it easily and understand what the developer wanted to express.
You see the decision is truly not that easy and clear as some might think. The final argument in every enterprise will be: we have a running system (and this is usually ABAP). What arguments exist to replace it with something new? And how much money will it save us?
All the best
Axel
I would just like to reiterate the fact that I am an old BASIS guy who left SAP for a while, did Java development, and am now back.
There is a major fallacy floating around that JAVA is NOT used for Enterprise Solutions. I can't go into specific, but I am 100% sure that if you ask IBM if they build Enterprise solutions using JAVA or J2EE they will respond with 'Of Course, where have you been for the past 5 years?'.
If we step outside of the normal 'SAP Zone' which is what Netweaver was 'supposed' to do, we will see a HUGE HUGE developent community that dwarfs that of SAP's. The first step in truely embracing a new community or a new direction is to admit that you do not have all of the answers.
Also is ABAP truely a OO development language? Hmm?
This is the BSP development team (so to say directly from the horse's mouth): BSP is a standard SAP shipped product. The usual SAP's support of 5+2+1 applies here as well. So you can be sure that we are planning to hang around for a while. And yes, the same development team is also doing the ABAP part of the Web Dynpro strategy. Which means, as a development team, we now have two good development platforms that we support, and plan to continue doing this for many years to come.
regards, brian
SAP, Development Architect for BSP & Web Dynpro ABAP
If we go Java route, we may not have to place WAS -ABAP in DMZ-1. We have come accross similar scenarios and we are considering converting some BSP's in to webdynpros to avoid exposing the ABAP engine to the extranet.
Any thoughts on that?.
Our Portal landscape ensures our WAS is totally secure. Let me sketch the scenario: We have a REVERSE PROXY in the Public DMZ; the Portal server is in the PRIVATE DMZ and the WAS server is in the "secure zone". Client certificates / SSL has been used to authenticate users wishing to come onto the Portal; there are security certificates between the reverse proxy and the SAP Portal server and further certificates ("handshaking") between the SAP Portal server and the backend WAS box.
So I would not worry about the fact of "exposing" the ABAP engine to the extranet - it can be "locked up" quite nicely in the backend.
Regards
Lynton
The technology which is described there is pretty much outdated (EP5 and JCo Client Service, which is even deprecated in EP6 !).
The state of the art technology for writing business applications for EP (in Java) is Web Dynpro (adaptive RFC). So the comarison should be based onn that technology !
BSP is NOT GOING AWAY. Let me say that again… BSP is NOT GOING AWAY.
ABAP is NOT GOING AWAY. Let me say that again… ABAP is NOT GOING AWAY.
SAP has expended a tremendous amount of research and development to bring the robustness, scalability, and change management features of the ABAP world to the J2EE camp. Web Dynpro technology (both in Java and ABAP) provides a scalable and flexible approach for designing enterprise class applications with its Model/View/Controller design model. At the same time, SAP has also extended the features of the J2EE world into the ABAP side with technologies such as BSP and ABAP objects. Other technologies such as ITS have also been utilized to bring web based access to R/3 applications. SAP has delivered a number of components using BSP technology and many customers have also utilized this technology for their own developments and applications. SAP realizes that many customers are using BSP technology in their own development and SAP WILL CONTINUE TO SUPPORT BSP based development, as Brian says in his earlier post. BSP is NOT GOING AWAY. When making your decisions around Development, it's of course very important to understand and carefully consider the pros and cons of each option, and how they may influence the design or maintenance phases of an application's lifecycle.
Now regarding the article that started this whole furor. I personally think it is not quite fair to compare the EP5.0 Java development environment (now almost 4 years old) with the later BSP technology. It does not serve the SDN community well to provide such a slanted (and in my opinion - biased) viewpoint. A much better comparison could have been made utilizing the latest J2EE 6.40 and Web Dynpro. You could have made a real comparison that would have had much more validity and weight.
Just to reiterate - SAP will continue to support BSP, ITS, etc. for quite some time. You DO NOT have to convert your existing BSPs to Java or Web Dynpro for ABAP (or any other format). However, with the other options now available, it is very important to consider the strengths of Web Dynpro when making your decisions on new development. The upcoming ABAP 7.0 development environment supports Web Dynpro for ABAP so you can have your cake and eat it too!
BTW, Java is not going away either 😉
Best regards,
Will
Will Carlton
SAP NetWeaver Foundation RIG - Development
http://www.jroller.com/page/tk10/20050415#is_really_abap_perform_better
By the way your weblog was quite interesting, you should think about writing here as well.
Craig Cmehil
Much respect.
I think SDN is evolving into a credible forum and when I feel I have something credible to contribute I will do so. My annoyance is that SDN needs to to remain impartial, promoting pay per view content, especially old content negates this proposition.
I authored the comment attached to the weblog at tk10 and did so to highlight the alteria motives and inconsistencies of the article "Why ABAP Performs Better in Portal Development than Java" which in my opinion was introduced as a red herring.
There is no right or wrong answer, as a developer and mentor with many years of both JAVA and ABAP experience, I am more than happy that there is more than one choice. My opinoin is that a debate on the merits of two credible programming languages will ultimately cause a riftin communities which isnt warranted.
I wait for future findings of SDN Meets labs but add there was no resolve to the JAVA vs .Net debate and market forces will drive future software developments not discussions - hence my thoughts that the next generation of webdynpro will be a fully compliant XML MVC framework with little or no programming.
just to let you know, that Matt Danielsson from searchSAP.com did an interview with Mario Herger, development manager at SAP's Palo Alto, Calif., development lab
The interesting part is that he made it unmisunderstandibly clear, now from the management side, that ABAP and JAVA will exist in parallel. There is an excerpt below ...
Best regards, Axel
http://searchsap.techtarget.com/qna/0,289202,sid21_gci1082729,00.html
"Some developers have remarked that it seems SAP is moving away from classic ABAP development and going toward true object orientation. What does the future hold for ABAP versus OO?
Mario Herger: First off, the majority of SAP code around is still ABAP. However, what we're seeing today is a need to expand beyond pure ABAP, which is why SAP opened up to Java a few years ago. The Java world is very different from what we used to have and offers many advantages. We have our own J2EE engine in place and we're working with Eclipse to facilitate OO development in SAP. Meanwhile, ABAP is more than 10 years old and has the benefit of being a proven technology.
For those concerned about ABAP's future, I want to make it very clear that ABAP will live on. The majority of current SAP development going on is still done in ABAP, and there are tremendous investments made in ABAP.
So rather than viewing an either/or proposition, think of it as merely opening up for other technologies. What we see today is something of an equalization process where ABAP and Java are used in a complementary way. You can use either approach for pretty much anything, and SAP provides the platform and the tools to make it come together seamlessly."