This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I have kept Stateless SB at Business logic layer. I have a DAO and DAOImpl where JPA Enitity manager gets created and the respective Entities as well.
1)As DAO comes under Integration pattern , I have put DAO components under Integration tier.
2)But ,I have a another view that , as these DAOs are associated to persistence context ,this shall be put under persistence tier which can be clubbed together with Business logic tier and can be addressed as one Business Logic & Persistence tier. No need for integration tier ?
I feel it's a thin line to distinguish .Your thoughts please ?
As an architect you are free to design in a way that you see fit. Just remember that you need to justify their decisions. So there's no way to answer this kind of question.
For example: I disagree with you:
Stateless SB can't be business layer! If you do your business layer as Stateless SB, you'll be tying the rules of business of the solution in the EJB technology. In my opinion as an architect, a business rule should be written in Java as Pure POJO.
As I told you, every architect has their point of view.
If you need to study design issues, I advise you to read books on the subject:
1. POJO in Action Book by Chris Richardson Book.
2. Domain Drive Design by Erick Vans Book.
3. Patterns of Enterprise Application Architecture by Martin Fowler Book.
While searching through the forum I chanced upon this and it sort of took me by surprise. While I do understand that the Session beans (Stateful/Stateless) are meant to encapsulate the business logic of the application - where do you think they stand to be in the component diagram? Is it unacceptable to put the EJBs in the business layer in the component diagram? This confuses me.
Which brings me to my second question - Is the component diagram supposed to show the classes that I have used in the class diagram? I thought it is supposed to be a level "above" the class diagram (which probably means that I'd make "boxes" that could house those classes without naming them) - Or is it a common, acceptable (and risk-free) practice to liberally show the classes and their stereotypes in the component diagram?