We Are Done With Layers - Now Start With Plugins

With Java EE 5 the architectural style changed drastically. Superfluous layers and indirections are an exception, rather than the mainstream. Even hard core ivory tower architects accepted, that with EJB 3 and JPA there is no more need for additional adapters and encapsulations.

But: even in small, "situational" applications there is desire to introduce plugins and modules. The question: "Why you need it?" and "What problem are you solving with that?" is rarely answered. In the J2EE era we were already exactly in the same situation. The more layers were introduced, the better was the architecture (at least this was the common believe at that time).

Now the amount of layers and tiers was dramatically reduced, and we try to introduce more and more (dynamic loadable) components into a layer. The plugins are encapsulated with interfaces - to introduce a lean indirection between them. But exactly this already implies a service oriented character of the application: Services and Service Facades can very easily communicate across plugins via interfaces. But it is nearly impossible to spread related JPA-entities across different plugins - the JPA managed relations between entities are modeled directly, without any interfaces between. And you will have to solve some interesting ClassLoader and Persistence-Unit challenges: it is hardly possible to load related JPA-Entities with several classloaders. ...and you will have to decide which plugin / module have to contain the persistence.xml. 

Considering all the challenges, I don't think that such an architecture would be the easiest possible solution - and so harder to maintain. If there is a need to Protect the Variations, plugins, modules etc. are the perfect solution. But there should be always a clear defined reason for introducing additional, technical complexity.

I was involved in several Eclipse RCP / Netbeans RCP projects - but we always had to disable the Update Manager at the end of the projects. It turned out that it was too hard for the end user to manage the plugins and for the operations to maintain their dependencies. Building plugins is not a big deal - the real problem you will get afterwards - they have to be versioned and maintained properly. This challenge can even kill a SOA project...

[See also "Premature Encapsulation Is The Root Of All Evil",  page 253 in Real World Java EE Patterns - Rethinking Best Practices

NEW online workshop: WebStandards Igniter (online)

Airport MUC workshops: Java EE 8, Java 9: Bootstrap, Effective, Architectures, Single Page Apps, Progressive Web Apps, HTML 5, ES 6, CSS 3 and Microservices

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns


Hi Adam,

well there is a small problem that raises up, when you like to build a shared domain model.

Sometimes you build up a security model with Principal, Role, Group Entities etc.

You could place these entities in a separate persistence unit and build a separate service. So you will have a complete encapsulated module (as in DDD) for this case.

But wait! Don't expect, that another module with entities in a different persistence unit can access these security entities.

Say, there is a Profile entity that stores some user-specific preferences. You might assert that you can draw a OneToOne Relationship between Profile and Principle, but you can't, cause it's a different PU.

Well... what you're doing now? You mess up your encapsulations and provide the security module in the same PU as the profile module.

And there's another pitfall:
The security module is inside it's own maven module, where the persistence.xml is placed inside the maven artifact (ejb) meta-inf.

Your profile module depends (maven) on the security module, so the ejb is refered inside the Manifest.MF of the profile module's ejb.

So in this case you have to remove the persistence.xml's from the ejb's and place it in the ear, so that it is valid for all ejb.

Hmmm... I don't think, that this is a good way to modularize your app. So maybe the JCP will focus on this problem for the next spec versions.


Posted by Robert on August 21, 2009 at 02:20 PM CEST #

"Even hard core ivory tower architects accepted, that with EJB 3 and JPA there is no more need for additional adapters and encapsulations."

... huhu, I wish this was true ... unfortunately I am not experiencing this in the trenches of enterprise-IT where I am stuck ... :-)

I have already seen several "architectures" that try to encapsulate/abstract/hide Hibernate/JPA or even EJB3 ...

Posted by Jonas Bandi on August 21, 2009 at 02:24 PM CEST #

Hi Adam,
I am starting to learn REST web services using Jersey, the RI-implementation in NetBeans using JPA.
This kind of architecture is new to me so I have some questions for you.
What do you mean with "we are done with layers" ?

Do you think there shouldn't be anymore say a "business layer" or a "security layer" somehow ?
How and where to implement this functionalities then ?

Posted by Guido on August 21, 2009 at 08:24 PM CEST #


You will need at least a boundary. See: http://www.adam-bien.com/roller/abien/entry/simplest_possible_ejb_3_13



Posted by Adam Bien on August 22, 2009 at 02:19 PM CEST #

Hi Adam,

"But it is nearly impossible to spread related JPA-entities across different plugins"

What are your thoughts on best practices when it comes to developing, packaging, and deploying entities?

Would you advocate creating a separate IDE project exclusively for JPA entities that produces a single jpa-entity.jar, upon which other projects depend? Or do you place JPA entities in the appropriate subsystem or component project? In which case you need a commons project as a catch-all for cross-cutting entities with no real logical home. For example, you may have cross-cutting entities, such as Language or Currency, that multiple subsystems (for example, Catalogue and Orders) depend upon.



Posted by Adam Bien on August 28, 2009 at 01:03 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments