|
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] Hello, Some comments: 1. Although principles of OO seems to be easy it is really difficult to built robust OO application, with a good architecture. You need experienced people to do that. It is not necessarly specialist of Java but specialist of Object Orientation. My opinion is that you must accept to engage experienced OO designer and developper, and ask them to design and help the other people of the team. The experience we have here is that the group of experienced Java developper developped fast their application, while the learners faced lot of problems. 2. I am not sure to understand the point 2, but it looks like an architecture design problem. It depends on what you really want to do, but there are way to develop reports for free using XML, XSL, FOP, you can then generate html, pdf, or whatever you want. If you have a browser based application you can also use Cocoon to do that. It is free from the Apache Foundation. There is also Java reporting tools based on Crystal Report. For our internet project, i will provide soon reporting facilities based on Cocoon. I just need to describe my data in XML, transform them using XSL and FOP, and Cocoon will manage the whole. It is completly free and very easy to develop. As our web "services" already describes the data in XML, we just have to write the appropriate XSL file to generate the report in PDF. One guy is responsible to write the XSL files to generate the PDF. He doesn't need any knowledge of Java, C++, only XSL. What you are talking about is also "interoperability". How can we make tools communicate together, especially when they are in different languages like C++, Java, RPG? We have decided to use XML to exchange data between applications. We sometimes use MQSeries as transport mechanism. In this case you don't have to "export" database object. Generally you should never expose database object to other applications, you must have an abastraction layer. It will hide the complexity and only focuses on services. XML is then very useful to pass the data to these services. 3. Once again your problem looks like an architecture choice. If you have a server to provide this information you can insure that only one client at a time get an identifier from the database. You just have to synchronize the method that get the id from the database. If you have written a a fat client application, you can also use different technics: - use a stored procedure that will manage itself a lock on the table of the identifier - write a method that locks the access while one application is getting an id To summarize: my feeling is that you had all of these problems because your java developper and designer were not experienced enough. It seems that your difficulties can be solved with different architecture. The problem you faced are not related to Java, but working in a client server environment. You would have have exactly the same problem working with other languages. My opinion is also that these kind of problems should never be solved by technic solutions (like how to pass a database object to Crystal Reports), but by design solutions. You must write abstraction layer between each level (DB, BO, UI), and also between the applications. But, before to be able to do that, you must be really experienced. In OO you build blocks and architecture to build block, you don't add lines to a program. >From my experience, the recent use of XML and XSL gave us a lot of solutions to problems that could have been very technical: - exchange data between java programs and our legacy application - exchange data between very heteregenous systems and some very old ones - generate reports easily, for free. Now my only experience is on object orientation. My opinion is that Java is a very good choice. I could not come back to C++. What i also see is some human problems. Some very experienced RPG programmers must accept that they can't do very good java programming untill one year, just because you must really understand object orientation. This is a task of the management to manage the learning curve and to hire the appropriate persons to ease the process. Cheers Gilles -----Original Message----- From: Vijosh A [mailto:vijosh@systsoft.com] Sent: mardi, 9. octobre 2001 08:54 To: java400-l@midrange.com; web400@midrange.com Subject: Java App. Development - Is it Worth ? Hi all, we have been developing a java based application for the past 1 year. the first phase is almost over. some of the issues we faced are - 1. Lack of experienced people in Java. For starters also, RPG learning takes much less time . They program and start delivering in 2 months time. Whereas with Java people get bogged down with nitty gritties of Java and Object Orientation to an extent where they often forget the business logic itself. For e.g. if you have 3 to 4 combo boxes on the screen and if one triggers the filling of other and vice versa, the listeners really play squash. YOU OVER SHOOT TIME LIMITS, FRUSTRATION FOLLOWS, A CUT IN YOUR PAY CHECK ARE THE CONSEQUENCES. 2. When it comes to developing reports like the ones developed & implemented using RLU - EXCPT (RPG OpCode, it is another set of woes. You don't have many reporting tools that integrates with java. They are too expensive too. If you go for Crystal Reports, then u need to write a C++ interface. Still u don't have any control over Crystal Report once it is invoked through this interface. Crystal Reports does not recognize the database object passed by java, whereas it does understand the result sets sent by VB etc. HERE WE STAND THE RISK OF LOSING THE CUSTOMERS CONFIDENCE WHEN HE DOES NOT GET REPORTS AS HE USED TO GET WHILE USING AN RPG APPLICATION. 3. Next is the problem with ID generation. Suppose u want continuous generation of employee ID's in a sequential manner. So if u keep the last ID in a physical file and decide to use a trigger-program combination(which was the only solution we found to be feasible)then comes the next set of problems. In a mulitple user environment 2 users can get the same id. To prevent this we use a Data Queue. And put the generated ID into the Data Queue thereby making it possible for requester program to pick it up from the Data Queue. PALTFORM INDEPENDENCE IS COMPROMISED. To sum it up, the amount of learning a new guy needs to do and the amount of self moulding of one's thinking when programming with java is too high. This leaves both the employee and the employer disillusioned !!! Thanx for your patience and sorry. Now my question, does everyone face such problems? If yes what is your approach in solving these issues ? Economic recession added, Does your company still have the confidence to place bets on java ? Thanks Cheers Vijosh >From the Desk of : Vijosh A. Senior Consultant Systems & Software 123, SDF 4, SEEPZ Andheri (E), Mumbai. Tel : (91-22) 829 0803/0075 Fax : (91-22) 829 2578 -------------------------------------------------------------- Systems & Software, Mumbai, India Sent using "The PostMaster" by QuantumLink Communications One Internet account, unlimited personal e-mail addresses Get your free copy of "The PostMaster" at http://qlcomm.com/ _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. ********************************************************************** This E-mail and any files transmitted with it are confidential and intended for the exclusive use of the addressee(s) only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender immediately. **********************************************************************
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.