Roberto Perillo

Alright! Then congrats, champion!

Welcome to the Ranch, Guilherme! It is good to have more brazilian people around!

Greetings, Ashwin!

From what I can see modeling software using UML leads to better quality code.

Well, not necessarily. The quality of your code will depend on what and how you design your code, and also on your programming skills.

There's this great book by Martin Fowler, named UML Distilled. There's also UML's official web site, where you can find other resources.

Karu Raj wrote:What would be your justification for your decision?

You mean, if we were to create a programming language? Well, if it was an object-oriented programming language, supporting polymorphism would be mandatory, since it is by definition one of the pillars of object orientation.

Howdy, Ayan!

Well, the value of UML diagrams is that they communicate design choices, or even situations. This means that you should create only the diagrams necessary to communicate things to other people. If you're going to create a sequence diagram, but you are not going to discuss it with nobody, then it isn't necessary.

You can create as many class diagrams as necessary, each diagram with a group of classes that make sense to take part on the same diagram. All layers of your application can have one or more class diagrams.

To represent classes of other libraries or frameworks, what I usually do is, I add a stereotype, identifying the library that owns a class. For example, if I wanted to represent the ApplicationContext interface, I would add an interface named ApplicationContext with the stereotype <<org.springframework>>.

One thing that I do all the time at work is create class diagrams on a whiteboard with some classes (sometimes 5 classes, sometimes with 20 classes, it depends) and discuss what will be done with the other members of my team. Thus, we use it as a tool to discuss design.

Gautham Kumar wrote:Our code has method to update the DB. Wondering if we can update this db file while testing.

Well, create a backup copy of the original file and use another copy of it in the development phase. When you submit your project, use the backup copy. The file to be submitted to Oracle MUST have the original .db file.

Well, the idea of the Proxy pattern is that you have an object that stays in front of another object and has the same interface as this object. So, if some operation has to be performed before another operation, you can make use of a proxy, to abstract the caller and simplify its code. For example, we have an object that has a getter method that retrieves a list of Strings, but we have to go to the database to retrieve this list. If there's a proxy, the caller simply invokes this getter method on the proxy object, and the proxy verifies whether the target object already has the list. If not, it goes to the database, retrieves the list, sets it on the target object and returns to the caller. Therefore, the proxy object can execute code before and after the code of the actual targeted object.

The original idea of the Business Delegate was to abstract the presentation layer from knowing how to look EJB objects up. The presentation layer (i.e. a Servlet) would have to know how to retrieve EJB objects that would execute business logic. You could then make use of a Business Delegate, so the Servlet could simply invoke a method on it, which would then retrieve the appropriate EJB object and delegate the execution of the business logic to it, simplifying the code of the presentation layer.

I have to confess that I have worked 95% of the time with Spring, but I believe that the Business Delegate pattern is retired nowadays. And yes, both patterns delegate the execution of things to other objects, but their purpose are different.

Neat!

Hum... are we talking about the proxy pattern and the business delegate patterns?

Dinkar Chaturvedi wrote:The file contents are going to be a JSON format text which I would like to serve as is. Can Quartz be configured to fire the job to write a file instead of a database?

Hum... you mean, if it is possible to get the content generated externally and save it as a file rather than saving it in a database? It's just that, if you do this, then the file will only exist in the server where the job was triggered, and if another server handles a request for the file, it won't exist there, so your problem will still be the same.

The idea of saving the content in a database is that you will be able to retrieve it from any server. You just have to save it as a byte array in the database (in a column of type BLOB). Then, you retrieve it as a byte array and you will be able to write it to any OutputStream. So, with it, you will be able to write it to a file, write it to the console (System.out), write it to a HttpServletResponse.getOuputStream() object, etc.

Ulf Dittmer wrote:Sounds complicated.

Agreed. Whenever I feel a solution is too complicated, I wonder if it is the right path to follow.

So the problem is that there is some data that is generated externally, and since your application is in a clustered environment, it might be handled more than one time (i.e. the number of servers in the cluster), and if you save this set of data as a file, then it would exist in only one of the servers, and if a server different from the one the file is saved in handles a request, then the file won't be found.

Well, what you can do is, since this set of data is handled on regular intervals, you could create a Quartz job and configure it to work in a clustered environment, it's pretty easy (you can find how to do it here). Then, regarding the file, you could save it in a database and retrieve its content from there. Then, no matter what is the server handling the request, the file would always be found.

Howdy, partner!

Well, the books I'd recommend are Head First Object-Oriented Analysis and Design and UML Distilled.

Howdy, Pawan!

Well champ, this "if-else" thing isn't certainly the best way. Especially in the actual page itself: it is better to keep this logic away from it and have it on the server side. It is better to use HTML/XHTML/JSF/JSP only to display things. Eventually, you might have an "if" there (e.g. to verify if the user can see a particular button), but the less logic you have on pages, the better.

But I think we could use more details to give you some advice. It looks like we're talking about something like an e-commerce, right? You have a page, and you have a header that displays things. Categories have higher priority than products. How do you decide what is going to be displayed on the header? I mean, is it based on the product that is being displayed? How does it work?

Howdy, Pari!

Well, I honestly think it takes a lot of studying and practicing until you start solving real world problems with good code. You'll have to study a lot, but with discipline, you'll be able to make it. I'd say that two good starting points are the Head First Object-Oriented Analysis and Design and the Head First Java books.

Howdy, Martin. Welcome to the CodeRanch!

Is it ok to call "UnicastRemoteObject.exportObject(this);" in the RemoteServiceImpl constructor to avoid RemoteServiceImpl "extends UnicastRemoteObject"?

You mean, on line 32 of your code? I don't think that is necessary because you are already doing so on line 58. I'm not sure though, because I didn't run this code...

Is it ok that RemoteServiceImpl does actually not redeclare the service methods incl. throwing RemoteException. Instead just the interface RemoteService declares the RemoteException??? That feels quite strange to me?

Declaring a method in an interface with a throws clause means that the implementations can throw the listed exceptions, not that the implementations have to throw them. It's not strange

Question 3: Overall design approach? Any hints or recommendations?

I couldn't take a very deep look at your code, but for what I've seen, I think you're fine!