[Freebilling-discuss] EJB Experiment

[Kostas Maistrelis]

The goal is:


PRESENTATION/INTERACTION
       |
APPLICATION SPECIFIC
       |
DATA MODEL
       |
PERSISTENT LAYER


###in the DATA MODEL model classes we have the constraints and the 
###Logic of object

###int the PERSISTENT LAYER: we Have only the constraints for the Database or
###the other media that we have for persistent.



with  the experiment of addition of EJB SERVER I  suggest:


PRESENTATION/INTERACTION (CLIENT)
       |   
SESION BEANS ADAPTERS
       |
APPLICATION SPECIFIC
       |
DATA MODEL
       |
PERSISTENT LAYER



For the MVC data entry app, I think we have:

CLIENT : view
SESIONS BEAN ADAPTERS: controler sesion bean adapter to DATA MODEL controler
DATA MODEL : controler, model
PERSISTENT LAYER :  controler, finder, data interfaces


I think the SESION BEAN ADAPTERS like a remote interface for our
data_model/application_spesific code


ABOUT ENTITY BEANS

http://java.sun.com/products/jdo/JDOCMPFAQ.html
the Sun wrote:
-------------------------------------------
What EJB adds to JDO is management of distributed transactions, security, 
and distributed execution. When you use JDO classes developed 
for use outside EJB, there is no requirement to rewrite them for 
use inside EJB. There is no requirement to use Entity beans 
if the JDO classes contain all of the functionality needed by session beans.

A reason to use Entity beans to wrap JDO classes (using a BMP delegate strategy)
is to allow the JDO classes to be remotely accessible directly, 
rather than through a session facade. This implies a higher 
degree of autonomy and functionality in the JDO classes.
-------------------------------------------

Change the word JDO with Persistent Layer

I think that for our model is beter the session facade solution because we
have the data model intact and reusable.
Additionally i think that is not good idea to have remote access 
to Perssistent Classes Directly