Slashdot Mirror
Building Java Enterprise Applications, Volume I
Summary: Building Java Enterprise Applications is an excellent book, and ought to be on the bookshelf of every J2EE programmer working on the mid- and back-tier. If you are like me, then you then have a series of books on various parts of the J2EE alphabet soup -- a few on EJB/JNDIs, one on JMS, one on RMI, one on JDBC, a database/SQL primer, a J2EE patterns book (I recommend Depur et al. by the way), maybe even some hyped-up case studies from Sun's press etc -- but nothing on how to design an entire J2EE application from scratch. There is nothing scarier than a blank piece of paper at the beginning of a project -- this book provides a combination of a tutorial and worked example, along with an insight into the thought processes of the designer.
There are not enough books of this type for the J2EE platform; the emphasis on tying together disparate technologies to build a coherent system is exactly what I need at this stage of my career, and I found the author's constant revisions and tweaking of his design fascinating and reassuring. I'm going to pre-order Vols. II and III.
Check your sources.
You might recognise the author's name -- Brett McLaughlin is the author of another O'Reilly title, Java & XML*, and writes for flashline.com, IBM Developer Works, JavaWorld and others. You can either Google for these or visit the web-site newInstance. In my opinion he knows his onions, is aware of what other root vegetables are out there, and, most important, he can communicate well.
What's the book about? I'll give you a bit of the blurb first, as it's a fair description of the material:
"Java has many enterprise APIs: JNDI, EJB, JMS, JAXP, and the other XML APIs, JDBC and more. But how do you as a developer put the pieces together and build something that works? How do these components integrate with back-end servers (databases and directories) and with front-end platforms (web servers and web services)?"
"[This] is Volume I of that series; it covers the business logic and back-end of an enterprise system, including entity EJBs, JDBC, JNDI (...), and JMS. Volume II will discuss architectures for web applications; Volume III will venture into the still-uncharted territory of web services."
That's quite an ambitious series; and something of a departure in style for O'Reilly, who have built their enviable reputation by providing definitive titles on one technology at a time. This more a book on when to use a tool, and which tool to use, rather than how to use a tool. I think it's good to see O'Reilly branching out in this way, but it brings them into the preserve of other publishers. It might be interesting to see how this new type of title does.
So what is covered in detail? Let's have a detailed look at the contents:
- Introduction
- Blueprints
This chapter outlines the case study that the author uses for the remainder of the book. This takes the form of a simple, but not trivial, financial-services tool. The blueprints are high-level sketches of the business need, the Data Layer, the Business Layer, and the Presentation Layer. - Foundation
This covers designing the data stores, databases and directory servers. - Entity Basics
Basic design patterns, coding and deploying beans. - Advanced Entities
IDs and CMP, data modeling and the nasty details. - Managers
Managers, in the facade sense, for entity beans and the LDAP directory. - Completing the data layer
Nasty details, populating the data store. - Business Logic
The facade pattern and stateful/stateless design. - Messaging and packaging
JMS on the client and server. Packaging. - Beyond flexibility
The wrap-up chapter, covers the major design points, discusses adapting the material to your own projects, and hints and what presentation layers may be added as a teaser for Vols. II and III.
As you can see there are no surprises in the contents. Once the high-level problem and solution is laid out, there's just a sensible progression through the layers. I particularly liked the practice of stopping and reviewing at regular checkpoints -- it helped tie the material together and emphasize the layering in the design.
There are some detailed appendices giving vendor specific instructions for databases, containers etc. This section also contains all the non-unique code for each layer, e.g., all the entity beans that weren't discussed in detail.
- SQL Scripts
Cloudscape, InstantDB, MySQL, Oracle, PostgreSQL. - SQL Deployment
Ditto. - Directory server setup
iPlanet, OpenLDAP. - Application server setup
BEA Weblogic only. - Supplemental code listings
All code also available in completed final form on the associated web-site.
Sounds wordy... It's not. This is a short book, only about 300 pages including appendices and index. (Compare that to something like Roman's classic EJB book ...) Chapter content is only 200 pages. Fully a third of the content of the book is code; this is definitely one for the programmer, those of you who delight in detailed breakdowns of requirements, user stories, schedules, etc will find little or nothing of interest here.
Equally, there is little in the way of explicit (non-coding) high-level design discussion -- all the code is evolved directly from the well-written text. This is not a bad thing at all -- the design seems sensible and straightforward, always a good sign, and mostly presents an admirable example to any young programmers watching.
All this doesn't mean you are reading a listing though. As on any
project involving EJBs, there is a lot of more-of-the-same code between
beans -- most of this code is concentrated in the appendices, and only
the material under discussion is presented. New code is always presented
in full, from package declaration to closing brace. This is
refreshing and permits you to actually get something working as you read
through the text, although you'll need to be prepared to set up app
servers, databases etc to get maximum benefit.
Target audience? Experienced Java programmers who have started using the J2EE platform and are fairly comfortable with all the bean types, JMS, JNDI etc. This book states several times that it is not a primer on any one technology, and provides ample references to more detailed texts when appropriate.
This is very much a book for a wannabe J2EE developer who can't quite figure out how to fit the pieces together, or, like me, just has a gap in his/her skillset when it comes, to, say, LDAP.
What's good? Lots of it. Mainly, the best thing is the clear presentation of a LOT of code via a well partitioned example application (which will also be re-used in Vols II and III). The code is of good quality too, and presents several idioms that while obvious now, were unknown to me when I started EJB work... with the usual reworking-over-a-weekend later on. In particular, there are some commonsense pieces of code -- like a nested exception class for those of us still using pre-1.4 (and remember, you're tied to what your app server supports), some simple session and entity bean
Adapter
classes, simple Value Object classes etc. As I said,
nothing earth-shatteringly novel, but it's nice to see a lot of these
idioms used together to simplify the code.
Another admirable thing about the book is the handling of the detail.
I've read several books which follow the practice of putting in
Gotcha! box-outs, and to be honest, few of them are that
useful unless you are a novice. I'm been programming for a few years now,
and was amazed at the silly difficulties I've had with my first EJB
project -- as a result I'm pleased to say that the box-outs indicating
problem areas sound like the voice of bitter experience. For example,
there is discussion on following the correct style for accessors/mutators
under CMP (getId works, getID cheerfully
fails), advice on the very fixed order in the deployment descriptor XML,
problems with case-sensitive searches in JNDI, etc. Those of you
who've worked with, particularly, EJB1.0/1.1, will undoubtedly have
groaned as you realised the problem de jour was something
simple-but-outside-your-code like those examples.
Admittedly it's not my area really, but I also found the whole treatment of directory servers very clear and useful. For the first time I understood (a) how they work (b) when they complement databases (c) how to use them easily from my code. Again, I admire the level of detail achieved without being confusing -- I don't see many introductory books include things like the default port number for directory servers using SSL (636 - well, I didn't know that!).
What's bad?
Not much. By nature of the book it doesn't go into huge detail on all technologies used -- there were a few areas where I wanted more. In particular I would have liked to have seen more on testing; now that XP is pretty much mainstream, no one can deny that unit testing is vital on production projects. (When I started using EJBs I had to kludge together a nasty version of JUnit which fitted into the sub-optimal build and client-server framework we were using. I've since found that there are better ways to test EJB layers, but I can still only think of one book, by Richard Hightower, which walks you through examples.) Although the build files in the example use Ant, which makes JUnit and other tools very easy to integrate, there is no mention of unit testing. This is a pity.
The only other things that caught my eye were minor -- coding style
in
particular. The coding style in the book is very straightforward and Sun-standard, but I have to admit that
I'd have liked more JavaDoc'ed code. The code on the website
is much more fully commented. I understand that printing this means more
paper, and thus a thicker and more expensive book, but on some of the
custom methods it would have clarified things for me.
In particular, and I'm being picky here, I didn't find that the
authors practice on handling nulls and errors fitted with my
own -- admittedly I don't so much practice "defensive coding" as
"paranoid coding." Most methods were not null safe, and that
can be a nightmare to debug in an n-tier system. Also, he
took the line of returning null to indicate failure or
error. I understand it's a valid design decision -- my experience says to
go with more explicit errors in a larger project, and I would have liked
a page or two on the choices here.
Another area where I feel there is room for improvement in the
presented style is in the use of hard-coded Strings for
lookups - for example, in the AccountManager object there
are several lookups of the AccountHome, e.g.:
AccountHome accountHome = (AccountHome)context.lookup(
"java:conp/env/ejb/AccountHome"; // Whoops, finding this can be tough!
From experience code reviewing EJB based projects, it's going to save a
lot of pain looking for typos if this repeated hard-coded
String is (a) extracted as a constant so it can only be
mistyped in one place and (b) refactored into a lookup method. It's a
fairly minor point, but useful to do right from the start on an EJB
project and worth pointing out to someone starting their first one.
(Mis-typed meta-data like this is a bit of a weakness in the J2EE
framework in my opinion - I always feel that I'd save a lot of time if
the compiler or some J2EE aware verifier could check over those
Strings to see if they match anything else in the build...
I've used vendor tools which claimed to do so, but as they didn't even
check that methods/lookup names were in the bean source I wasn't sure
what was being verified!)
One last thing: I know it's minor, but why the insistence on importing explicitly? I feel it makes maintenance more difficult -- change one LinkedList to an ArrayList and you're off fiddly with minor imports again. I also didn't find this:
import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import javax.jms.ObjectMessage; import javax.jms.Session; import javax.jms.TextMessage; import javax.jms.Topic; import javax.jms.TopicConnection; import javax.jms.TopicConnectionFactory; import javax.jms.TopicSession; import javax.jms.TopicSubscriber;as appropriate for a printed book as this:
import javax.jms.*;It would have been nice to trade those 10 lines wasted for some custom
JavaDoc. However, all told there is remarkably little to grumble about in this book -- I couldn't even spot the obligatory editorial mistake. (That really annoyed me.)
Alternate titles?
Can't think of a good one. (Either a sign that this book is one you might want to look at or else so completely specialised as to be of use to only one person in the world, and that person is probably the author. Luckily, I think it's the former in this case.)
It is however worth a trip to the bookstore for companion, as opposed to alternate, titles before reading this - it assumes detailed knowledge of several J2EE areas, but provides suggested (O'Reilly) titles for reference.
Sounds good -- but what do you know anyway?Time for the disclaimers. Some material in the book I found useful because I lack experience -- in particular, some database and LDAP stuff.
However, 5 years of getting paid to play^H^H^H^Hcode, and a personal reference library of some 120+ books has made it easier to spot the rare decent title! Most of my J2EE books are from my experience of EJBs for the last year or two, so I know what mistakes are easy to make, as I've made 'em. [I'm actually catching up on my reading, and hence reviewing, due to the Great Telecomms Downturn finally affecting me - anyone want a J2EE developer? :-) ] Finally, I paid for this book (which isn't the case for some of my other reviews).
You can purchase Building Java Enterprise Applications, Volume I from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
(* Bonus mini-review: a useful book, but not easy reading, I found it hard to slog through, but managed my first XLST work in about 10 minutes using it.)
what's the subtle message in the exclusion of iPlanet, WebSphere, JBoss, etc. with the summary line: "Application server setup - BEA Weblogic only"
no doubt in my mind BEA makes a helluva product, but i'm surprised the king of the open source publications doesn't have an entire section devoted to Building Enterprise Java Applications with _______ (insert your favorite jakarta packages here)
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
A lot of people seem to equate EJB/J2EE with dot-bombs. I think that's unfortunate, because it can be a really useful framework for development. Certainly there are times when people have overapplied EJB (used it where they shouldn't have) and there are also organizations whose projects get mired when trying to work in such a framework (but they are usually mired because they're sprawling projects, not because of the framework).
I tend to use 'slimmer' solutions than a full-blown framework like EJB (yes, I like 2- and 2.5-tier applications). ;-) But I would like to caution those who strike out at Java/EJB/J2EE as though it's just marketing speak. It ain't all a crock, and like anything that achieves some popularity it will attract idiots who will give others a bad impression.
Yeah, but reading it is easier, especially if you're skimming through or haven't read a particular chapter where they introduce all their constants. Obviously, good practice differs.
So that readers can see the exact dependencies of the class you're writing. In fact, I often write imports explicitly in production code as a form of documentation, but usually not for packages like java.io or packages where nearly every class is needed.
Handling nulls is crucial, but it also clutters the example and makes it longer (somewhat). I would look at it (if they'd included it) and known they were being defensive, but I could see another reader possibly mistaking it for a special case? But i assume page length was [probably the main reason.
Books can strive to give you as much code as possible, but really, you shouldn't use it (and many books have such disclaimers). You're not buying code, you're buying the ideas behind it, so code should be explanatory and descriptive rather than production ready. Some books come with utility libraries or include code from popular, well-used libraries, but even then never cut and paste book code into a production project!
I usually pay attention to their reviews, particularly when you can get at least 3 people responding.
5 96 001231/qid=1033485007/sr=1-1/ref=sr_1_1/103-198980 7-1175041?v=glance
http://www.amazon.com/exec/obidos/tg/detail/-/0
Not a great review; the primary complain is too many mistakes and typos.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Why? There's a fundamental issue at stake that Sun has partially solved, but not completely: What your application does should have nothing to do with how it does it.
For example, take the "bank account" app that I've seen used as a tutorial in many places. Customers can have one or more accounts, and they can perform operations on those accounts (deposit, withdraw, transfer). The code necessary for those operations is trivial. It's the support code that makes writing enterprise apps so difficult. At the minimum, you need:
You'll probably want to expose a few other interfaces, like an API for your app to be used on a message bus so other apps can access it.
It sucks to have to write all of that extra code. It gets even worse if you have to modify your app (add/delete fields, features, etc). Sun is slowly chipping away pieces of the problem (EJB sort-of makes persistence easy, unless you need stored procs, etc), but they haven't solved one of the big the underlying issues:
The application has data that can exist in multiple representations. Each representation requires work to make sure it's always in sync with the rest of the representations.
There's an easy way out - define your data, and let the computer generate the different representations for you. While you're at it, have the computer write the code that can convert data in one format to another format. This is obvious for things like going from one XML format to another, but not so obvious when trying to convert a web form into a java object, or a java object into a database record.
By defining your data and using code generators or other automation techniques (reflection) to create those different representations, you can slash maintenance costs, time to add new features, etc. Want to add a new field to an object? Update the canonical representation of the object, and presto, your entire app supports it, from the web UI down to the DB schema. Want to add a new data format? Write a generator for it, and all of your objects automatically support that new format.
The overhead is higher at first, but it pays off incredibly quickly. On my last project we saved many many man-years by doing this. Check out thesandbossproject for an LGPL set of tools to help out with this, based on the SAND architecture.
(Yes, I've glossed over about a zillion issues. It's not that I havent thought of them, it's that the problems are solvable. The main point is that your data representations should always be in sync with each other, without your lifting a finger. And no, UML doesn't quite get you there yet).