This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am kinda stuck with the design of part 2. I cannot decide what to use for data access layer for the assignment. I am hezitating between the choice to go with entity beans or to use DAO with. Does SCEA Part 2 actually requires that to use Entity Beans? or can I say that I here is the Domain model for the application and I will use O/R mapping tool for example?
No reason you can't take the non-ejb/orm approach to your persistence so long as you justify your decisions as to why that is preferable to entity ejb's in your particular situation (extensibility/flexibility might be reasons to not prefer entity ejb).
If you are using complex transactions then maybe entity CMP ejb's are a sensible option. If you do decide to use pojo/orm persistence maybe you will then maybe need to introduce Spring DI for transaction management, but if you're using an EJB container anyway why not just use entity ejb and take advantage of the features of the j2ee container?
I beg to differ. I strongly recommend you to stick with services provided by the J2EE platform. You may use CMP Entity beans or a a BMP DAO. Even if it works, I urge you not to use Hibernate, iBatis or other O/R mapping tools. If you model a DAO, then you can still use a OR tool beneath the DAO layer, but just don't explicitly include it in your design.
If you go back and read the assignment instructions, you will notice that they make an explicit point about "J2EE based solution".
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
YEs but an ORM such as hibernate *does* use J2EE under the hood (ie JDBC, JTA etc) so it's really just a case of layer indirection. However if you stick with "pure J2EE' solution you can't go wrong.
Joined: Mar 09, 2005
Thank you very much guys! Yes I have also noticed that the instruction says: "Remember the most important requirement of all: it must be J2EE".
I am reading the book "J2EE Architect handbook" by Derec C. Ashmore. He makes two separate layers - Deployment Layer and Business Logic layer. In Deployment layer he puts all the EJBs and Business Logic he implements as plain java objects. He strongly promotes the idea that Business logic must be deployment independent and selfcontained - meaning that there should not be dependencies on the JNDI lookups and other J2EE stuff in business logic layer.
Looking back on my experience from using CORBA and RMI, I agree with him that business logic should be deployment independent. And I used this approach in my design. I want to make the my business logic independent on what I will be using for persistence.
It looks like if I go with entity beans design I won't be able to accomplish such independence for business layer. Unless I come up with some wrappers to wrap all entity beans stuff.
Hi Vlad, in your first posting you wundered about entity EJB vs. DAO, but now I read about business logic:
Originally posted by Vlad eroshin: He strongly promotes the idea that Business logic must be deployment independent and selfcontained - meaning that
For clustered servers you might prefere a session EJB being a pure/poor Session Facade. That is all what JNDI goes to - not much.
For doing the business logic you may choose remote Session EJBs as well (allowing for further clustering of parts of the business logic if via remote interface), or local Session EJBs, or just local POJOs, all trhee realizing the Business Tier.
This Business Tier accesses Entity EJBs and / or DAOs of the Enterprise Integration / Data Access Tier that in turn access db tables or other resources in EIS / Data Tier.
Originally posted by Vlad eroshin: ... Derec C. Ashmore. He makes two separate layers - Deployment Layer and Business Logic layer. In Deployment layer he puts all the EJBs and Business Logic he implements as plain java objects.
Is he talking about tiers or about layers? In Suns three dimensional cube tiers are vertical (Client, Presentation, Business, Data Access, Data Tier) and layers are horizontal like transport layer.
In my world his Deployment layer would just be the Session Facade EJB mentioned above for Business Tier, right?
And for Data Access Tier there would be a Deployment layer only if using EJBs, not for DAOs?
How Deployment layer is defined? That what we need a deployment descriptor for?