• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Query : Component Diagram

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ranch Hand
Posts: 497
2
Spring Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sankar

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.

Best Regard.
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stateless SB can't be business layer!


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?

Thanks,
Aditya
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic