Some thoughts about abstracting everything from everything
Hello,
For the last 3-4 months I've been picking JBoss Seam as the framework for my Java EE projects,
before this I was using some plain EJB3 + JPA approaches.
The overall stack of technologies looks like this (from Presentation Tier downto Resource Tier):
RichFaces
|
Facelets
|
JSF
|
EJB3
|
JPA
....with Seam being present somewhere throughout all these technologies.
Everything seems to be cool - the need for introducing some "glueing" components such as DAOs, DTOs, Service Locators etc.
seems to evaporate and all layers seem to cooperate pretty much well. BUT....
I really need (have) to keep a certain level of independence and loose coupling among the technologies used throughout the application tiers.
To my opinion the main issue with JBoss Seam seems to be the following:
The common practices assume the presence of Seam-specific annotations and JPA invocations in Session Beans,
which are being later called by JSF
Considering that Session Beans contain almost all the business logic of our application (for the case of Seam application),
this means that this business logic is coupled with both Seam by using at least its context management services
(e.g. @In @Out annotations for injecting/outjecting Seam components) and JPA by calling EntityManager methods directly
inside the methods of Session Beans
What I really need (have to) is the following:
Independence from the technologies in Persistence Layer (EIS Integration Tier):
My "data feeders" can be anything the human mind can imagine: RDBMS, XML Database, Plain Files, Legacy Systems via Proprietary Protocols etc.
Independence from Seam in my CORE business logic.
At the same time - keeping all the infrastructural services provided by Seam and EJB3
From my side I can suggest the following solution to this architectural problem:
To keep Session Bean sublayer dependent on Seam - there is no other way out,
I will call this sublayer "Seam Business Logic Integration Layer".
It's main purpose will be to integrate Business Logic Tier with Seam and EJB3 infrastructural services.
To move the core business logic into POJI/POJO implementations,
which will not use Seam/EJB3 annotations or other services + they will also not use JPA invocations.
Considering that we will not use @Name annotation for these POJOs and
that we will still need to inject them into Session EJBs, all these POJOs will be configured in components.xml as Seam components.
To introduce something called "Domain Model Facade" - abstraction from the underlying persistence technologies.
This facade will be presented as POJI for the core business logic (implemented as POJOs) and will provide
the basic methods related to data access operations (e.g. save, load, find etc.).
The underlying implementations will provide JPA, XML or JCA versions according to the configurations.
I will call this sublayer "Seam Domain Model Integration Layer".
Domain Model itself will be exposed to the core business logic as POJI/POJO combinations.
While at the same time - these classes can be configured in components.xml as Seam components
for enabling the context management services provided by Seam + referencing them in JSF pages.
What I really want to ask is the following:
Will this work?
For the case if it will work - maybe there are some existing and better approaches to this issue?
For example: something with Spring integration into all this mess for enabling the loose coupling between layers?
Or maybe it will introduce some much bigger mess...
Thanks in advance,
Oleg
