Slashdot Mirror
Server-Based Java Programming
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- Enterprise Java
- ClassLoaders
- Custom ClassLoaders
- Extensions
- Threads
- Threading Issues
- Control
- Remote Control
- Configuration
- Sockets
- Servlets
- Persistance
- Business Objects
- Business Object Models
- Middleware
- Java Native Interface
- Monitoring
You can purchase this book at Fatbrain.
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.
You don't have to license anything to build a JVM
or a Java compiler or a J2EE server or servlet
container or EJB container or Jwhathaveyou.
There is an open spec. Now run along and implement.
I run ours, and fill it up with 3 heaping scoops of Kirkland 100% Columbian supremo bean dark roast fine grind, 10 cups of water, and program the timer every night.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
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
Hey hey.. wait a minute!! I didn't diss Perl, nor did I mock it or any of the uses for it. I was just questioning the original authors statement about how Perl is/has been an example for other languages (a model for them). Personally, I can't think of any language that would have been influenced heavily by Perl.
In a completely separate point, I was asking if my feelings about Perl actually being used less now than it was used 3 years ago are correct. What I mean is, rather than being a great example that everyone is following, Perl is actually slowly fading away from the position it once had.. I could be wrong, but that's the feeling I get..
There's a reason why there are so many Java books in the bookstores. The reason is that Java is extremely popular right now for server side programming and there is a demand for those books. The people on Slashdot that say that Java sucks have mostly little or no real experience with JDBC, EJB, JSP, RMI etc. and are just basing their view on Java applets coded by some "programmer" at a web concultancy, holding "Teach Yourself Java In 21 Days" in his left hand. Yes, those suck. Yes, those are slow. The fact of the matter is that Java is clearly fast enough for what it's being used for - that's why it's so popular. Java is in the same ballpark with Perl when it comes to speed (there are lots of benchmarks proving the superriority of either of these, and most of these benchmarks are ridiculously flawed and one-sided) and obviously, Perl is also "fast enough"; case in point, Slashdot.
As far as "easy" vs. "hard" goes, I don't think that Java being hard is a point against Java - quit the opposite, Java is usually perceived as being a relatively easy language, mostly thanks to garbage collection and all objects being passed by reference (contrary to what you often hear on Slashdot about Java not having pointers - it has nothing BUT pointers, except for primitives). Too much like C++? C++ with an option for garbage collection and a strong and balanced standard library would be - to me - an ideal language so I'm not sure I understand your point there..
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?
attention brave soul (or fool):
Write a book that covers all web-middle-tier-to-database application arcitectures in detail. Include everything from mod_perl, python, java servlets, EJB, jsp, asp, COM+, C/C++. Tackle ODBC, JDBC, OCI, etc. Give a pro/con on all of the above in detail, and get it out the door in 6 months before it all changes.
Someone you trust is one of us.
were they trade schools? if you are looking to get a degree in the Science of Computers, you should be asking if they have an "Operating Systems" course or "Networking Theory." If they teach you a language (as opposed to language design) you would be lucky. If you want a degree on how to apply the theory go to ITT Tech or spend your nights hacking in your dorm. Colleges and Universities for the most part teach Theory. Esp as an undergrad.
Curious George
A.D.D. means never having to feel off-topic.
***General Consultant to the Human Race*** My opinions are free. You get what you pay for.
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).
I like it when the book reviews have a picture of the book cover. Allows me to put a face with a name. ;-) Here is the Amazon.com page with the picture on it.
I had a really good argument as to why that's not true, but during the 72 seconds I waited for this form to come up after I clicked "Reply to This", I forgot what my argument was.
P.S. I have a fast connection and image loading turned off.
.. should probably know that the second edition of Jason Hunter's excellent O'Reilly book on Servlet Programming is now available. Very good book, if you want an intro to java server-side dev Timo
-- Profound quotes need not apply
"do you have a distrubited network applications class?"
Or advanced finite method elements?
What about perl?
Oddly, none of them could answer.
Although I do enjoy java. My stepdad works for HiddenMind, and they do some really cool stuff with java.
01101001 01100001 01101101 01101110 01101111 01110100 01100001 01101100 01100001 01110111 01111001 01100101 01110010
A book like this would be a great help to someone that knows the language but would like to start using it for the Internet. Like myself, I just started learning RMI and this book would be something that I would buy.
You may not realize it, but since C# is basically a sellout to MS, Java and Perl are going to be the basis of most programming languages. Of course, C# will be used, but watch out for Java and Perl
Slashdot Hypocrisy at work?
I have to agree with the reviewer on the general quality of Manning books. I have "Web Devlopment with JavaServer Pages' by Fields and Kolb, and it is excellent, better than anything from Wrox, or Addison-Wellesley.
The other nice thing about Manning is you can buy a PDF copy of a book from their website www.manning.com for $13.50 plus 3.50 "processing fee" and apply the $13.50 as a credit to the hardcopy if you want to buy that later. Nice if you want to check it out before buying, or to keep a reference copy on your development box.
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
I take it this book is write once, read anywhere??
Seriously, though - what you get out of a book is what you put into it. No book is a complete reference and doing the "extra leg-work" to fill in the gaps is the difference between reading a book because you love what you do, and reading a book because your boss told you to.
RC
RC