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 ]

Congratulations to the winners! Enjoy the book and let us know what you think.
Many thanks to JavaRanch for giving us the opportunity to discuss our
2nd edition this week. I have certainly enjoyed participating at JavaRanch.
I hope to stick around and stay tuned to this wonderful community.
Meanwhile, let me leave a few URLs that i hope will be useful to passers by.
Companion site for the book:
http://www.corej2eepatterns.com
To buy Core J2EE Patterns on Amazon:
http://www.amazon.com/exec/obidos/ASIN/0131422464/corej2eepatte-20
Join/participate at the J2EE Patterns Interest List @ Sun:
http://archives.java.sun.com/j2eepatterns-interest.html
J2EE Patterns Interest @ Sun is an interesting list community with
over 2000 active subscribers dedicated to the discussion of J2EE
patterns and related topics. The list is archived so you can
search/view past discussions/topics. Visit the above URL.
We (authors of Core J2EE Patterns) welcome feedback, comments, suggestions and questions. Email the authors at:
[email protected]
Thanks!

Originally posted by zb cong:
thanks
because i am the reader of the version1,so that i wonder what's the difference,addition or modification in the version2,then i will make the decision if i buy or borrow the book,could you give me more detailed instruction?

Hi,
You might want to check the replies to other readers with similar questions in the following topics:
https://coderanch.com/t/312304/EJB-JEE/java/Core-EE-questons
https://coderanch.com/t/312333/EJB-JEE/java/EE-Pattern

Originally posted by zb cong:
hello author:
i am the reader or your book(version1),i wonder if you introduce the work flow architecture in the version2,i need such code,but i know NOTHING about workflow,i think the MVC and workflow are parallel concepts,is it true?but i don't know the relationship between them,could you give me some instruction?
thank you

In the 2nd edition, we included a micro-architecture called Web Worker that discusses how you can integrate a workflow system into your web applications. Web worker uses several adapters (called Action adapters and Work Adapters) between the workflow system, users, and web application components.
This is explained in detail in the book so check it out when you get a chance.

The correct URL for Dan's reply (see above) is:
https://coderanch.com/t/98414/patterns/bean-or-not-bean

Originally posted by Arathi Raj:
Hi,
What does the book J2EE Pattern covers. What about EJB. Will this is good book for person who is new to EJB and J2EE.

Arathi,
You might want to check my reply to another topic in this forum on
the content of the book. Go to:
https://coderanch.com/t/312304/EJB-JEE/java/Core-EE-questons
(and scroll down to see my post/reply).
Hope this helps.

Originally posted by Pradeep Bhat:
What is refactoring ?
Is it re arranging the code so as to make maintenance easier?

Pradeep,
As Chris suggested, i would highly recommend Martin Fowler's "Refactoring" book. While his techniques are mostly related to code, we have used his approach and elevated it to a higher level of abstraction for J2EE. We discuss refactorings primarily as a way to improve existing design by applying one or more of the Core J2EE Patterns. We feel refactoring and patterns become a powerful pair of tools for application designers/developers to continuously evolve and improve your system. In our 2nd edition, we document 14 J2EE refactorings and continue to work in that area as we go forward.
As you mention, in addition to making maintainance easier, several other reasons for refactoring include (paraphrasing from Martin Fowler's book) design improvement, ease of understanding, maintainability, performance, fixing bugs, and productivity.

Originally posted by Pradeep Bhat:
How different is the book from the J2EE design patterns in the Sun site?

The book was recently released in June 2003 at JavaOne and is updated compared to the content on Sun site. I am assuming that the Sun site you are referring to is http://java.sun.com/blueprints/corej2eepatterns .
The book is a lot different from the Sun site at this time:
1. Book contains 21 patterns (i.e. 6 new patterns compared to the Sun site)
2. All the patterns from the 1st edition (Sun site) have been revised and updated with new strategies, UML diagrams and sample code.
2. Book contains other material that is not on the sun site such as:
2a. J2EE Refactorings
2b. J2EE Bad practices
2c. J2EE Design Considerations
2d. a new chapter on a newly introduced concept called Micro-architecture. We currently have documented in the book one micro-architecture called Web Worker for integrating workflow into your J2EE web applications. A Micro-architecture is a set of patterns used together to realize parts of a system. We view Micro-architecture as a prescriptive solution derived from linking a set of patterns.

This is in response Pradeep's question on the usefulness of Business Delegate (BD) pattern. We have been using BD in several projects for many years now.
As Lasse put it above, you have to judge when a pattern is useful or not based on your own requirements in your project. However, in addition to encapsulating remote business tier components (such as Session Facades), BDs have other usefulness in our applications:
1. BDs translate exceptions thrown by the business tier container (e.g. RemoteException) into more meaningful user friendly exceptions. This improves ease of use of business tier.
2. In large projects, BDs shield the Web/HTML/JSP/Taglib/UI programmers (who may not be EJB programmers) by providing a simpler object interface. This improves productivity.
3. In some cases where it makes sense, BDs can cache certain data making it unnecessary to re-invoke the business tier component. This can improve performance.
4. In cases of failure on the business tier (e.g EJB session timeout, etc.), BDs can recover by implementing retry logic as long as the problem is recoverable. This can improve availability.
Having said that, you have to weigh how useful the above features are against introducing the BD in your application as it will be another layer of objects between your client and the business tier. In most cases, this tradeoff (i.e. an extra layer) is outweighed by the benefits offered by the BD pattern.
Hope this helps reducing your hatred towards the BD :-)

John, Thanks for your questions. Please see my comments below.
Comments on Q1:
We have primarily tried to highlight the relationships between Core J2EE Patterns amongst themselves because it is a very powerful way to understand our pattern catalog. Understanding inter-relatioships between these patterns in the book will help our readers to link the patterns together to solve larger problems and eventually to build micro-architectures. In the "Related Patterns" section, we also try to highlight relationships to GoF patterns,
POSA (Patterns of Software Architecture: Vols. 1&2), and Patterns of Enterprise Architecture (Martin Fowler). If there are other patterns you see relationships to in PLoPD, etc., please let us know and we will look into including these references. You can email us at [email protected] to reach all the 3 authors.
Regarding a companion website, we do have one at http://www.corej2eepatterns.com under which we would gladly include additional information useful to our readers.
Comments on Q2:
CMR does impact Business Object pattern and in particular impacts the Composite Entity pattern. Composite Entity is closely related to the Business Object pattern as it discusses the best way to implement business objects using entity beans. We discuss CMR in Composite Entity where relevant. Perhaps, in a future edition, we might include a richer discussion as a strategy of the Composite Entity pattern.
Finally, regarding:

I would very much enjoy a companion website to include an extended Index into the text, or add and invite bleeding-edge strategies.

See comments above about companion site at http://www.corej2eepatterns.com . We would be happy to publish our reader's strategies under this site. Since we want to maintain cohesive information, we would be moderating such submissions. So please write to us about your strategies and we will publish them with proper attribution to you. You can email us at [email protected] .