Separation of Presentation and Business Tiers with Spring

Question

Hi there,

In my just-completed project, I was working getting distributed transactions working.

We implemented this using JBoss's Arjuna Transaction Manager, and Spring's declarative transaction boundaries.

Our request sequence looked like:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

What this meant is that we had a WAR to serve our secured servlet and an EAR to serve our SLSB.

Our SLSB had a static initialiser block to bootstrap our Spring application context.

I don't like the mix of technologies, but I do like the separation of presentation and business tiers, which could reside on different physical locations.

I would be interested to know what others propose to separate tiers when using Spring?

Answer 1

Requiring an EJB3 app server just for a SLSB that is a facade doesn't seem like it's worth the effort to me. There is no reason you couldn't just remove that and have your servlet work directly with Spring. You can add the ContextLoaderListener to the WAR to load your ApplicationContext and then WebApplicationContextUtils to get at it. Alternatively you could use SpringMVC, Struts or other web technologies if you need to do more than what the Servlet on its own will allow for.

Answer 2

A pretty typical approach is to define a web tier, a service tier and a DAO tier, and attach transactional semantics to the service tier. The service tier might be a bunch of POJOs with @Transactional annotations, for example. The web tier might be Spring Web MVC controllers. In this approach, the web tier is essentially adapting the service tier to HTTP. Good separation and no need for SLSBs here.

One area of debate though is with respect to the domain objects, like Employee or PurchaseOrder or whatever. These span application tiers and one thing that seems to be happening with annotations is that the domain objects get annotations that are tied to specific tiers. So you might have ORM annotations here but then use the same domain object as a form-backing bean as a way to avoid parallel domain/form object classes. Some people object to that as violating architectural separation of concerns.