Describe the architecture you use for Java web applications? [closed]

Question

Ok I'll do a (shorter) one:

• Frontend : Tapestry (3 for older projects, 5 for newer projects)
• Business layer: Spring
• DAO's : Ibatis
• Database : Oracle

We use Sping transaction support, and start transactions upon entering the service layer, propagating down to the DAO call's. The Service layer has the most bussines model knowledge, and the DAO's do relatively simple CRUD work.

Some more complicated query stuff is handled by more complicated queries in the backend for performance reasons.

Advantages of using Spring in our case is that we can have country/language dependant instances, which are behind a Spring Proxy class. Based on the user in the session, the correct country/language implementation is used when doing a call.

Transaction management is nearly transparent, rollback on runtime exceptions. We use unchecked exceptions as much as possible. We used to do checked exceptions, but with the introduction of Spring I see the benefits of unchecked exceptions, only handling exceptions when you can. It avoids a lot of boilerplate "catch/rethrow" or "throws" stuff.

Sorry it's shorter than your post, hope you find this interesting...

Ideal Java Based Web Development Technologies Today.

Web Layer :

HTML+CSS+Ajax+JQuery

RESTFul Web Controller/Action/Request Processing Layer :

Play Framework

Business Logic/Service Layer:

Use Pure Java Code as long as possible. One can do fusion of web services here.

XML/JSon Data Transformation Layer :

XMLTool(Search On Google Code),JSoup,Google GSon,XStream,JOOX (Search On Google Code)

Persistence Layer :

CRUD : JPA or SienaProject or QueryDSL / Complex Queries : JOOQ,QueryDSL

Here's my 5 cents

Presentation

Android, Angular.JS WebClient, OAUTHv2

API

REST, Jersey (JAX-RS), Jackson (JSON de-/serialisation), DTO-objects (different from business logic models)

Business Logic

Spring for DI and Event handling. DDD-ish approach of model objects. Longer running jobs are offloaded with SQS in worker-modules.

DAO

Repository model with Spring JDBC-templates to store Entities. Redis (JEDIS) for Leaderboards, using Ordered Lists. Memcache for Token Store.

Database

MySQL, Memcached, Redis

What we have followed in our project is :

Front end Technology

• AngularJS
• HTML5
• css3
• Javascript
• Bootstrap 3

API

1. REST
2. JERSEY (JAX-RS)
3. REST ASSURED
4. SPRING BOOT
5. Jackson
6. spring security

Business Logic

• SPRING DATA

• SPRING data MongoDB

Data base

• MongoDB

Server (For caching)

• redis

We are still using the usual Struts-Spring-Hibernate stack.

For future apps, we are looking into Spring Web Flow + Spring MVC + Hibernate or Spring + Hibernate + Web Services with Flex front end.

A distinct characteristic of our architecture is modularization. We have a number of modules, some starting with 3 to max 30 tables in the database. Most of modules consist of business and web project. Business project holds business and persistence logic while web holds presentation logic.
On logical level, there are three layers: Business, Persistence and Presentation.
Dependencies:
Presentation depends on Business and Persistence.
Persistence depends on Business.
Business does not depend on other layers.

Most of business projects have three types of interfaces (note: not GUI, it is a programatic java interface layer).

1. Interface that presentation is using as a client
2. Interface that other modules are using when they are the client of the module.
3. Interface that can be used for administrative purposes of the module.

Often, 1 extends 2. This way, it is easy to replace one implementation of module with another. This helps us adopt to different clients and integrate more easily. Some clients will buy only certain modules and we need to integrate functionality they already have. Since interface and implementation layer are separated, it is easy to roll out ad-hock module implementation for that specific client without affecting dependant modules. And Spring Framework makes it easy to inject different implementation.

Our business layer is based on POJOs. One tendency I am observing is that these POJOs resemble DTOs. We suffer from anaemic domain model. I am not quite sure why is this happening but it can be due to simplicity of problem domain of many of our modules, most of the work is CRUD or due to developers preferring to place logic somewhere else.