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 23 transaction support, and start transactions 22 upon entering the service layer, propagating 21 down to the DAO call's. The Service layer 20 has the most bussines model knowledge, and 19 the DAO's do relatively simple CRUD work.

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

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

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

Sorry 2 it's shorter than your post, hope you find 1 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 5 Java Code as long as possible. One can do 4 fusion of web services here.

XML/JSon Data Transformation Layer :

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

Persistence Layer :

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

Here's my 5 cents

Presentation

Android, Angular.JS WebClient, OAUTHv2

API

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

Business Logic

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

DAO

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

Database

MySQL, Memcached, Redis

What we have followed in our project is 1 :

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 37 stack.

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

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

Most of business projects 22 have three types of interfaces (note: not 21 GUI, it is a programatic java interface 20 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 19 is easy to replace one implementation of 18 module with another. This helps us adopt 17 to different clients and integrate more 16 easily. Some clients will buy only certain 15 modules and we need to integrate functionality 14 they already have. Since interface and implementation 13 layer are separated, it is easy to roll 12 out ad-hock module implementation for that 11 specific client without affecting dependant 10 modules. And Spring Framework makes it easy 9 to inject different implementation.

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

Here is one more web architecture I have worked on:

One major requirement was the application 10 should support mobiles/other devices. The 9 application should also be extensible or 8 flexible to changes in technology choices.

Presentation Tier:

• JSP/JQuery (Client-side MVC)
• Native Android
• Native iPhone

• Mobile 7 web (HTML5/CSS3/Responsive design)

• Spring 6 REST Controllers (Can change to JAX-RS)

Business Service Tier:

Spring 5 @Service (Can change to Stateless EJB)

Data Access Tier:

Spring 4 @Repository (Can change to Stateless EJB)

Resource Tier:

Hibernate(JPA) entities 3 (Can change to any ORM)

You can find more 2 information on the book which follows this 1 architecture here.

IMHO, most of us have a common denominator. Atleast 20 in the back-end, we have some form of IOC/DI 19 container and a persistence framework. Personally 18 I use Guice and Mybatis for this. The differences 17 are in how we implement the view/UI/presentation 16 layer. There are 2 major options here (may 15 be more) .. Action based (URLs mapped to 14 controllers) and component based. Currently 13 am using component based presentation layer 12 (using wicket). It perfectly mimics a desktop 11 environment where I use components and events 10 as opposed to URLs and controllers. Am currently 9 looking for a reason why I should migrate 8 to this URL-controller kind of architecture 7 (that's how I ended up on this page). Why 6 the hype about RESTful and Stateless architectures.

To 5 answer this question in short: I write stateful 4 web applications using a component oriented 3 framework on top of Guice IOC container 2 and put data in relational database using 1 Mybatis.

A bit different, and I would claim more 12 modular java architecture here. We have:

1. Spring WS/Rest/JSP front end
2. Spring MVC for business service logic, containing presentation layer logic as well as Spring transactions
3. Component service communication interface, looked up through EJB by business services. EJBs set their own transaction boundaries that are able to join Spring transactions.
4. Component service implementations, again Spring components
5. Integration layer, MyBatis for database integrations, Spring WS for web service integrations, other integration techonologies for other services
6. Mainframes, databases, other services at other servers...

In 11 addition to the above, we have the shared 10 library modules which is common functionality 9 provider for all srevices.

Use of different 8 layers allows us full decoupling and the 7 modularity we need. We are also able to 6 fully utilize the power of Java EE as well 5 as Spring. Nothing prevents us from using 4 JSF, for example, for the front end if needed.

Compared 3 to example architecture by OP, I think this 2 can be described as having four main layers 1 instead of three, albeit with a twist.

I've worked on projects that use that rigid 28 manager pattern. Historically, I was a 27 huge proponent of the rigid hierarchy where 26 everything fit into a neat box. As I progress 25 in my career I find it to be forced in a 24 lot of cases. I believe that adopting a 23 more agile mindset towards application design 22 leads to a better product. What I mean by 21 this creating a set of classes that solve 20 the problem at hand. Rather than saying 19 "Did you build a manager for this and that?"

The 18 current project I'm working on is a web 17 app with a combination of Spring MVC and 16 RestEasy JSON/Ajax calls. On the server 15 side embedded in our controllers is a sensible 14 facade based data tier with JPA/Hibernate 13 for direct Database access, some EJB access, and 12 some SOAP based web service calls. Tying 11 all this together is some custom java controller 10 code that determines what to serialize as 9 JSON and return to the client.

We spend 8 almost no time attempting to create some 7 unified pattern instead opting to adopt 6 the "Worse is Better" idea of the Unix Design 5 Philosophy. Being that its much better to 4 color outside the lines and build something 3 sensible, quickly than it is to build something 2 that adheres to a bunch of strict design 1 mandates.

The components in Web Application Architecture include :

1 : Browser 3 : Client interaction

        HTML
        JavaScript
        Stylesheet

2 : Internet

3 : Webserver

        CSS
        Image
        Pages(Java render )

4 2 : Application Server

        App Webapp (Java interaction)
        Others WebApps

5 : Database 1 Server

        Oracle, SQL, MySQL

6 : Data