Server-Based Java Programming 48
| 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
- 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.
Re:True... (Score:1)
Re:If you'll allow me to argue from authority... (Score:1)
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 worked for boo.com
This is a great book (Score:5)
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.
Re:I wonder...... (Score:3)
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.
Re:This is a great book (Score:1)
Re:Opinions on Marty Hall's Core Servlets & JSP?? (Score:1)
don't use them!
Trust me on this one. Servlets good, JSPs bad.
Re:Opinions on Marty Hall's Core Servlets & JSP?? (Score:1)
I do. But JSPs don't make that any easier.
I thought jsps just compiled to servlets anyway- what is the problem there?
I've sure one could write a befunge to Java compiler too, but you probably don't want to write your servlets in befunge.
I would love to trust you on this one, but you haven't supported your argument very comprehensively here.
Hmmm, if I told you it was bad to stick a pencil in your eye would you be so skeptical...?
JSPs have numerous problems, but what it boils down to is this: they're a maintenance nightmare. They don't support any real modularization (beyond include), you can't compile them at build time (if anyone knows otherwise, let me know), they remove the ability to do certain things (like sent the output encoding dynamically), they suck rocks for trying to do i18n, and they make it way too easy for people to insert actual Java code that should be in Java files, not JSPs.
If you don't believe me, go ahead and use them for a large project. But don't say I didn't warn you.
Enterprise java server (Score:3)
Reading in the morning... (Score:4)
It's early, and when I read this, I thought he meant that the book had neither volume nor clarity.
Re:This is a great book (Score:3)
If you'll allow me to argue from authority... (Score:5)
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 [poliglut.com]
Re:If you'll allow me to argue from authority... (Score:5)
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 [poliglut.com]
Re:Seems to be a core part of the language's style (Score:1)
Also, I can't really see where you have a problem with using StringTokenizer() instead of split().
I find the docs have quite a few good working examples for the tricky things (moreso than man pages for C functions). And if the docs do fall short, in about four seconds of web searching you can find so much example code you would be amazed. In fact the problem is an embarassment of riches, or perhaps just an embarassment depending on what code you find. But, at least it's an eample!
Re:Seems to be a core part of the language's style (Score:1)
Personally though my style is to writePrettyVerbosley. I tend to copy a lot of text and use registers in Emacs for common things, so the length doesn't get in the way - and it makes it a lot more readable.
I'll agree with you on the not nessicarily better or worse, I just prefer a little more verbosity and find that you get used to it and the extra length does not really matter... Since you can sometimes spend hours reducing something you are doing to a single line of code, why bother trying to shorten the characters used in that line? That's what I think coding is really all about, getting rid of code you have rather than worryng about how many characters are there to start with. It's just as easy to delete StringTokenizer() as split().
It's all about writing a boulder and then carving a fine statue - and even if you just set out write a statue you always find you end up with a boulder anyway!
Re:Seems to be a core part of the language's style (Score:1)
List aList = new ArrayList();
StringTokenizer st = new StringTokenizer(delimitedText,",A");
while( st.hasMoreTokens() )
aList.add( st.nextToken() );
Of course, you could write that into some kind of static string helper class and then just say:
List aList = StringHelper.tokenizeString( delimitedText, ",A" );
which is what you'd do if you were having to use StringTokenizer often.
A side note is that StringTokenizer also offers somewhat more flexibility than split() as it can change the delimiters on the fly for each token (though I'll have to admit I can't think of a good case where I would use that!).
I am aware of the 10 billion Java sprintf() implementations. I think there are two reasons - the first is that C programmers new to Java don't yet have the idea down of browsing the Java libraries to look for features they need, the other is that some might be trying to port old C code and to make that easier you might well want a good Java sprintf(). I myself have had no need or desire for sprintf() in Java.
Ruby looks interesting, but for the moment I find Java a lot easier to use than just about anything. It's really a matter of knowing the libraries pretty well, then just about anything you want to do is easy.
Re:Java's Server Basis (Score:2)
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..
Re:True... (Score:3)
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..
Re:Java's Server Basis (Score:4)
Re:True... (Score:1)
I've tested gcj as native compiler for Linux, not only did the app run faster, but the resource usage was remarkably lower as well. What I'd like was ability to manually tweak parameters for hotsport enabled JVMs. They compile to native code runtime, but only as far as their internal logic allows them.
The book that needs to be written (Score:3)
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.
Re:I wonder...... (Score:1)
Re:This is a great book (Score:1)
--
Re:This is a great book (Score:1)
free market and all that
Interesting argument, considering that the reason for the boycott was that Amazon is impairing the free market--
Re:Speaking of buzzwords... (Score:3)
Re:Enterprise java server (Score:1)
Coffee/Java jokes are SO 1997.
--
Re:Enterprise java server (Score:1)
Jeremy
Seems to be a core part of the language's style. (Score:1)
Whereas python is for display and use. And perl is for use and abuse
As I type there are probably thousands of java programmers implementing their own versions of messiness like "split" or sprintf - StringTokenise blahblahblah.
Also have you ever taken a look at Sun's Java documentation? It looks like a blooming academic textbook. Or an Oracle Installation Manual. Hands up how many of you actually used a 3rd party Oracle Install HOWTO instead?
The docs also have very few useful working examples.
Working examples are important so that you can more easily tell whether the language implementation screwed up (or just changed with rev X), or you did. That's real world for you.
Cheerio,
Link.
Re:Seems to be a core part of the language's style (Score:1)
listorarrayorwhatever=split(',A',delimitedtext)
As for sprintf. Well I dunno why, but many people are doing it in Java, so somehow there must be a need, or there was a need in the past (the out of date Java FAQ has at least one reason)?
http://www.google.com/search?q=java+class+sprin
Personally I see my colleagues doing Java and there seems just too much pain and trouble for me to bother.
Basically I'm just waiting for it to get easier. Unfortunately the signs aren't promising.
Meanwhile I might just go learn Ruby if I've got the time - the language even has standard methods to escape html or urls. Cool!
http://www.rubycentral.com/book/web.html
Pity mod_ruby/FCGI, RDBC, Ruby/DBI stuff are not production ready yet. But once they've got that, I think the party will really start
Cheerio,
Link.
Exactly! That's what he and I meant. (Score:1)
Too often in Java you have to be more verbose just to do the _common_ case. I don't mind being verbose to do the uncommon case, but for the common case isn't that bad?
With perl (and probably the others) I can do "change delimiters on the fly" with split (or something else) as well. This time it'll probably take about the same number of lines as StringTokeniser code to do the same thing.
Another example, getting the number of rows in a SELECT. Many of my colleagues have gone through the pain of going "Doh! You mean there's no built-in attribute? You mean I have to get the result set, go to the end of the result set and fetch the current row number? What the
That's the sort of thing I don't like about Java.
I wish the Java creators actually bothered to sit down and use their own language for common real world situations. Well maybe they do, and they're the sort who don't mind doing 2 to 3 times more work just to do simple things. If they change that I might consider Java.
Being verbose for the common case is bad because when you have to spread the common concept/idea/action over many lines, it can get lost amongst other lines. And then when you also have the uncommon case, you could confuse the two.
Yeah I can probably build my own split in Java. But if I'm going to build all my stuff from molecules it might just be better to use LISP right?
Also, if I build my own split, people looking at my code have to find out how my split actually behaves, and I might have to write documentation for it as well.
Larry Wall's "Make easy things easy and hard things possible" sounds like a good idea to me.
I find compression very analogous to programming.
I prefer: compress very well for the common target data, compress ok for most unusual cases. Slight expansion for those rare pathological cases.
Cheerio,
Link.
Re:Opinions on Marty Hall's Core Servlets & JSP?? (Score:1)
Re:If you'll allow me to argue from authority... (Score:2)
I am an engineer, so I focus on the engineering. They tell me they want an enterprise solution, and I tell them what it's going to take to put in place. While I certainly care about the outcome of the project, and the future of the company, it's not my place to worry about it.
You go ahead and read your "business aisle" books, and I'll focus on the specs. Together, we can build something that really works.
Opinions on Marty Hall's Core Servlets & JSP?? (Score:2)
Curious George
A.D.D. means never having to feel off-topic.
Re:Java's Server Basis (Score:1)
Secondly, how do you define 'serious mission critical'? CGI has *never* been in that category, but the assortment of crucial tools running on Unices, many written in Perl but short-tempered sysadmins, often are (as they keep the system ALIVE).
Thirdly, although the original poster could have phrased it differently, he did have a point - namely, 2 of the largest areas of biz computing will be dominated by Java (large static systems engineered by hordes of cubicle drones) and Perl (continuing to keep IT running around the world; interfacing whatever junk apps the suits keep buying). It's a familiar dichotomy, and a persistent one at that.
To repeat myself: Java and Perl are the primary representatives of two areas of biz computing, and they and their semantic derivatives will remain dominant in their respective spaces.
Re:Java's Server Basis (Score:1)
So what is this position it is fading from? Advocacy. I think Perl, used on the web, really validated scripting languages and prototyping for a huge swath of computing. Even the concept of TMTOWTDI: ignored, mocked, fought, and won. Now that the space has been validated, it is competing with Python, Ruby, Tcl, etc. I think Perl is still being used as much as it was then, and I have no predictions for its future, but it would be an odd thing if Perl were to regain the amount of buzz and mental energy exerted evaluating it like it had in the recent past. It's become a widely accepted workhorse, and we won't hear as much except the truly revolutionary events. Natural order of revolutions.
Thanks for the review (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).
Re:If you'll allow me to argue from authority... (Score:3)
I agree. The biggest problem is programmers who have NO understand on business. Programmers who also have extensive business /accounting/etc expertise are as rare as hen's teeth. (But I do know a couple). They are also way undervalued.
This gets to be the equivalent of a non-coder technology manager who has picked up a book on javascript, and has written something simple in a afternoon. Who then says that there is nothing to javascript, and way can't you use javascript to create this intricate ssetup for me?
A comprehensive understanding of the programming problem is vital to the development of a competent programming solution. To the extent that you do not have the the problem well defined, the more time you will spend debugging, etc.
this is well illustrated by this webpage [multicians.org], which tells the story of a guy who wrote a memory management tool. the only bugs in the program were a handful of typos. It was literally perfection otherwise. He obviously had done all of his debugging on papaer in the first place.
The flip side on this is in large corporate enviroments where people asking for reports, etc do not understand the nature of the data in the first place, and so as for simple things that are hideously difficult, or which are confused in the first place.
Check out the Vinny the Vampire [eplugz.com] comic strip
Book Cover (Score:2)
"Fast Enough" for web sites (Score:2)
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.
New servlet programmers.. (Score:3)
Speaking of buzzwords... (Score:3)
"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 [hiddenmind.com], and they do some really cool stuff with java.
Good Books (Score:1)
It's good to see a book that talks about server side java in a realistic manner. There are too many java programmers that think that dynamically creating HTML from your servlets is really cool stuff.
Re:True... (Score:1)
But..surely, Java still has some barriers to overcome, like those people, who post on
But it is a easy language compared to the others and is as good as C++ or in this case C#
Java's Server Basis (Score:2)
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
Thanks for the link... (Score:1)
Re:This is a great book (Score:1)
Manning books are great (Score:2)
The other nice thing about Manning is you can buy a PDF copy of a book from their website www.manning.com [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.
-----------------
Re:Thanks for the review (Score:1)
i'd like to dispute some points. first, most popular, mission critical middleware is still written in C and C++. most of course will create a Java API by putting lightweight wrapper classes around JNI calls to their code, but important software necessitates the level of control that C/C++ afford the developer.
Second, I dispute that Java programming is absolutely necessary to develop inter/intra (why you make the distinction here is lost on me...)net apps. Knowledge of sockets and wire protocols are the keys to being a competent network programmer. remember, java sockets are native socket calls (and therefore, once again, written in c/c++ or assembly).
now, that being said... I think java is better language to write most programs in. it is easier to write bug free code - both by design of the language IMHO and by ignoring portability concerns. No need to worry if an int is 16, 19, 3, or B bits, in java, just trust the VM that an int primitive is a signed 32 bit data type... Nobody's going to leave dangling pointers or forget to free buffers. It's good for very rapid development that requires very good reliability and good performance. It's also easier to read 'legacy code' since there's no really tricky code you can write for better or worse...
but in the end, it's another turing equivalent language.. you can do the same thing in PERL, C++, VB, blah, blah, blah. it's all a matter of taste and convenience.
javabooks (Score:3)
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