Tiers is a reference web-based business application implemented using J2EE technologies.
It aims to demonstrate the multitier design approach of an enterprise level application.

Key features:

    * J2EE deployment scheme (.ear package)
    * All used technologies implementations are free available
    * Strict layers responsibility
    * Clear interfaces between layers/sublayers
    * Web GUI layer:
          o Model-View-Controller pattern implemented in the web context (without Observable, with every request Model generation)
          o User-friendly browser back/forward support (redirect after POST, session stored form data and result messages)
          o Object oriented approach to XSL stylesheets
    * Business layer:
          o Business logic beans sublayer
          o Data Access Objects sublayer
          o Business logic functional testing
    * Persistent layer:
          o Object interface to persistent data
          o Runtime translation to SQL queries
          o Transaction connection pool

Used software:

    * Java 2 Platform, Standard Edition 1.4.x
    * JBoss 3.x (application server)
    * Maverick 2.x (web MVC framework)
    * Saxon 6.x (XSLT Processor)
    * Hibernate 1.2.x (object/relational persistence and query service)
    * PostgreSQL 7.3.x (relational database server)

Checkout this sample architecture / application at: http://romanpetrov.com/tiers/

Hi there,

It seems to me the site is unreachable?

Domain romanpetrov.com is recently registered. It can be problem. Try http://poma.spb.ru/tiers/

Roman,

It seems that all the pictures file on the web site are not found. Can you check that ? (I've tried on the two URLs you gave).

Thank you.

Jérémie.

Strange problem. It's correctly under Galeon/Mozilla and IE6. Download binary build. You can find html documentation there.

The overall architecture looks good, and I'm glad you posted the high-level design.

I'd love to hear more about the reasons you made certain decisions in this architecture. For example:

1. I've been struggling with Struts in a J2EE application. You chose Maverick to support MVC. Alternatives include Struts and Webwork. Why Maverick? Rod Johnson is making the MVC framework from his book (called Spring framework) an open source project because he was frustrated with all three of these.

2. I'm using EJB entity beans. You chose JDO and Hibernate. Can you comment on this decision?

3. Can you comment on other decisions you had to make that we might find controversial, and why you made those decisions?

I suspect many of us are dealing with questions arising from the tension between popularity (e.g. Struts) and beauty (aka supportability, programmability, etc.) (e.g. Maverick/Webwork). I'm always interested how people arise at such decisions. Open discussion of those decisions can help us all make better decisions in the future.

Thanks in advance for your reply.

0. I'd like to see such questions in http://romanpetrov.com/tiers/forum/ Have no time to read all forums :(
1. Flexibility - using Maverick you can select Struts or Webwork way just extending different classes. I don't like JSP (poor extending/reusing, fuzzy interface with Java Model). Maverick is not JSP/TagLibs oriented. Maverick is very good designed from my point of view.
2. I'm using JDO/Hibernate not vs Entity beans. JDO/Hibernate is just JDBC replacement. If Tiers will required complex cache (like cached user access rights) I'll add entity bean that communicate with database _via_Hibernate_too.
3. I can, post it, see 0.

That's a neat example for demonstrating the different parts of an enterprise app, but I think it also points out some of the major flaws in many J2EE apps (this is all IMHO, of course).

The first problem is that there are a number of different representations the business objects. Tools like XDoclet go a long way toward reducing the need to hand-code these objects, but they don't go far enough. For example, this app uses XDoclet but there are still representations of a Gadget in several places. If you update a Gadget to include a price, you'd have to update several files. Updating several files each time you make a change like this is a maintenance headache on even a medium-sized project. On large projects, that headache approaches nightmare status.

Another related problem is that there are a number of common patterns in most applications (create/read/update/delete an object). The pattern has to be implemented by hand for each object in the system. This results in a ton of helper classes for object creation, validation, display, etc. Maintaining those helper classes by hand is no fun, to say the least.

In most cases, you should be able to generate *all* representations of your object from a single, canonical definition (XMI, java object, whatever). Furthermore, you can generate the helper code that works with your objects. This includes code for database initialization and verification, all the way up through web or Swing forms.

Pervasive code generation is trickier to implement from scratch than a hand-coded app is, but it quickly pays off in many ways. For example, you can write a new generator and instantly add a new interface to your app. You can also switch databases or even persistence technologies if necessary - just add the proper generator. The best part about the generators, though, is that you're guaranteed a high-quality implementation of every object in your system (assuming you did an OK job w/ your generator).

Unlike much application code, generators can also be reused. They implement patterns, which are much easier to share in the real world than business objects are. This helps amortize the initial development cost of the generators.

Another gripe....the business code is implemented in technology-specific objects (session beans). While most people probably don't consider this to be a problem, in my experience it's been a real pain (especially when you get called in to reimplement someone else's broken "solution"!). IMHO the business code should be separate from all technology dependencies. If I need to switch from EJB to JDBC for persistence I shouldn't have to worry about making sure my business logic gets ported correctly - it shouldn't matter!

While this example app does a good job showing the different parts of an enterprise app, quite frankly I'd hate to use it. IMHO it uses a number of antipatterns that, unfortunately, are much more obvious to non-programmers than they are to programmers.

I don't claim to have a silver bullet, but the good news is that there are options. The code generators I described are one implementation of an Aspect-Oriented Programming model (the JBoss folk are pushing an interceptor-based implementation). My particular favorite implementation follows the SAND model for app development. It's technology-agnostic, and IMHO it's shockingly easy to develop apps with. Check it out the whitepapers at http://epinova.com. There's also an open-source implementation called Sandboss on Sourceforge (linked off the epinova site).

1. Gadget is _persistent_ data representation.
2. GadgetValue is _runtime_ business logic interface object
3. GadgetModel is just UI data
It's not good to couple these.

>Another related problem is that there are a number of common patterns in most applications (create/read/update/delete an object).

It's not common pattern. There are many different create/update/deletes. It depends on business logic.

>If I need to switch from EJB to JDBC for persistence I shouldn't have to worry about making sure my business logic gets ported correctly - it shouldn't matter!

I have some doubt in existing code generator with EJB to JDBC switching without any problems.

>I don't claim to have a silver bullet, but the good news is that there are options. The code generators I described are one implementation of an Aspect-Oriented Programming model

I'm not Aspect-Oriented Programming guru. Can people comment applicability of this?

2. GadgetValue is _runtime_ business logic interface object
3. GadgetModel is just UI data
It's not good to couple these.
 
Ah, but that's my point - IMHO, it's very important to couple them. They all represent the same set of attributes - an ID and a name. What if you need to add a field for price? You have to add that price field in several places (Gadget, GadgetValue, GadgetModel, etc). That's busywork, and it's an invitation to make mistakes. A gadget is a gadget, no matter what the representation. By using generators or other techniques, you can ensure that all of the different representations are always up-to-date. The gadget example already does this by using XDoclet to generate EJB classes (the generated interfaces are just another representation of the gadget itself). I'm suggesting applying the same concept to the entire application.


>It's not common pattern. There are many different create/update/deletes. It depends on business logic.
 
There are many individual c/r/u/d SQL statements in a given app, but in most apps I've seen all those statements look very much alike. A generator can write the SQL for you, guaranteeing that you never have to update the SQL by hand. This is effectively what an EJB container does for you already when you use CMP beans. (You can also generate CMP beans directly from your object definition by plugging in a CMP bean generator).


>I have some doubt in existing code generator with EJB to JDBC switching without any problems.
 
It sounds bad but it's not, I promise. I've actually done this. Remember, you're starting from a canonical definition of your object; the generators work off that definition. As long as your generators are written properly, you can plug in any persistence implementation you want without changing your code at all. Converting from EJB to JDBC is literally as simple as changing your build script, assuming you have the generators. On most medium to large projects, it's MUCH easier to write generators than to maintain dozens or even hundreds of objects by hand.

Hate to bust your bubble here, but isn't hibernate taking care of generating the SQL in this app?

Regards

Did I say it wasn't? That's besides the point, however. Hibernate is a big step forward, but using it still requires too much work (IMHO). Take a look at the getGadget() method in GadgetDAO. Now compare it to getUser() in UserDAO. Not much difference. Yet someone has to maintain those files separately.

Take another look at those DAO classes. How much work would it be to log each exception with Log4J? You'd have to add the exact same logging code to every single file. Not much work for 2 or 3 objects, but what if you had 10 objects? Or 100? Would you rather change 100 objects by hand, or change a single generator?

Another thing to ask yourself.....which do you think will be more consistent when given the task of changing those 100 objects? A developer or a generator?

The crud statements could all be easily refactored into the BaseDAO (or a different helper class) which would go a great deal towards simplifying the code (it's not actually complex now, but Hibernate uses application exceptions which causes all those catch blocks). Then all that would be left in the individual DAOs are the object specific finders.

An excellent book which shows an excellent example of this is Martin Fowler's Patterns of Enterprise Application Architecture. I highly recommend it for documenting and putting a name to pretty well every pattern used in this kind of environment...
http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/qid=1045714097/sr=8-2/ref=sr_8_2/104-9140530-2831958?v=glance&s=books&n=507846

Steve,

I agree 100% with your statements, but it's very hard to convince people about the advantages of using a code generator to take care of all of the boilerplate code you mention. There was a long discussion regarding this in another thread on TSS some time ago.

Stefan Tilkov
iQgen - The Model Driven Software Generator

Just to comment on the Maverick MVC,

I started to use it recently and I would say it is excellent. Very flexible, quite powerful out of the box and _very_ resonable to understand and extend.

The best part about it that it is also very pragmatic and agnostic in terms of your design choices. It does not impose specific execution pattern like Struts (single instance controller/multiple databeans) or very specific approach to data exchange like Webwork's valuestack.

From the configuration perspective it is enough to compare maverick.xml configuration file with Struts xml, or Webwork property files to see that it is quite compelling.

Source code also very easy to read, even for someone not familiar with code, I've found figuring out the way things work, is faster then composing email to mailing list. Got it working with Jakarta validator, Jasper Reports in no time.

Very happy user,
Michael

Michael@ITSolv.ca

Maverick is an excellent step toward untangling some of the unnecessary dependencies that were introduced by Struts et al and became popular solely due to the momentum rather than merit of the technology. If you are an architect who believes that Model should not be exposed to View and Controller should not be a choice between ActionServlet or nothing take a look at http://freemarker.org. Freemarker is a template engine designed to solve one and only one problem: presentation. It doesn't care how you structure your presentation (JSP, servlets, taglibs, XML), what you get (HTML, RTF, Java source code) or where it goes (HTTP, database, another app). Freemarker believes in freeing (pun intended) your model from the clutches of the presentation.

Alex
Freemarker PR agent