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]