Slashdot Mirror
JBoss - A Developer's Notebook
Pankaj Kumar writes "Controversies aside, JBoss has emerged as a credible
alternative to commercial J2EE App Servers for developing and deploying Java based server
applications. Besides the usual advantages of open source and GPL licensing, what sets it
apart is its JMX based
microkernel, a light-weight framework to run independently developed Java programs within a single
JVM. Together, these make it possible for one to pick and choose
components and assemble a custom server anywhere between the two extremes (and beyond!) of a
simple Servlet Container and a full-fledged J2EE Server. JBoss - A Developer's Notebook by Norman Richards, a JBoss developer at JBoss, Inc., and Sam Griffith, Jr., a software consultant and trainer, is a no-fluff How-To guide on doing stuff with JBoss in O'Reilly's new Developer Notebook format." Read on for Kumar's review of the book.
JBoss - A Developer's Notebook
author
Norman Richards & Sam Griffith, Jr.
pages
150
publisher
O' Reilly
rating
7
reviewer
Pankaj Kumar
ISBN
0596100078
summary
A How To Guide on Working With JBoss
True to the format, this book doesn't waste pages on paeans to architectural elegance, internal design or conceptual deliberations, and limits itself to the basic needs of most professionals -- how do I do this or that with JBoss, where to start, what steps to carry out or what code to write, and what happens behind the curtains.
Books dealing with J2EE products tend to be fat and bulky, but this (note)book doesn't fall in that category. By covering only JBoss specific aspects and avoiding general J2EE topics, this rather thin book has managed to include a good deal of difficult-to-find information about JBoss. In fact, while going through its pages, I got a feeling that the authors have taken care to be different and complementary to the online documentation available in the JBoss Application Server Guide and JBoss Wiki.
In support of the above claim, let me compare the coverage of how to deploy applications under JBoss, an important activity with any J2EE container, in the JBoss Guide, JBoss Wiki, and the book under review. The JBoss Guide covers application deployment as part of the JMX based microkernel architecture and design, describing, in excruciating detail, the internal components responsible for the deployment and and how they interact. The JBoss Wiki takes a more externally focused approach, talking about hot deployment capability, relevant directories and configuration files in an installed system, and steps in a typical deployment process. In contrast, Developer's Notebook goes through the whole process of creating the deployable WAR file for a web application, deploying that to JBoss by copying the created file to JBoss's deploy directory, and verifying successful deployment or looking for errors. It even talks about how to modify a deployed application. Needless to say, the last one is most useful to someone who just wants to deploy his or her application.
True to its lab notebook style, the book makes important, though not integral, observations about specific topics in the page margins. For example, a note in the margin of deployment steps tells you that you can include a deployment package within another deployment package, up to an arbitrary level of nesting, a la Russian doll packaging. I found this informal way of communicating relevant stuff quite effective.
Another noteworthy aspect of this book is that it makes generous use of appropriate tools, such as Ant and XDoclet, to get things done. This can be either good or bad, depending upon your familiarity with these tools. For me, it turned out to be a mixed bag. I know Ant and am happy writing Ant scripts for packaging and deployment. It is different with XDoclet, which I haven't had a chance to use so far. But perhaps the authors know better and one should just get familiar with it before working on any project involving JBoss and Enterprise Java Beans.
It is difficult, if not impossible, to cover each and every aspect of software as feature rich and complex as JBoss in any single book. This leaves the somewhat unpleasant task of choosing topics to the the authors and editors, for the selection may or may not match the needs of a particular reader. At the same time, it increases the responsibility of a reviewer like me who must help a prospective buyer decide for or against making a purchase, based on her needs.
Let me attempt to do that by making two lists: first, what is included and then, what is not.
What is included (paraphrased Table of Contents):
A similar, comprehensive, list of what is not included is simply not possible. Still, I have gone ahead and created the following based on my experience with JBoss. Keep in mind that these reflect the kind of applications I have worked on and may not be representative of your needs.
I can only hope that the authors will take this as a reader feedback and include some of the above in a future edition.
So, what else is there not to like about this book? One thing that caught my attention was the relative absence of insight into why things worked the way they worked: What are the underlying patterns and how can the awareness about these patterns be applied to other similar situations? These are the things I look for in a new product or technology, and have found them to be much more helpful than just a compilation of step-by-step descriptions of doing things. Perhaps the Developer's Notebook format doesn't allow for such digressions, still I think inclusion of such insights would have improved the book.
Overall, I would say that JBoss - A Developer's Notebook is a good introductory book for those who are thinking of getting started or are just getting started with JBoss. If you have already worked on JBoss and are looking for more advanced or esoteric stuff, then this book is perhaps not for you.
You can purchase JBoss - A Developer's Notebook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
True to the format, this book doesn't waste pages on paeans to architectural elegance, internal design or conceptual deliberations, and limits itself to the basic needs of most professionals -- how do I do this or that with JBoss, where to start, what steps to carry out or what code to write, and what happens behind the curtains.
Books dealing with J2EE products tend to be fat and bulky, but this (note)book doesn't fall in that category. By covering only JBoss specific aspects and avoiding general J2EE topics, this rather thin book has managed to include a good deal of difficult-to-find information about JBoss. In fact, while going through its pages, I got a feeling that the authors have taken care to be different and complementary to the online documentation available in the JBoss Application Server Guide and JBoss Wiki.
In support of the above claim, let me compare the coverage of how to deploy applications under JBoss, an important activity with any J2EE container, in the JBoss Guide, JBoss Wiki, and the book under review. The JBoss Guide covers application deployment as part of the JMX based microkernel architecture and design, describing, in excruciating detail, the internal components responsible for the deployment and and how they interact. The JBoss Wiki takes a more externally focused approach, talking about hot deployment capability, relevant directories and configuration files in an installed system, and steps in a typical deployment process. In contrast, Developer's Notebook goes through the whole process of creating the deployable WAR file for a web application, deploying that to JBoss by copying the created file to JBoss's deploy directory, and verifying successful deployment or looking for errors. It even talks about how to modify a deployed application. Needless to say, the last one is most useful to someone who just wants to deploy his or her application.
True to its lab notebook style, the book makes important, though not integral, observations about specific topics in the page margins. For example, a note in the margin of deployment steps tells you that you can include a deployment package within another deployment package, up to an arbitrary level of nesting, a la Russian doll packaging. I found this informal way of communicating relevant stuff quite effective.
Another noteworthy aspect of this book is that it makes generous use of appropriate tools, such as Ant and XDoclet, to get things done. This can be either good or bad, depending upon your familiarity with these tools. For me, it turned out to be a mixed bag. I know Ant and am happy writing Ant scripts for packaging and deployment. It is different with XDoclet, which I haven't had a chance to use so far. But perhaps the authors know better and one should just get familiar with it before working on any project involving JBoss and Enterprise Java Beans.
It is difficult, if not impossible, to cover each and every aspect of software as feature rich and complex as JBoss in any single book. This leaves the somewhat unpleasant task of choosing topics to the the authors and editors, for the selection may or may not match the needs of a particular reader. At the same time, it increases the responsibility of a reviewer like me who must help a prospective buyer decide for or against making a purchase, based on her needs.
Let me attempt to do that by making two lists: first, what is included and then, what is not.
What is included (paraphrased Table of Contents):
- How to install, start, examine (through JMX Console) and shutdown JBoss Server.
- How to package, deploy, observe and undeploy an application.
- How to create a web application with database access and user authentication.
- How to use MySQL as database for a JBoss application.
- How to setup user database, login modules and enable SSL.
- How to configure logging for various components of JBoss.
- How to map schema, objects and relations to database tables.
- How to monitor and manage a JBoss application with MBeans.
- How to create a custom JBoss with modules that your application needs.
A similar, comprehensive, list of what is not included is simply not possible. Still, I have gone ahead and created the following based on my experience with JBoss. Keep in mind that these reflect the kind of applications I have worked on and may not be representative of your needs.
- How to use JBoss as a J2SE container.
- How to develop Web services with JBoss.
- How to create, package and deploy an application consisting of JBoss services, web applications and web services.
- How to troubleshoot class loading problems.
- How to isolate applications within a single JBoss server instance.
- How to profile for performance bottlenecks.
- How to run multiple instances of JBoss Server on a single machine.
I can only hope that the authors will take this as a reader feedback and include some of the above in a future edition.
So, what else is there not to like about this book? One thing that caught my attention was the relative absence of insight into why things worked the way they worked: What are the underlying patterns and how can the awareness about these patterns be applied to other similar situations? These are the things I look for in a new product or technology, and have found them to be much more helpful than just a compilation of step-by-step descriptions of doing things. Perhaps the Developer's Notebook format doesn't allow for such digressions, still I think inclusion of such insights would have improved the book.
Overall, I would say that JBoss - A Developer's Notebook is a good introductory book for those who are thinking of getting started or are just getting started with JBoss. If you have already worked on JBoss and are looking for more advanced or esoteric stuff, then this book is perhaps not for you.
You can purchase JBoss - A Developer's Notebook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
My quotation states that "JMX sets JBoss apart". How can JBoss be set apart by a technology used by many (if not all) the major vendors? Perhaps the author meant "JMX sets JBoss apart from the other low cost/free/open source J2EE servers?"
Javascript + Nintendo DSi = DSiCade
My reading of the post is that the poster is implying either responsibility for or a current monopoly on the technology. Nothing could be further from the truth.
However, I am willing to concede that others (such as yourself) have not read it this way. Which only leaves the point about being "set apart" based on this technology. I find it hard to accept that JBoss is "set apart" by a technology that is in many competing J2EE servers. In which case, I can only assume that the poster either did not understand this, or intended to say that "the quality of the JMX implementation sets JBoss apart."
Javascript + Nintendo DSi = DSiCade
You're sinking fast.
:-)
Sinking, nothing. I'm pointing out an oddity in the review, which *seems* to claim that JBoss is somehow superior for its use of JMX. Since JBoss has nothing to do with the development of the technology, nor does it have a monopoly on the use of the technology, I find that statement odd at best, disingenuous at worst. However, I think you answered the argument after this:
What does set them apart is that they base their architecture on JMX where as others simply expose JMX objects, usually for mundane tasks simply to get the checkbox on feature set. JBoss on the other hand, uses JMX to bootstrap the entier application server, almost every component within the server is configured with a JMX MBean meaning you can use the JMX server infrastructure to easily interrogate and alter the configuration at runtime if desired. This is what sets them apart.
Or in other words, the quality of the JMX implementation sets JBoss apart. Which I can accept quite readily. Thank you for clarifying.
Javascript + Nintendo DSi = DSiCade
Absolutely right, the pattern has been derived from the OS design.
Which is, again, completely screwed up. JBoss, NetKernel, Geronimo, etc., all have zip to do with microkernels. They don't manage anything other than loading shared, executable code. Something which, if I may point out, is precisely what a Microkernel *doesn't* do. That's what the servers are for!
Not to mention that the concept *still* fails to commmunicate what precisely the software *does*. When we talk about OS Microkernels, we know that we're talking about the interface between the hardware and software in a multiuser system. When we're talking about a Microkernel in the context of App Server software, it is completely unclear what is meant. At best, we can assume that a central control launches "services". The meaning of this is quite ambiguous and highly confusing. Now if we said "JBoss is an application server based on a JMX Framework where everything in the system is a JMX object," then we know what exactly JBoss is.
It's an abstraction, it looks at what is the essence behind the principle of the OS microkernel and transfers it to other areas.
No, it's not. A Microkernel is a very specific concept, with very little abstract about it. Redefining it to be an abstraction is a problem.
And to make it clear: using this term in that general way is in no way an invention by the poster nor by the JBoss group.
To be clear, I'm merely annoyed at the desire of marketeers to reuse terms like this. It's nothing against JBoss in specific, just the corruption of a perfectly workable dialect.
No, definetely not. "Framework" is far too general and unspecific.
Framework is a starting point. Thanks to the power of the English language, we can be more specific without inventing a new term. "J2EE Framework", "JMX Framework", and "Plugable Server Framework" are all perfectly acceptable, and far more informative than "Microkernel."
Javascript + Nintendo DSi = DSiCade