Composite Entity Pattern

[Joseph Jegan]

Composite Entity Pattern (one of Core J2EE patterns) can be implemented only by BMP. We cannot implement through CMP. Any thoughts?

[Pradeep bhatt]

EJB 2.0 CMP uses local interfaces so there is no need for Composite Entity pattern.

[Bill Dudney]

Hi All,
I totall agree with Pradeep, the Composite Entity pattern is an antipattern if you are using EJB 2.0 (Depak Alur, from the Core J2EE Patterns book disagrees though).

[Zkr Ryz]

Looks interesting.
Could somene provide me a link where this pattern ( anti pattern ) is described ?

[Bill Dudney]

Hi Zkr,
Composit Entity is the pattern. The AntiPattern is documented in the entity chapter of the AntiPatterns book.

[Chris Mathews]

Originally posted by Bill Dudney:
Hi All,
I totall agree with Pradeep, the Composite Entity pattern is an antipattern if you are using EJB 2.0 (Depak Alur, from the Core J2EE Patterns book disagrees though).

What I find interesting is how even the Core J2EE Patterns authors go out of their way to avoid Entity Beans in real projects. Case in point, look at the architecture for the ultra-massive EBay J2EE rewrite (which Depak was lead on), not a single Entity Bean in sight. :roll:
[ November 19, 2003: Message edited by: Chris Mathews ]

[Deepak Alur]

Originally posted by Chris Mathews:

What I find interesting is how even the Core J2EE Patterns authors go out of their way to avoid Entity Beans in real projects. Case in point, look at the architecture for the ultra-massive EBay J2EE rewrite (which Depak was lead on), not a single Entity Bean in sight. :roll:
[ November 19, 2003: Message edited by: Chris Mathews ]

Hi Chris,
Interesting, but you are overstating and oversimplifying the eBay example :-) The decision to not use entity beans at eBay was made jointly with eBay architects. There wasn't any no going out of the way to avoid it. We had long and serious discussions at eBay and finally made the decision not to use it. I believe that you have to choose the technology to solve the business problem and not just choose the technology for technology sake.
Besides eBay, there are other projects that i have worked on where entity beans made sense and were used. Unfortunately, those case studies are not public (yet).
Composite Entity pattern describes just a set of best practices for usage of entity beans. People confuse it to be an anti-pattern, but it is not. What becomes wrong is if you use the Composite Entity pattern and implement the entity beans as remote entity beans. Perhaps, this is why people confuse it and say it is an anti-pattern. In the 2nd Edition of our book, this pattern was revised to address EJB 2.x as the previous edition only addressed EJB 1.1.
Composite Entity is used when you implement your Business Objects (another pattern we documented in the 2nd Edition) using entity beans. We explain it in detail in Core J2EE Patterns and i summarized it here in another thread on our J2EE patterns interest listserv.
Hope this helps clarify.
[ November 19, 2003: Message edited by: Deepak Alur ]

[Pradeep bhatt]

Deepak,
Thanks for posting at this hour (I beleive that it is late night for you. )
I was reading you book core J2EE pattern last, (Thanks for writing a great book and hope to have Bill's antipattern as it's pair) where in Composite Entity pattern local interfaces(CMR) are mentioned.I am not sure why you have made it as pattern. It woule be great if you let me know the reason.
Also, I have a question on Session facade as acting as a proxy to Entity bean. There are cases where we do not have any business logic in the session bean so it wil just be a proxy to Entity. I feel that this proxy is unnecessary but you talk about maintenance problem. Can you please elaborate more
Thanks

[Bill Dudney]

Hey Depak!
Great to see you on-line. How do you have time to read and post here? Glad that you do though
I think CompositEntity is only an AntiPattern when you use a graph of POJO's behind the local facade. This kind of implementation leads to really nasty API's (IMO) and painful maintenance, especially on deep object graphs. If someone really needs to 'aggregate' their POJO's perhaps the object model is too fine grained to begin with and needs some refactoring to become a more reasonable design.
Exposing an entity through a session facade that is devoid of business logic is captured as AntiPattern 'Transparent Facade'. Without knowing your full requirements its hard to answer exactly but generally it is a bad idea to just add another layer over your entities that does nothing but delegate. This is one of the examples in the presentation and sample code that I gave at the No Fluff symposium this year (every thing is avalible on my blog).
If I read it correctly the next part of your question is 'why not expose my EJB Entity remotely since it is an independent encapsulated entity?' Well again not knowing your requirements and implementation details its hard to say exactly but I'll offer some general guidlines. First make sure that your Entity is a coherent abstraction, inother words make sure that it is focused on providing one kind of thing for your application. If it is providing many 'things' (or abstractions) then chances are maintenance will be harder than it should be. Second the principal behind using the Session Facade in this situation would be to have a place to put multiple calls to the Entity in one transaction context so that the client is not managing that context. So a place for you to look is in the clients of this Entity, if they are making multiple calls to the entity in one 'logical transaction' then you probably need a session facade. Third, if your entity is never called from anywhere but the client then perhaps your entity is really a stateful session? I Hope this is helpful and not just muddying the waters!
Pradeep - don't put the Pattern and AntiPattern books right next to each other, I've heard bad things happen, someing about matter & anti-matter

[Pradeep bhatt]

Pradeep - don't put the Pattern and AntiPattern books right next to each other, I've heard bad things happen, someing about matter & anti-matter

Dont worry I will keep them separate from each other. Which one to read first Bill- Anti pattern or pattern?

[Bill Dudney]

Not sure which one to read first. I'd say if you are in maintenance mode or ongoing development mode the antipatterns would be more bang for the buck right now. If you are doing green field development then I'd say the patterns book is better for you right now.

[Dan Malks]

Hi Bill,
Sorry we missed eachother at the No Fluff Conference several weeks back. :-)
Good recommendation on pairing the books, though I'd hate to leave the impression that our book (Core J2EE Patterns) is most beneficial for green-field development, since that's actually rarely the context in which it is used.
In fact, we cover Bad Practices, Design Considerations, and specific J2EE Refactorings in addition to the numerous code-level pattern strategies, so there's really lots of content that's valuable to ongoing development as well as new projects...moreover, since patterns should be used *judiciously* and often are a target for a specific refactoring, gaining an understanding of the patterns at any point is valuable b/c it helps shape your approach (ie: if you know about a pattern and its strategies, you might choose to opt for a basic implementation strategy at first, with the understanding you might introduce something more sophisticated down the road, depending on requirements...the point being, if you know about the options, you can make an informed decision about what fits best... )
Finally, for those of us that practice incremental and iterative approaches to software dev, the notion of "green field" dev becomes somewhat arbitrary, since one ends up iterating through areas of development, such that you're really cycling through a bunch of smaller pieces, each time moving forward and starting afresh from a stable build of code, turning the crank a bit each time toward your final goal.
Thanks
[ November 20, 2003: Message edited by: Dan Malks ]

[Bill Dudney]

Hi Dan!
Next time we will have to make a plan. Are you going to be on the tour next year? I heard good stuff about your talk. I'm bumbed out I missed it. I can't wait to see what matures out of micro-architectures!
You are right about green field development. Something does not stay green field for long since we move in and start muddying up the water Your book has a hallowed spot on my shelf and I use it all the time, green field or not. I was trying to say I guess that if you are starting from scratch inorder to get a good view of what should be done, the Patterns book is the place to start. It will help you avoid most of the AnitPatterns in the first place (except for that Composite Entity pattern .
On another related topic Joshua Kerievsky has a great book started that discusses refactoring to patterns. It is not J2EE specific but there is a ton of good info there on how to really use patterns to make your code better.
Anyway thanks for responding and I hope we can hang out at the next NFJS!