This is the supporting website to the book, Server-Based Java Programming, from Manning Publications. (You can find sample chapters and the Table of Contents, all in much more nicely-presented form, at the publisher's site.) This page, meanwhile, is dedicated to discussion and support for the book and its accompanying code.
It's been over a year since the book was published, and now that I've had time to reflect on it, there's a number of things I feel merit explanation. Some of the key questions that have been asked me are:
I couldn't say this in printed form at the time, but the fact is, EJB sucks as a technology. (See my reasoning why at http://www.javageeks.com/Papers/EJBReviewed.) The fact is, it's supposed to make the Java programmer's life simpler regarding a number of key issues, like remoting, persistence, transactions, object lifecycle, and so on. Instead, it only serves to complicate the entire process immensely, forcing Java programmers to learn an entirely orthogonal set of rules that have nothing to do with the business domain they're trying to program--exactly the very problem that EJB was trying to solve in the first place.
Many EJB vendors will then turn around and tell you that their product, in turn, solves much (if not all--marketing people are shameless) of the complexity inherent in EJB. I won't argue with this statement; in fact, I heartily support it--many vendors have some powerful features that can definitely make your life easier as a developer. Problem is, if you take advantage of that vendor's functionality, you lose the vendor-neutrality in EJB that's supposed to let you avoid "vendor lock-in" in the first place. If you're not interested in vendor-neutrality, why aren't you considering Microsoft's .NET architecture as part of your vendor evaluations at that point? Or CORBA, for that matter? In addition, many vendor implementations, while perhaps easing the burden of developing EJB applications, miss on an important point--the ability for a Java architect/developer to "hook in" at certain critical points and provide tuned implementations of various parts of the system (smart stubs on the client side to avoid redundant round-trips, smart caching for read-only or read-infrequently data, and so on).
In short, EJB is a fundamentally flawed specification--a great idea that just doesn't solve the problems it sets out to solve--and therefore isn't worth writing about.
Possibly, but only to explain in greater detail my reservations regarding the technology/specification as outlined above. Don't expect an "EJB Best Practices" section from me, now or ever.
Two reasons: first, I wasn't sure I understood it well enought at the time to do more than just parrot the obvious back at the reader. (Unfortunately, much of the "Threads" chapter does just that, but I thought that the Java Threads API was still new enough to many readers to merit that coverage. Subsequent reviews and comments from readers have me regretting that particular decision.) Almost three years later (after I started writing), I realize that I really didn't understand Java Security back then--I've got a much better grip on it now. If/when a Second Edition comes out, expect at least a chapter on Java Security.
The second reason is far more profound--any discussion with the word "security" somewhere in the title is bound to start creeping out into things like cryptography, public-key/private-key encryption, SSL and TLS, and so on. These are subjects in which I'm not an expert, in any way. I felt, at the time I began to work out the Table of Contents, that if I covered "security" in this book, I'd have to talk about those things as well; hence my comment in the Preface about how "Security could cover a book all its own". In the interim, there've been a number of good Java Security books (including my favorite, the Li Gong "Inside Java2 Platform Security" book) that cover just Java Platform Security, and leave SSL and encryption to other books--exactly what I'd want to do. Having seen it done, I now feel a lot more comfortable about the idea, so again, expect at least a chapter on Java Security in a Second Edition.
Time and space. There's only so much time you have to write a book, and only so much space for the words you've written. There were a number of things I'd have liked to have included, but the topics included (ClassLoaders, Threads, Control, Sockets, Serialization, Business Objects, Middlware, JNI and Monitoring) seemed like the "bare minimum" to have to talk about server-based Java coding. At that, I felt like I gave certain topics (Control and Monitoring in particular) short shift and should have been expanded. (shrug) Hey, you have to ship sometime. :)
Not really, according to the official definition of "open source". I own the copyright to GJAS (mostly because I didn't want people making "improvements" to it without going through me first), but beyond that, it's yours to use as you wish, so long as you don't hold me liable for anything.
That stated, I'm not sure why you'd want to use it except as a springboard for your own projects--it's definitely not production-quality code, and would need a number of enhancements to it before it's something I'd feel ready to deploy into a production system.
If/when I write a second edition, I plan to rewrite GJAS from scratch, then host it up on Sourceforge and open it up for the world to use as they wish. If/when a companion book comes out, I plan to rewrite GJAS's core to accomodate the new ideas there.
Note that many of the ideas in GJAS are also covered by JSR-111, of which I am privileged to be a member. Check out Avalon, as well, for a "service container" similar in concept to GJAS.
Very closely, in fact. Write a Connection-implementing class that ships XML back and forth, and you're right on the cusp of XML-over-HTTP, which is what most folks are calling "Web Services" these days.