|
On Montag, 5. Juli 2004 19:57, Joe Pluta wrote: > > From: Dieter Bender > > > > > I would never use EJBs, except for... well for anything, really. > > There > > > > isn't a single iSeries industry expert that I know of who still > > promotes > > > > EJB. > > > > Joe, do you remember me?, so I'm no iSeries industrial expert in your > > opinion??? Do you really think you are the one and only expert??? > > I am certainly not the only expert, Dieter, but all the people who have > published books or columns in the iSeries community agree with me. That's simply not the truth, I didn't publish books, but many columns on these topics in germany in the as400 community and I've made more than 20 presentations on german common events on difrent topics in a wide range, you might have a look to my webpage www.bender-dv.de. > As > to your credentials, Dieter, in every one of our discussions you've made > lots of unusual claims and never proven one. Joe, your claims are unuaual and unproven; following your opinions the whole java community is wrong and only some guys are knowing how to do it - would you please be so kind and declare why the java community is going away from as400 to other systems??? most of my customers change their hardware, or the as400 plays the role of a database server, because its too expensive to run true java applications on as400. > Your positions are so > different from those of the iSeries community that I have a problem > considering you as an iSeries developer. Mabe your positions are so far away from java, that the java community might have a problem considering you as a java developer? > You're more of a Java > developer who happens to use the iSeries. If you are rweally interested abaout my work, have alook at my webpage, there is some rpg freeware and ist shouldn't be too hard to understand - even with my german page, the rpg stuff should be readable. > > For example, you recommend that nobody ever call RPG from Java. Be a liitle more exact on this, my recommendation is: never make a synchronous call from rpg to java or vice versa. If you have a need to use an existing code of peace, decouple both worlds (think in services). > You in > fact recommend a Java only solution, with no RPG at all. Thats the goal, once you have started with java!!! > That's > probably the worst recommendation you can make, and it's potentially > crippling to an SMB with heavy investment in RPG skills, which happens > to be the vast majority of iSeries shops. Put in from the head to the feet! Peaople who are programming with java, because they like it, won't go back to rpg, the maintenance of existing applications need more rpg programmers, then we will have in ten years. Everybody has to make a decision: stay with rpg or (and not and!!!) move to java. > > But even were we to forget about that and assume that you are qualified > as an industry expert in iSeries development, that still only makes ONE > iSeries developer who believes in EJB. So I'm pretty comfortable with > my position that EJB, especially using container managed persistence > (CMP), is inefficient code that has no place in business application > development. > > > The main things are scalability and better separation of business > > layer > > > and controller; > > This is silly. You can have great separation in RPG, and many of us > have proven it over the years. What software do you mean??? BPCS??? MAPICS??? Where I have a look, I see Programms opening Database Files, Print Files and Display Files in one Programm- no seperation of tiers at all. You are recommending in this thread to use record level access - in other words: put the physical structure of the database to the application layer, where is the seperation of Layers??? It's a matter of design. I design > three-tiered systems all the time, with a servlet/JSP presentation tier > and an RPG back end. As to scalability, there aren't any machines out > there that scale better than the iSeries. That might be a dream of ibm as400 division! have alook at the java server Benchmarks, Mr. Google might help you. > Please explain how EJB helps > scalability, and skip the buzzwords: provide a concrete example. If you don't use ejbs (and don't write some of your own with another applicaion server) the size of the objects stored in your sessions will be the limitation of your web application - using ejbs, you can move this to as much app server as you want and you have only to store the session id of your session beans in your session object of the servlet engine, thats the machanism - joe, this is no secret, you can get as much prove on this, as you want from as much experts as you need. > > > I've made some reviews of projects in > > the last three years and the projects not using ejbs had more problems > > with > > business code in the controller (especially using STRUTS, thats one of > > the > > > weak points). > > Well, I don't use Struts, and I separate the application control from > the presentation logic. In fact, in one model (server/client) I write > the application controller in RPG. It's extremely fast and allows for > incredibly flexible development. > > And not a single EJB in sight! > I did never say, that you have to use ejbs in every project, it was you, who claimed without any prove, that you never should use ejbs and you claimed, that there is no expert outside saying something else - trying to make people believe, taht anybody who uses ejbs is a fool - its your turn to proove your statmenents not mine!!! > > > Start with this: in order to use EJB you must journal all your > > files. > > > Joe, more then 10 years ago we journaled all files in an environment > > without > > any java programms, totally rpg without commit, we've journaled all > > files, > > > for recovery after program faults and for problem detection, whats > > wrong > > > with journaling??? > > Journaling is unnecessary overhead. The fact that you even ask > indicates that your client base and mine are different. I would venture > to say that the majority of iSeries shops do not use journaling. There is no transaction controll without journaling and commitment control - I don't know american laws, but european laws say: if you don't use all technics, that are available, you are responsable for all damage your software makes, do you really recommend: no risc no fun? One word to the overhead of journaling: I'm the architect for the data staging process in a data warehouse in germany (one of the biggest as400 absed installations here, with data in the terrabyte range) - its an rpg project (so far to my as400 and rpg knowledge), we use sql for database access, all tables are journaled and all programms use commitment control. We use parallelism to speed up and the as400 with about 8 processors in the partition is filled to 100% cpu for about 80 minutes and the work (cleaning, aggregate, doing some history stuff etc.) is done. You might even cancle every job of the load process, it would not corrupt data. Joe, sorry, are you really shure, that you didn' sleep in the last years? Dieter > > Joe > > -- > This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) > mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/java400-l > or email: JAVA400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/java400-l. -- mfG Dieter Bender DV-Beratung Dieter Bender Wetzlarerstr. 25 35435 Wettenberg Tel. +49 641 9805855 Fax +49 641 9805856 www.bender-dv.de eMail dieter.bender@xxxxxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.