Expert One-On-One J2EE Design and Development by Rod Johnson looks at things that work and don't work in the real world, with frank discussion of the pros and cons of EJB, the problems with entity beans and how to work efficiently with relational databases.

The book is Available on Amazon.com.

More info
-----------------------------
Expert One-On-One J2EE Design and Development</a> isn't just a rehash of J2EE patterns. It takes a fresh look at design and development in J2EE 1.3, based on practical experience, not just theory. This book explains why the problems encountered in many J2EE projects result from bad practice, and how to avoid them.

If you're following the J2EE vs .NET performance controversy on this site, you'll be particularly interested in this book. It addresses performance issues head on. After reading this book, you'll understand why Microsoft's .NET version of the Pet Store outperforms Sun's, and how you can design J2EE applications that perform just as well.

Topics covered include:
- When to use a distributed architecture, as opposed to a collocated architectures. Distributed architectures are slower and harder to implement and maintain. This book looks at how to decide when we need the power of a distributed architecture, and when we can implement a simpler, web application architecture. Many books and articles ignore this fundamental choice (suggesting distributed, EJB architectures as the default choice), yet it has an enormous impact on project outcomes.
- When to use EJB. This book offers a dispassionate discussion of the pros and cons of EJBs, why they're a good solution to some problems and overkill in many applications.
- How to choose between remote and local interfaces, if using EJB
- How to access RDBMSs efficiently. The book looks at the drawbacks of entity beans, and alternatives that offer better performance. It looks at when--and how--to use JDBC, and when it's appropriate to use stored procedures. It also touches on JDO and O/R mapping solutions such as TopLink.
- Good practice in web interface, such as MVC and how to use JSP
- How to ensure that J2EE applications are OO applications. It's easy to get caught up in the details of EJB and other J2EE details, and forget that good OO design is essential to successful J2EE projects.
- Writing maintainable code in J2EE applications
- Testing J2EE applications

There's a sample chapter on the Wrox site.

Rod, I am looking forward to getting this book, which I've had on order at Amazon.co.uk since you meantioned it on another thread. The sample chapter looks brilliant. Do you have any idea when amazon.co.uk will get it in?

Another question is whether a CD with the book text is available for buyers. Or a downloadable version for purchasers of the dead tree version. This is useful because it is searchable, so I can bring up all references to a topic with a simple search. It also reduces my mule-load when I start a new gig..... ;-)

Brilliant achievement, I think. I love the idea that the experience can be encapsulated in a book. I loved the predecessor, the Tom Kyte Oracle book.

Keep up the good work. I hope it sells a million!

Don, thanks for your encouragement. Writing it was a hard slog, and it's good to get some positive feedback!

I'll check with Wrox when Amazon.co.uk will have it. It was printed in the US, so it's already shipping there.

I'm pretty sure that Wrox don't produce CDs, but I'll check with the editor whether purchasers will be eligible for a PDF. I think they may have some plans in this area.

1 word for this book --> AWESOME.

it gave me a tons of lightbulb for a bunch of doubts and questions that i have been having in mind for any j2ee development.

this book is something that worth to read. i really enjoy it. thankx for writing this book... awesome......

Great job Rod :-) to tell you the truth, it is a great intro. chapter. good work

Never trust this muslim's word!
Adel Alrashidi tells lies. Plus (s)he hasn't read any part of the book yet.

Stop trying to troll on this message board and go and post on www.f*ckedcompany.com

David

@Gotya: You deserve to get banned from this board/website for your stupid comment.

that was a stupid comment

It doesn't stand to reason to start debating you on this now, because as others said, your post was stupid enough. But let's be objective about this anyway:

1. What do you know about Adel to start accusing him of telling lies? And how do you know he didn't read the book? the book has been released for almost a month now, and I think this is enough to get the book and read good part of it. On the other hand, the book now has an Amazon sales rank of 575, although the book is only a month there, which tells you that it is actually a good book.

2. Adel wasn't telling about the book, his exact words were that the book has a good intro and sample chapter, he didn't mention the whole book. You are accusing a person with something he didn't say buddy, this clearly reveals more about your character not his.

3. Tell me why you don't trust Muslims? I bet a person like you who totally lost reason to discern what a post like that would like if posted, isn't qualified to judge on Muslims.

4. It's Muslims my friend who brought trust to this stupid world you live. It's you and the like who work on defaming it by spreading such thoughts.

I don't think there should be any action against you on this website, I think you better keep what left of your face's water and disappear for good. This is an educated community, there is no place for people like you here.

I think you disserve a response with the same "measure" as your "smart" post. Using your "specification style" in the last century, and not only unfortunately, smart people like you decided that others will be better to be used as soap in the bathrooms.
 As long as you can't understand and accept peoples I'm sure you can't understand IT Science so f..k off and disappear from this site ... here is not place for Nazis ...
or go to a psychological treatment if you are so stressed ... as Cameron P. always tries to remember us we should be people of peace and mind ...

funny, no response from Gotya -"THE HERO"....
I thought hero's were meant to be brave, but your comments
were not only stupid but cowardly too,
Obviously you have your issues, I suggest you take a good look at yourself before you discriminate others.

getting back to business, Im looking forward to reading the book looks very promising

for french readers:

http://www.uzine.net/article1032.html

Looks great! The sample chapter is clear and gives an excellent overview of J2EE application choices.

I look forward to getting the book.

Many of the things you mention in your excerpt are consistent with some of the confusion and doubt I have experienced, especially with regard to the use of entity beans and their role vs. JDO. The J2EE spec is in every way a work in progress and its refreshing to finally hear someone willing to discuss the potholes that do exist, not only the benefits of J2EE. I think this book would be very helpful to beginner and experienced J2EE developers alike!

I had the extreme pleasure of reviewing the whole book. I would say it is *THE* best J2EE book I have ever read (I have read quite a few). There are really great chapters on using JDBC, plain old Java Beans and a Java bean based configuration framework, different web application frameworks, debate on using JSPs compared to other templating technologies and a lot more. I would strongly recommend this book as it would be an immense resource to any J2EE developer/designer/architect.

Guys, all of you could not be wrong. This book is going to be the next after finishing the one I am reading.

I loved chapter 1. The criticism of EJB the author makes confirms what I have been suspecting for some time now:
EJBs are evil, and should be avoided at all costs, except in a few cases. However, even in these cases EJBs won't be the best option, in the next few years (SOAP/web services will be a better option for synchronous remoting).

I didn't quite agree with some recommendations, though (not relating to EJB):
1. Always using interfaces instead of concrete classes: I think this decision should be made on a case by case basis, according to business requirements. Concrete classes are a simpler solution, and with refactoring tools (such as IntelliJ IDEA 3.0), changing client code when the implementation needs to change is not too difficult.
2. The use of the central servlet approach (a.k.a "Front Controller), as in Struts. I am convinced the "Page Controller" pattern (see Patterns of Enterprise Application Architecture) is a much simpler and more effective solution, in virtually all cases. (BTW, I think people will eventually realize, just like they did for EJB, that the design of Struts is un-optimal, to say the least.)

Rogerio, thanks for your comments.

1.One reason I think there's a particularly strong case for using interfaces in Java is because Java only allows concrete inheritance from a single superclass. As we remember from C++, this is a wise decision, but it does mean that we have a major problem if we ever want to "inherit" from more than one class.

Interfaces give us the best of both worlds. It's possible to provide convenient abstract superclasses, allowing extension, while letting developers decide if they want to implement the interface from scratch for any reason. IDEs also make it easy to work with interfaces, stubbing implementations.

This is ultimately a matter of taste. However, in many projects I've found rigorous application of an interface-oriented approach to deliver excellent results, especially where JavaBeans are concerned. The flexibility *is* beneficial. And I've not found it to reduce productivity. In Chapter 4 I discuss the pros and cons in more detail and discuss cases where I'd prefer concrete inheritance.

2. I'm not a great fan of Struts either, but this is to do with its implementation. However, I am a firm believer in the MVC model. The Page Controller approach that Martin Fowler discusses is natural in ASP.NET, which practically enforces it, but I can't see its merits where J2EE is concerned. I used to use it myself, but abandoned it a couple of years ago. I dislike the idea of a JSP initiating request handling. A few considerations that spring to mind:
- It's JSP-centric. What if we want to use XSLT or Velocity to render content?
- The slight simplification of the default view being the JSP itself doesn't really simplify things much, but ends up being counter-intuitive when the request does need to go to another view. I regard this as a bigger negative than the slight simplification is a positive.
- Having an MVC framework can make it easier to configure helpers (actions) than activating them via JSPs. And once you're up and running--with a blank project for example--the complexity isn't very great.
- Why does control code belong to one view? If you want to replace that view completely, you need to cut and paste the action handler tag/whatever out of it and put it into the new view.

Martin Fowler does note that the Front Controller works better for more complex control logic. My experience is that Page Controllers never get refactored as interface omplexity grows (which it will) and that, except in simple applications, it's better to adopt a more powerful approach up front.

Regards, Rod

Rod, thanks for the informative reply!

I think we ultimately agree on the use of interfaces versus concrete classes. Interfaces do improve the flexibility of the design, but sometimes this flexibility goes unused, in which case a design based on classes alone would have been more productive (even if not by much).
I was thinking of the XP principles of simplicity (choose the simplest design that meets the requirements) and courage (believe that you can refactor later to add more flexibility if needed, without cost overruns).

As for the Page Controller, I believe it can (and should) be used in the context of an MVC-based web app framework, just like the Front Controller typically is. (I am also a firm believer in MVC. :-)
In fact, I have created a JSP-based web app framework that uses the Page Controller as its main pattern. And yes, this is similar to the concepts of "Web form" and "code-behind" in ASP.NET. (My framework, however, differs from ASP.NET in several respects.) In my experience, the Page Controller, when properly used, leads to a simpler solution than the Front Controller, and with no less flexibility:
- It's JSP centric, and this is a good thing in the most typical situation, when you embed HTML code in the JSP page. XSLT could still be used inside the page, through special custom JSP tags (as I do in my framework). If the entire outbound page is generated with XSLT, though, I wouldn't use the Page Controller. Some points to explain my view:
- Page Controller requires the use of a custom JSP tag of the form "<xx:page code='example.OrderController'/>" on the top of every JSP page (or containing the page in its body).
This tag is responsible for calling the appropriate action method in the "example.OrderController" class, after populating an associated model object with any request parameters. The JSP page should not contain any Java code (scriplets).
- This depends on UI design, but in many cases only one view (the JSP page itself) is required. Therefore, no need to forward the request when using Page Controller. For cases where you need to forward it, a simple solution is to have the action methods return a string containing a file path or URL for the next page. This may be a little confusing for the first time user, but once understood, is a lot easier to use and configure than the Struts actions.
- When an action method returns a URL, the target JSP page can be configured in web.xml, through an "url-mapping" entry. Note how simpler this is, when compared to Struts (which, when you look deeply, replicates a lot of functionality of web.xml).
- The page controller class can be reused for different views (JSPs). It's also possible to have multiple JSPs using the same controller class. I haven't yet designed this, but I believe you can also nest pages (and their page controllers), therefore creating the effect of multiple controllers for the same top-level page.

I think the Page Controller will be more used for J2EE web applications in the future. It's just a matter of frameworks, such as the one I described above, becoming more popular. Maybe WebWork will, or something similar to ASP.NET (although I personally don't like some of the design choices made for ASP.NET).

Anyway, I am looking forward to read your book (as well as Martin Fowler's new book) in the following weeks. I suspect these are going to be the two best books on enterprise applications to come out this year!

Regards,
  Rogerio

where I can get the free pdf doc?

I've been looking of some .aspx code, and I find the PageController pattern really very interesting.
Less more complex that framework like struts/webwork.
Do you have any place where I can download your implementation of this pattern.
thanx in advance

Rogerio -

<quote>
EJBs are evil, and should be avoided at all costs, except in a few cases. However, even in these cases EJBs won't be the best option, in the next few years (SOAP/web services will be a better option for synchronous remoting).
</quote>

As someone who uses EJBs very successfully (including entity beans) I couldn't disagree with you more. Many people confuse EJBs with persistence only and end up using them in either inappropriate ways or situations.

Now, that said, it is absolutely true that they are not to be used everywhere and in every application, another mistake commonly made, especially in the early days of J2EE. However, used correctly, in the right situations they can be of great service. While they may not always (for instance) be appropriate for web apps, there are classes of enterprise applications where they are very appropriate (I do EAI/warehousing - a very big market in application development). So don't use them if you don't want to, but certainly don't call them evil as that spreads mis-information.

Cheers
Ray

I use EntityBeans as an integration mechanism. Databases are the most obvious usage of this, but for other corporate systems - mainframes, TPMs, middleware, Corba systems - they work very well also. You can perform transactions, including distributed transactions, and can easily set the caching characteristics of the data to increase performance and scalability. Fortune 1000 companies have a lot of data and legacy functionality that can't just be ignored. EJBs are a very good way to develop new applications that work with these existing systems.

Sounds like a great book. I'm definitely going to check it out.

-Scott

Hello Rod,

I had the pleasure of reading several chapters of your book and must say that this is the best book on J2EE development I have read, even better than Core J2EE Patterns. It is refreshing to read a book that cuts through the marketing hype and covers the practicalities of each J2EE technology, written by someone who has been in the trenches working with each technology. Bravo! I've came to many of the same conclusions too over the years. I also like the general discussions of methodologies, app servers, and DBMSes, important topics in any application development effort that are typically ignored by J2EE development books.

My only question - when will the Wrox website have have the code download for your book?

Stephan, The code download should be there in the next 2 or 3 days. My apologies to everyone for the delay. Also, I'm hoping to set up a web site which will offer updated versions of the code, articles etc.

Somebody asked about a PDF... I'll discuss this with the editor. I can't promise a free PDF, but we have considered serializing the whole thing.

- Rod

Free PDF for a potential best seller from Wrox? That will be a first if you can pull that off. I will never dream about it!

Anyway, congratulations to you Rod for a job well done. I got my copy from Bookpool last night and started reading the Entity Beans chapter right away. What I found is a very practical, informative chapter detailing the pros and cons of using entity beans. A pleasant read to say the least.

If some Java book series technical editor (or .NET editor for that matter) from Wrox is reading this thread - try to publish 2 to 3 Expert One-on-One books each year, instead of 2 to 3 dozen useless multi-author titles by fresh out of school people. Save some trees if nothing else!

Or certainly a reduced priced downloadable PDF would be good (like the JBoss books).

Rod,

The sample chapter is great. It confirm all my more or less fuzzy un-well-though-out-thoughts (but not un-practical) with insights full, well formulated logic. It is obvious that you have extensive experience from the trenches. I have ordered the book. I shudder when I think of all the real world solutions that use routinely the so called "classic" J2EE architecture (Distributed Application with Remote EJBs, entity beans and all) for everything, which they did get more or less automatically as generated code out the box.

The Page Controller system in .NET is very irritating that it is the page that calls the code and not the other way around. The code should not only call the page but depending on logic be able to call any page it wants. I hope that is fixed in the upcoming version 1.1.

Regards
Rolf Tollerud

Rolf, thanks for your comments. I agree, a lot of J2EE applications are too complex. It's good to have all those options, but it doesn't mean we should always use them. It is a very practical book, so I hope you'll enjoy the rest of it!

I agree about the ASP.NET approach. I was really keen to see how Microsoft had approached things in cleaning up ASP, and I was a bit disappointed. Some of the code examples I've seen in .NET sites are scary, with lots of HTML in C# classes. I hope they do improve this in 1.1.