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.
Either way, given that WebLogic and WebSphere cost a fortune, JBoss is the only "real" app-server that can be had for no dollars. It's good to have a cookbook out there, so the do-it-yourselfers can learn how to write for an app-server on their own. Plus, the low-budget crowd can put up a real app-server. If JBoss won't scale to the traffic and you have to buy one of the big boys, well, that's a good problem to have.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Just started a new gig and am forced to use WebSphere (WAS 5.x/6.x) and RAD. What can I say - it's a huge piece of turd and I miss using Tomcat/JBoss for real. There are great advantages to using commercial application servers - for instance WAS (and Weblogic) allows you to hotdeploy and debug your code while running it in your container right out of the box. Of course you can do that with JBoss as well, just takes a big longer to setup and configure. Some plug-ins like SolarEclipse attempt to address this and they are doing a great job (however they're commercial ;-)
Anyway, fact is that JBoss is based on JMX and that modular design is simply superior. Another fact is that JBoss has matured to a level where it frankly can do anything any commercial J2EE container can do. Unless you've already standardized on Websphere or Weblogic, I just don't see a reason not to take a very serious look at JBoss - it runs fast, it's stable, and there is plenty of support (and great books, obviously).
Just my 2 cents for all it's worth.
It depends on what your product is doing. If you simply need a web application, then there isn't much need to introduce all of JBoss into the mix unless you need to cluster it and manage a large number of nodes in a centralized manner. However, it is quite possible to slim JBoss down by stripping out many parts of the app server to make it lightweight and suitable as simply a web application container. I've actually used JBoss as a framework for a product before and it absolutely shined. We didn't need EJB so that was yanked out. We need portability through JCA, that worked beautifully. We implemented most of our functionality as JBoss SAR services and used the velocity-based template service for deployments of new components (see the user's guide and wiki, it's all quite well documented), all worked beautifully.
My personal experience, FWIW, is that taking advantage of the JBoss-specific architecture has its downsides:
-you lock yourself into jboss (not a horrible thing, really, how often do you want to change the appserver of a running application, but annoying)
-some of the implementations appear to be version dependant, e.g. your jboss-specific components might break when you upgrade
-there's are undocumented hurdles-e.g. I spent hours trying to figure out why my mbeans were refusing to load, eventually googled a mail message to learn that it relies on an (undocumented, as far as I can tell) naming convention.
In the end we just did POJO with MBean access to some basic parameters. But there's definately an (unfriendly) learning curve.
Simple... php inferior language
C much longer development time for server side stuff, with not too much performance gain in that area, and to few portable libraries which are really portable (thank Microsoft and the ISO consortium for that)
Python... much slower, and not really an improvement over java language wise
Lisp... not as common, you cannot find enough people
The ideal language for that kind of development probably would be smalltalk, but the Smalltalk vendors killed themselves in the Digital Parcplace fiasko and their inability to extend the common base to something java could deliver out of the box.
The only contender in the long run I see currently is Ruby, with their excellent rails framework.
What is your beef with Java? Java is excellent for server-side applications. Not so much for client-side, I agree, however there are some impressive java applications out there. (Limewire, Open Office, etc). JBoss and J2EE application servers are very good. I prefer a simple Tomcat server over JBoss myself. Not everyone should program in Java. Just web developers ;)
Why? Object Orientated Programming language. Very well documented. Code runs on multiple platforms. Interpreted language. (Running applications on a virtual machine gives you an extra layer of security between the application and OS).
There's no place like ~/
Either way, given that WebLogic and WebSphere cost a fortune, JBoss is the only "real" app-server that can be had for no dollars.
No, Sun has had a Real Appserver(tm) available for no cost for some time now (at least two years). They've even gone to the trouble of benchmarking it (both backed by Oracle and by MySQL) against the SPEC Java benchmark AND publishing the results so you can compare it.
Their next version is even Open Sourced and being developed under GlassFish at java.net.
I have heard this opinion off and on, but I have also heard this from people who either did not fully grasp the entire framework that is J2EE or from people who did and thought it was a waste of time for various reasons.
No matter how you build your framework, good OO design dictates that you seperate business logic from the presentation, control layers (commonly called MVC and idea as old as Smalltalk 80). If you stick with Servlets and JSPs you should at least have some type of BusinessObject that does the real work...
Now I don't know anything about what kind of apps you build, but I have worked on banking software, data processing intensive (math, parsing), apps, etc and they NEEDED EJBs. Especially MDBs (because some of those operations are hardcore math, i.e. long and must be done asynchronously with Transaction encapsulation/management).
EJBs are definitely not a silver bullet, and like anything they can be overused. But on the flipside, I have worked on more PHP styled apps that did everything in JSPs and Servlets, and they were awful to maintain!
EJBs are not all the same either, CMP Entity beans have more overhead, SLSBs are pretty light weight (especially if you preload the ejb container on deployment). You can make the nasty details pretty transparent, especially if you are smart enough to use SessionFacade and Composite patterns. And using DTOs, factories, and Entity beans can also mean that your real-time app objects can be worlds different than the DB.
For big systems, this is pretty important. It is well established by both SEI and IEEE that maintenance is 80% of the cost of a software system. So, if you build a multi-tier system correctly it can eb easy to understand and maintain.
That is all with the caveat that you have used the right set of tools for the job. A system that tracks data for a small company is alot different than banking software that manages billing for subcontractors, customers, accountants involving billions of dollars. Big systems like that will be in service for years, and enough hands touch it that a strong OO design can really help when someone else has to look at it.
Basically, it is extremely heavy-handed to make claims of J2EE dying. I don't speak for everyone either, but I know there are alot of big systems using EJBs that will be around for a long time. As they say, J2EE is the new COBOL.
FWIW, JSPs and Servlets are part of J2EE. They may run in the web container vs the ejb container, but they are all part of the same concept. Not all app servers support all J2EE features, but that is another matter (and that is the way it should be). And I do like Hibernate and Spring, but I try to use the right tools for the right job.
As such, I don't see anything seriously wrong with Java. Thanks to its clean and simple syntax and its rich library, I feel it lets me solve problems faster than many other languages. At least on the server, it runs at compiled speeds, and the base of free code to build on is enormous.
There are certainly "better" languages, for various flavors of "better". Lisp and Smalltalk come to mind. Look at Structure and Interpretation of Computer Programs for a glimpse at the awesome power of Lisp. Smalltalk programmers never cease to rave about what a joy it is to work with. These two languages suffer from lack of acceptance by the masses, something like why Microsoft and not {*nix|*BSD|BeOS|VMS} is the dominant operating system. I posit that it takes hardly more intellectual prowess to program in Java than in BASIC, but Lisp and Smalltalk are better suited for hardcore geeks.
The other languages you mentioned each have some glaring flaws:
J2EE is horribly complicated. But because it was backed by Sun, and still much more manageable than CORBA, it was happily accepted by the industry. The standard is improving, the code base is growing -- Java has momentum, and for better or worse it isn't going away anytime soon.
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
While I didn't find J2EE really compelling for a project I was working on back in 2003, JBoss in combination with both Hibernate and Spring was quite awesome. For those who don't know, Hibernate is a persistence framework for SQL databases; I found it to work very well with PostgreSQL. Spring is an MVC framework meant to make it easier to organize server-side application logic.
Some nice tools for building Java-based web-applications:
http://www.hibernate.org/
http://www.springframework.org/
http://www.jboss.com/
http://www.postgresql.org/
http://ant.apache.org/
http://www.eclipse.org/
Thanks, but no thanks... I've had issues with Visual studio fubarring my box, definitely don't want to play with beta software development tools. Why should software dev tools mess with the OS? Unless they are just as entangled with the kernel as IE? Anyone else has suggestions for C/C++ gui application development on a windows box?
The only contender in the long run I see currently is Ruby, with their excellent rails framework.
I would hardly call a framework where the object model has to be defined as database tables, and you then end up locked into a particular database product for the lifetime of your application 'excellent'. Compared to other systems, like Hibernate, where data can be defined as true objects, this is a huge step backwards.
disclaimer: I work for JBoss, but have been a J2EE programmer for as long as I can remember =)
Most of the enterprise Java community actually agrees with you, hence why the EJB3 specification is highly derived and influenced from Hibernate. Value Objects, Home interfaces, and redundant configurations are just some of the things that have been all but completely removed from the new spec. But "removal of annoying features" isn't the only thing that EJB3 is focusing on. There is also a sharp focus on the Keep It Simple Stupid methodology that made Hibernate so popular to begin with. There are sane/default configurations for practically everything now, and DB->Entity mapping has finally been addressed as a non-vendor specific detail of the spec. Don't forget the fact that EJB3 Entities can also be easily detached and re-attached to the container, as well as used completely outside of the J2EE container.
I encourage to check out the new annotation/POJO based EJB3 spec here:
http://java.sun.com/products/ejb/docs.html
Or, for a walkthrough of EJB3 and how to use it in JBoss, see our (IMO) excellent trailblazer:
http://trailblazer.demo.jboss.com/EJB3Trail/
And just for shits and grins, you should also check out JBossIDE's Hibernate & EJB3 Tools (shameless project plug!):
http://www.jboss.com/products/jbosside
arcane for life
Hmm...
;)
Isn't it nice, though, that you can be a server-side Java programmer during the day at work, and use the same skill set at home to hack together your client-side hobby projects?
Isn't it nice to be able to focus on a single language and really master it, instead of trying to keep several balls in the air at once?
Isn't it nice that if you ever wanted to, you could write an applet for your website instead of having to pay five hundred bucks for Flash authoring tools?
After all, with Java, the difference between web development and client-side development is just the libraries you choose... Isn't it "one stop shopping"?
Right?
Farewell! It's been a fine buncha years!
http://www.objectstyle.org/cayenne/index.html
http://jakarta.apache.org/tomcat/index.html
http://jakarta.apache.org/tapestry/
http://www.eclipse.org/
http://ant.apache.org/
Choose any database you want. Tapestry is simply AMAZING!!! Everything is a component. It is like have all of the coolest legos and building sites in not time. Also, if you don't like the block, it is EASY to make custom components. Howard Lewis Ship is a genius.
Okay, the Java world needs to really wake up and start buying into Cayenne. Get off the Hibernate kick!!! All I see is ways to improve Hibernate and Cayenne already has it all in place. Plus Cayenne and Tapestry were made for each other.
J2EE was a nice try, but way, WAY too complicated. Both Cayenne and Tapestry are straight-forward and easy to use, IMHO!!!