Remembering the Future

Excessive layering plagues many Java applications because they submit to the component and container dichotomy. Containers inevitably produce layers because they are so darned intrusive; combined with so-called good programming practices the result is walls have to be thrown up to protect the mythically valuable business logic from the implementation details of the Container. There's been an enormous pushback against intrusive Containers that's culminated in JPA: it's now finally possible to write fairly complex Java applications that do non-trivial database work without messing with deployment descriptors, interfaces, and other container gobbleygook. This pushback against intrusive containers should evolve into a pushback against layers. You can already see this in the latest next-generation frameworks like JBoss Seam where all sorts of magic is employed to seamlessly (one wonders why they called it Seam?) merge the view, domain and persistence layers into a single coherent body.

. . .

Rather than N-tiers of a single monolithic application you're much more likely to end up with M-islands of services connected by some sort of bus (in SOA) or by a uniform interface (in REST).

Topics: j2ee | Architecture

Labels: Architecture, J2EE, Layers