Slashdot Mirror

← Back to Stories (view on slashdot.org)

Server-Based Java Programming

Posted by timothy on from the community-service dept.

Craig Pfeifer wrote this review of Server-Based Java Programming, and in a world of books loaded with buzzwords, and sometimes volume at the expense of clarity, he claims that this volume suffers neither fault. (Even if you're sick of the word "Enterprise.")

Server-Based Java Programming author Ted Neward pages 556 publisher Manning rating 10 reviewer Craig Pfeifer ISBN 1884777716 summary From designing and building the nuts and bolts of your own java application server, to understanding and integrating common middleware technologies and patterns, this book covers it all.

The Scenario

Whether you're building your own Java application server, or evaluating your options when it comes to building an enterprise class application, there's an awful lot to consider. Everyone likes to throw around the adjective 'enterprise'; 'enterprise class,' 'enterprise information system,' 'enterprise solution' but what does this mean? What is an enterprise solution? And more importantly how do you build one? This book cuts through the J2EE hype and gives you the straight dope on desiging/implementing realistic java based distributed systems.

What's Bad?

If you are looking for a Java2 Enterprise Edition (J2EE) overview (Enterprise Java Beans (EJB), Servlets, Java Server Pages (JSP)...) or an intro to Java fundamentals, this book is not for you. This book covers some fundamentals of threads, classloaders and sockets, but the bulk of the text is the application of these concepts. If you aren't already familliar with how these features are commonly used, you might find yourself doing a little prerequisite work to get the full value out of the material in these chapters.

Additionally, several code samples span multiple pages and it can be tough to keep this sample (along with all of the previous samples, as they build on each other) in your head when you read it in more than one sitting. This could be remedied by presenting a series of UML diagrams to show how the current example extends or interfaces with the previous examples, and the existing classes in the Java SDK.

What's Good?

This book goes from narrow to broad in it's coverage of different aspects of enterprise systems. Ted starts off chapter 1 with a wonderful overview of what characterizes 'enterprise development,' and 'enterprise systems.' According to Ted, enterprise development projects:

  • get less QA time
  • have shorted development cycles
  • typically require expert administration
  • must work within an existing architecture

From here, he goes into a discussion of key build vs. buy decision criteria and a justification/defense of using Java on the server side. This first chapter should be torn out and given to every development manager in every internal IT department in every company everywhere. Many managers feel that any project dealing with 'enterprise' and 'java' require a product like IBM's webSphere or BEA's webLogic, but this is simply not the case. These are excellent products, but for most of the projects out there, basing a solution around a full blown J2EE appserver only makes building, deploying and maintaining the system more far more complicated and expensive that it really needs to be.

Just as I started to worry that this book would be all talk and hand-waving, the next two chapters (approx 60 pages) were a gloves-off, down and dirty discussion of Java's classloader functionality. Many developers take the classloader for granted (including myself), and don't fully understand/exploit its power. Ted shows all of the rules that a Java classloader must follow, and the role it plays in the application lifecycle. He builds sample classloaders that can load classes from an HTTP server, an FTP server and even from an internal hashtable. The most impressive part of these two chapters is Ted's explanation of how the differences between the Java 1.1 and the Java2 classloader. This illustrates Ted's depth of the Java platform, and is just one example of the knowledge (not just information) that this book is chock full of. Ted's sample classloaders are the foundation of the Generic Java Application Server (GJAS) that you build as you progress through the book.

In the next few chapters Ted takes on his two other major topics for the book: threading, and sockets. These topics are worthy of entire books on their own, but Ted keeps it focused and talks primarily about how they are applied in the context of an enterprise application server. He doesn't just rehash the threading and sockets APIs, but provides common usage patterns for each and even provides implementations for useful new primitives. Some of these primitives include an implementation of a PollingThread, a ScheduledThread, an HTTPSocket and a SocketServer. For all of the examples in the book, Ted lets you in on his design process as the GJAS evolves. He lays out the alternatives, makes a selection, and then justifies it. When he applies design patterns from the Gang of Four (GoF), he tells you why he is applying that particular pattern, and how it solves the problem at hand. This is the core of this book, and it's strong point.

Interspersed in the threading and sockets chapters are about server configuration and control structures for services that get executed on the server. Ted discusses different implementations of user services running in their own thread (so as not to interrupt other processes on the server), and in doing so makes use of the thread primitives he laid out in a previous chapter.

The later chapters are typical server programming fare: business objects, business object models, persistance and middleware. However, Ted covers them in a style consistant with the rest of the book: copious code examples, design justifications, and years of valuable on the job experience communicated in a scant 160 pasges.

So What's In It For Me?

As a Sun Certified Java 2 Developer, I've read more than my fare share of bad java books. The good thing is that they are very easy to spot: they are typically extremely thick books with trivial examples and a huge API reference (that you can download from Sun's Java Developer Connection) for filler. This book is a voice of reason in Sun's flood of J2EE (especially EJB) hype. It's a wholly remarkable Java book. Ted Neward should be rewarded and congratualted for this book, it sets a new standard in content quality for Java books.

Based on this book, and the review of the Manning Swing Book, Manning now ranks right up there w/O'Reilly in my list of top-quality technical book publishers.

Table of Contents
  1. Enterprise Java
  2. ClassLoaders
  3. Custom ClassLoaders
  4. Extensions
  5. Threads
  6. Threading Issues
  7. Control
  8. Remote Control
  9. Configuration
  10. Sockets
  11. Servlets
  12. Persistance
  13. Business Objects
  14. Business Object Models
  15. Middleware
  16. Java Native Interface
  17. Monitoring

You can purchase this book at Fatbrain.

6 of 48 comments (clear)

  1. This is a great book by djweis · · Score: 5
    No, it's not JSP for dummies, but it gets into just about all of the complicated topics that no other book so far covers. It was a bit pricy ($49.95) but definitely worth it. The chapter on Modeling is also useful and is something that is missing from the other Java books I have.

    I also liked Java Enterprise in a Nutshell from O'Reilly. Previously, there wasn't anything about the more complicated server-side Java topics, just how to use awt/swing/applets. Between these two books, you can learn a lot.

  2. Reading in the morning... by MSG · · Score: 4

    volume at the expense of clarity, he claims that this volume suffers neither fault.

    It's early, and when I read this, I thought he meant that the book had neither volume nor clarity.

  3. If you'll allow me to argue from authority... by rw2 · · Score: 5
    I've been a pro for better than a decade and an amateur for another decade before that. Let me tell you that the biggest problem in corporate development today isn't whether or not people understand J2EE, but whether they understand distributed idioms and business.

    I can't tell you the number of times that I've had to help folks who had memorized the spec and read books like this, but didn't understand why the spec contained the features it does, nor why going distributed was the way to go (hint, $).

    So, read this book. Learn everything it contains. But don't skip the more academic architectural tomes nor the business aisle the next time you're at Borders...

    --
    Poliglut

    1. Re:If you'll allow me to argue from authority... by rw2 · · Score: 5
      I don't care *why* management chose to go down a certain path. Even if it looks like to wrong choice to me sometimes, I trust them, because they know a lot more about that stuff than I do.

      I'm not saying that you should not trust them. I'm saying that you will be better at *your* job if you understand them.

      Nor am I saying, as you mention, that you shouldn't focus on the specs. Just that you shouldn't focus on them to the exclusion of other, admittedly less interesting, subjects.

      How many times have things needed to be re-worked in projects that you have worked on because of miscommunication? In many cases that can be eliminated because you better understand the business perspective and can ask better questions. And, frankly, that seems a lot more likely than that we'll convince the business types to learn enough about what we do to give better instructions.

      --
      Poliglut

  4. Re:Java's Server Basis by macpeep · · Score: 4

    Java and Perl will be the basis of most programming languages? Java maybe - C# proved that, but Perl? I may be wrong but the only place that Perl has really ever been REALLY strong (yes, it's used for scripting stuff by system admins but I'm talking *REALLY* widespread and serious mission critial use) is for CGI on web servers. There, Perl has traditionally been extremely strong but it seems to me that lately, ASP, PHP and especially Java servlets and JSP is eating up that advantage. If anything, it seems that Perl is losing "market share". Does anyone have any stats to show if my feelings are right/wrong?

  5. Thanks for the review by nullnvoid · · Score: 5

    Sounds like this book contains some of the nitty gritty that I've been missing in other volumes I've picked up. It's definitely on my buy-list now.

    I'm a little disappointed in some of the flamebait posted in response to this review, though. I thought trolls like that hung around the Java advocacy newsgroups all day.

    People who like to talk about the "failure" of Java apparently have very little exposure to the real world of Enterprise applications... EJBs, servlets, and JSPs are being deployed on many custom applications developed by and for Fortune 500 companies.

    Some of the more popular middleware is also either Java-based, or, at the very least, is exposed to developers through a handy Java API.

    In my experience, Java programming is one of the absolutely essential skills needed if one plans to develop these Internet and Intranet applications (and, no, I'm not talking about applets).