Giovani Salvador's Blog: May 2008 Archive

I already interviewed lots of Java developers during hiring activities. As part of the interview, besides other things, I like to understand if the person being interviewed has understanding of the applications he/she develops as a whole, I mean, not only understands business requirements but also understands the entire architecture of the application and, most important, why that specific architecture is in place for that application and its specific needs.

So below a typical dialog between a candidate (C) and I regarding architecture of a Java EE application.

- So, could you please describe, from your perspective, what should be a typical Java EE architecture for, let's say, a medium-size web-based application?
C - Of course. Well, typically I will have in place a lightweight container like Spring and persistence mechanism like Hibernate. Spring will do everything for me.
- Alright, let me be more specific, I believe my question was not well-built. Imagine if the end user is about to submit a form data. What will be the flow that data would take to be persisted in database? Describe to me the building blocks, all the path of the data, which objects will apply business rules, which objects will handle web requests, etc. Feel free to draw this architecture if you think it is better for you.
C - Not necessary. Well, I would put Spring MVC in place to handle all the requests. For persistence, Spring DAO with Hibernate support.
- hum, I think you haven't got the point. Forget about Spring. forget about EJBs. Forget about lightweight or heavyweight containers. Forget about Hibernate. Imagine you don't have these technologies to assist you. You have to propose the architecture without using any specific product. What would you do? Remember, no products. Just give me building blocks.
C - .....
C - .....
C - In the presentation layer an object will take all data submitted and...
- Which object?
C - hum...... maybe a Servlet object or .....
- Or a managed bean, something like this? Ok, go on. Once data is retrieved from the UI, what will happen?
C - ... ok, data will be sent to an object and this object will perform business rules and after that data will be persisted.
- Could you please be more specific? Do you have in mind any design pattern that could assist you for this architecture? What would be the structure for the domain layer? And Persistence layer?
C - ...
C - Man, I would work with Spring, it does all those things for me.
- Alright, that's good for me. Thank you.

Let me say somethings about this dialog.
First: I don't have any problems with Spring. In one of my posts I said that I never used it because I never had to. We need to find solutions for our problems and not create problems for given solutions. By the way, comments in that post were great.

Second: The candidate never asked how many transactions per minute, hour, etc, how many concurrent users, if it is a critical application. That dictates the architecture. We can't have silver bullet and it seems today most of the "architects" have silver bullets. And, even worst, relying on specific products. Also, based on the non-functional requirements of the application we could see if clustering would be needed. But no, no question about those kinds of things at all.

Third: The lack of knowledge on some typical design patterns is also something to take into account. Façade? DAO? Value Objects? Application Controller? Even if we don't need all of them, candidates should be prepared to use them when necessary.

I know it is hard in an job interview to remember all those things. And I really don't have answers for all problems, most of the times we just can't propose an architecture whitout digging deeper in the details, in the business requirements and having lots of discussions with peers and even business team.
But as developers and architects we can't be relying on specific products, we need to be able to understand architecture as a whole and what are the options we have to better propose a scalable architecture and build a solid system.

Here a few basic references about all this stuff.

Java BluePrints - Here some good stuff for JAva Enterprise Applications.
Java EE Design Patterns: Core J2EE patterns are here also
Patterns of Enterprise Application Architecture, from Martin Fowler.
Head First Design Patterns.

There are lots of other good books and articles. Please, feel free to comment here adding more references.
Also, what do you think would be the basic understanding developers should have nowadays? Any other specific skill?

Powered by
Movable Type 3.01D

java.net RSS Feeds