Who didn't use SLSB for DAO?

[jianming chen]

I think I'm taking huge risk to not using SLSB for DAOs.

DAO is suppose to be used in integration tier, and provides a unify the interface for accessing any kind of resources, such as LDAP, WEB service, DB, etc. So I created a DAO Factory to load all kinds of DAOs, and put all DAOs under intergration tier. Then the consequences is I have to do lookup to get EntityManager inside DB DAOs, rather than using kind of standard way to inject EntityManager into SLSB.

[Jaime Bravo]

It's a good idea to make a slsb a DAO for CRUD like a facade for BuzzEntities...all the time ;)
DOn't use service locator from DAO, you must prefer injection so the solution is slsb anyway...you know
regards!

[jianming chen]

But what is the problem of putting DAO in the integration tier. Those DAOs will be still used by service tier SLSB. And EntityManager instances are transaction based, as long as the transaction started from SLSB, it is safe to lookup EntityManager inside any classes.

I think to separate DAOs from SLSB will create better separation. Another argument is if you create DAO from SLSB, then you need to manage transaction attributes for DAO methods. Good practice is you should only declare transaction from Service tier. What's more, if you create DAO from SLSB, that means, client can probably skip other service tier wrapper SLSB to directly call those DAO SLSBs.

[Jaime Bravo]

he bro...i like your way to discuss....nice
well my answers are:
1. DAO is a pattern and not only the artifact.

2. On the other side, SLSB is an artifact and not the service tier, itself. So without problems, an SLSB could be in integration tier.

3. "And EntityManager instances are transaction based, as long as the transaction started from SLSB, it is safe to lookup EntityManager inside any classes.". OK, JTA is all about to associate a transaction with a thread. So if you do a JNDI look up on the same thread then, the EM automatically will register with the TM.

But actually look up a dependency from inside the DAO class is not a good practice, because you're creating a dependency with the lookup mechanism and details about the same one. And this fact adds another responsability to the DAO class, that is: find its dependencies. So the class becomes less cohesive. For example if you change the JNDI name for the dependendy then....you know. So Dependency Injection pattern is the winner against the Service Locator pattern.

4. "if you create DAO from SLSB, then you need to manage transaction attributes for DAO methods. Good practice is you should only declare transaction from Service tier.". Transactions like security is a cross-cutting concern so it could be present in any tier(including presentation, bussiness, integration and resources tiers of course)

For example JMS operations can be transacted and, WS supports transaction throught the OASIS specs and another standards.

5. "What's more, if you create DAO from SLSB, that means, client can probably skip other service tier wrapper SLSB to directly call those DAO SLSBs. " You can prevent that situation. Take a look to this code:

//Transfer Object
public interface CustomerTO extends Serializable {
   Long getId();
   String getName();
   ...
}
//Entity
@Entity
public class Customer {
    @Generated
    private long id;
    ....
}

//DAO interface
@Local
public interface CustomerDAO {
   CustomerTO findById(Long id);
   CustomerTO persist(CustomerTO cust);
}

//DAO Impl
@Stateless
@TransactionAttribute(SUPPORTS)
public class CustomerDAOBean implements CustomerDAO {

    @PersistenceContext(unitName="CustomerPU")
    private EntityManager em;

    @Resource(name="singleton/TOFactory")
    private TOFactory factory;

    public CustomerTO findById(Long id) {
        Customer entity = em.find(Customer.class, id);
        return (entity == null)? null : factory.newCustomerTO(entity);
    }

    @TransactionAttribute(MANDATORY)
    public CustomerTO persist(CustomerTO cust) {
        Customer entity = new Customer();
        entity.setName(cust.getName());
        ...
        em.persist(entity);
        return factory.newCustomer(entity);
    }
}

//App service interface
@Local
public interface CustomerAppService {
   CustomerTO findCustomerById(Long id);
   CustomerTO persistCustomer(CustomerTO cust);
}

//App Service Impl
@Stateless
public class CustomerAppServiceBean implements CustomerAppService {

    @EJB
    private CustomerDAO customerDAO;

    @TransactionAttribute(SUPPORTS)
    public CustomerTO findCustomerById(Long id){
        return customerDAO.findById(id);
    }

    public CustomerTO persistCustomer(CustomerTO cust){
        return customerDAO.persist(cust);
    }
}

//Session Facade interface
@Remote
public interface CustomerFacade {
   CustomerTO findCustomerById(Long id);
   CustomerTO persistCustomer(CustomerTO cust);
}

//Session Facade Impl
@Stateless
public class CustomerFacadeBean implements CustomerFacade {

    @EJB
    private CustomerAppService service;

    @TransactionAttribute(SUPPORTS)
    public CustomerTO findCustomerById(Long id){
        return service.findCustomerById(id);
    }

    public CustomerTO persistCustomer(CustomerTO cust){
       return service.prsistCustomer(cust);
    }
}

regards!

[jianming chen]

Jaime Bravo wrote:
1. DAO is a pattern and not only the artifact.

Yes, but DAO is an integration tier pattern. Based on the DAO pattern definition on Core J2EE Pattern, Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

Jaime Bravo wrote:
2. On the other side, SLSB is an artifact and not the service tier, itself. So without problems, an SLSB could be in integration tier.

I think the idea of injecting EntityManager into SB is kind of mixing business tier and integration tier. The boundary of each tier is not clear any more. The major benefits of EJB container are security, transaction management. So it's best for business tier. DAO layer should be able to site outside of EJB container. Probably you want to re-use DAO component in other project deployed outside of EJB container.

DAO pattern should provide unified interface for any kind of resources. It doesn't make much sense to wrap any other resource accessing code inside SLSB. Such as LDAP access, Web service client etc.

Jaime Bravo wrote:
But actually look up a dependency from inside the DAO class is not a good practice, because you're creating a dependency with the lookup mechanism and details about the same one. And this fact adds another responsability to the DAO class, that is: find its dependencies. So the class becomes less cohesive. For example if you change the JNDI name for the dependendy then....you know. So Dependency Injection pattern is the winner against the Service Locator pattern.

Before EJB container can specify other classed inside DI context, I'd rather use other DI provider to manage dependencies in DAO layer.

4. "if you create DAO from SLSB, then you need to manage transaction attributes for DAO methods. Good practice is you should only declare transaction from Service tier.". Transactions like security is a cross-cutting concern so it could be present in any tier(including presentation, bussiness, integration and resources tiers of course)

For example JMS operations can be transacted and, WS supports transaction throught the OASIS specs and another standards.

Jaime Bravo wrote:
5. "What's more, if you create DAO from SLSB, that means, client can probably skip other service tier wrapper SLSB to directly call those DAO SLSBs. " You can prevent that situation. Take a look to this code:

Client could be the upper tier running inside same container. "Local" wouldn't avoid those clients directly access SLSB DAOs.

[Dumitru Postoronca]

jianming chen wrote:
Yes, but DAO is an integration tier pattern. Based on the DAO pattern definition on Core J2EE Pattern, Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

And in JEE applications, the container manages the connection. Don't take the definition in such a literal way. Also, just because it's called integration tier, it doesn't mean it can't live in the same environment as the business tier (same ear, same technology - SLSBs).

jianming chen wrote:

Jaime Bravo wrote:
2. On the other side, SLSB is an artifact and not the service tier, itself. So without problems, an SLSB could be in integration tier.

I think the idea of injecting EntityManager into SB is kind of mixing business tier and integration tier. The boundary of each tier is not clear any more. The major benefits of EJB container are security, transaction management. So it's best for business tier. DAO layer should be able to site outside of EJB container. Probably you want to re-use DAO component in other project deployed outside of EJB container.

1. Do you have such a requirement?
2. Reuse can also be about reuse within the same application, it doesn't automatically mean that it has to be across projects. Your design makes it (slightly) harder to reuse within the same application.

jianming chen wrote:
DAO pattern should provide unified interface for any kind of resources. It doesn't make much sense to wrap any other resource accessing code inside SLSB. Such as LDAP access, Web service client etc.

True, but DB access is transactional, as opposed to LDAP. Also, one could wrap LDAP acess in a SLSB because you get thread safety with a simple annotation.

jianming chen wrote:

Jaime Bravo wrote:
But actually look up a dependency from inside the DAO class is not a good practice, because you're creating a dependency with the lookup mechanism and details about the same one. And this fact adds another responsability to the DAO class, that is: find its dependencies. So the class becomes less cohesive. For example if you change the JNDI name for the dependendy then....you know. So Dependency Injection pattern is the winner against the Service Locator pattern.

Before EJB container can specify other classed inside DI context, I'd rather use other DI provider to manage dependencies in DAO layer.

You are adding one more dependency to your project, instead of reusing the existing dependecy on the EJB container.


To conclude, my opinion is that it's a bad idea.

[jianming chen]

1. Do you have such a requirement?

We do have requirement like this. Sometimes we want to create some sort of quick tool outside of the Web Application which requires access to the database. Or sometimes Swing application.

You are adding one more dependency to your project, instead of reusing the existing dependecy on the EJB container.

As a matter of fact, before EJB 3, we have created application with Session bean in business tier, and Spring + hibernate dao in the integration tier.

[ntumba lobo]

Client could be the upper tier running inside same container. "Local" wouldn't avoid those clients directly access SLSB DAOs.

There is nothing wrong for a local client to bypass a SB layer to access directly a DAO.
Assuming you SB layer adds value in addition to calling the DAO, this extra value may not be needed to serve all the requests.
In that case you can have your Session Facade (local client) calling directly a DAO.

If you have a look to the Session Facade pattern, it can call ANY business component (BO, DAO, Application Service,SB ...)

[Dumitru Postoronca]

jianming chen wrote:

1. Do you have such a requirement?

We do have requirement like this. Sometimes we want to create some sort of quick tool outside of the Web Application which requires access to the database. Or sometimes Swing application.

My advice to you is to stick with the requirements in the assignment.

[Luay Abdulraheem]

So what you are saying Jaime, Session Bean(service) ===> Stateless Session Bean(DAO) ===> JPA ?
1) Is this applicable if the Session Bean(service) is Stateful ?
2) Is there really a need for the DAO layer at all ?
Thanks alot..

[Jaime Bravo]

So what you are saying Jaime, Session Bean(service) ===> Stateless Session Bean(DAO) ===> JPA ?

yes that is the idea. The DAO tier hides the data access mechanism, in this case JPA but it also could be JDBC, iBatis, Hibernate, flat file or JNDI/LDAP and so. There's nothing new about this, i'm only applying core j2ee patterns

Is this applicable if the Session Bean(service) is Stateful ?

There's no point to use a stateful EJB because the DAO bean is to be used as a facade for the entity managers and entity classes, in this case of JPA use. It's not a component intended to be a client extension like the stateful beans are.

Is there really a need for the DAO layer at all ?

Of course, you could require to change internal representation from JPA to Hibernate or to make part of it based on JDBC or to include other data sources like LDAP. Or still better you could provide mock implementation for DAO facades to facilitate the parallel development between the DAO tier and another tiers with dependencies to it. Not to use DAO means to create dependencies to persistence mechanism within tiers not requiring to know about that, hurting the low coupling.

regards!

[Luay Abdulraheem]

Thanks !

What I meant was :
Suppose I'm using a Stateful Session Bean to handle my business, and I want to add a DAO layer.

Is it applicable : Stateful Session Bean(Business Tier) ===> Stateless Session Bean(DAO"Integration Tier") ===> JPA ?

P.S.: Am I the only one who is thinking about using Stateful Session Beans or WHAT ?!

[Jaime Bravo]

hahahaha you probably are the only one thinking about using a stateful bean as service facade basically, they are not so scalables like the stateless ones are, mainly by the instance pooling facility in the last ones

[Luay Abdulraheem]

Yes but let me ask a question just to clarify what a stateful "cart" means ! please comment whether I'm right or wrong..

1) Suppose there is a system for designing wedding cards, a person can log in his own account and choose from different designs and add fonts, pictures, ...etc to his wedding card. This is a stateful "cart" scenario, right?

2) Another system, in the traffic department, the employee in the department uses a system to register cars for many people waiting in line. This is stateless scenario, right?

Not to forget that BluePrints best practice is to maintain session state in stateful session in EJB centric applications, and HTTP session in web centric applications.

I'm I right or wrong ?

OR !

should I ask if there is an application client and to maintain the state we use stateful, otherwise use stateless ... you know what... I'm opening a new topic on the forum