Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Java Books Media Programming Book Reviews

BEA WebLogic Server Bible 132

RickHigh writes "The BEA WebLogic Server Bible is an enjoyable read. If you have been using WebLogic off and on since before EJB (Enterprise JavaBeans) existed, you will still learn a bunch of new tricks. This is an excellent reference that can be read from cover to cover. The book focuses on small examples with an emphasis of deploying and configuring the examples in the WebLogic environment." BEA's WebLogic is an application server -- as such, it sits in a small enough niche that you won't find a full shelf of helpful books at your local Borders. If hosting applications for a large organization is part of your work, though, you should read on.
BEA Weblogic Server Bible
author Joe Zuffoletto et al
pages 1000
publisher Hungry Minds
rating 5 stars
reviewer Rick Hightower
ISBN 0764548549
summary The WebLogic Bible reference to have on hand.

There are plenty of examples of setting up your WebLogic configuration, with explanations of what the different parameters are and when to use them for Servlets, JSP, EJB, JMS, and more; just what you need when you are having those configuration problems and a great reference to have around when you get stuck. If you like going from concept to implementation, then this is the book for you.

Unlike some other WebLogic centric books, the Bible's coverage of EJB CMP/CMR was good. Also, the coverage of performance monitoring was really well done. And, the ideas for optimization and the thought process behind it was also really well done. These are just a few examples of a really well written technical manual--the missing WebLogic Manual.

A couple areas of concern (some just nits):

1) A few times the examples were WebLogic centric when they could have been written them in a cross platform manner (wrt J2EE ). (Note: A prerequisite of this book is a working knowledge of J2EE.)

2) The EJB examples hard coded the JNDI parameters instead of using the file in the classpath, which is the preferred approach for cross platform J2EE development.

Granted, at times you have to write things WebLogic centric to utilize WebLogic-specific extensions to J2EE, but the book also did this at times when it was not really necessary to do so. A J2EE veteran will catch the difference, and a J2EE novice will not. Bottom line: you should have a working knowledge of J2EE before reading this book and there will not be any problem.

Another problem with the book is that it covers WebLogic 6.1, while WebLogic 7.0 is already out. However, the material is still applicable to WebLogic 7.0. The book was released this year as was WebLogic 7.0. This in an unavoidable problem with books focused on such a target market. By the time they update the 1000-page book to WebLogic 7.0, WebLogic 8.0 will probably be out.

Also, in the next edition they should cover the Weblogic specific Ant tags in addition to the console and other means of deploying applications. Ant is the de facto method for building, deploying and testing J2EE applications, and a book like this should reflect this reality.

If you are new to WebLogic, I suggest that you get this book. If you have been working with WebLogic since before the EJB .8 spec., I suggest that you get this book. This book is not a J2EE tutorial, but it covers the basics and focuses on WebLogic specific areas of concern.

Consider this book recommended.

Links of note:

You can purchase WebLogic Bible from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

BEA WebLogic Server Bible

Comments Filter:
  • Re:Vendor lock-in (Score:4, Interesting)

    by cpfeifer ( 20941 ) on Wednesday September 25, 2002 @11:29AM (#4327617) Homepage
    Isn't the purpose of J2EE to avoid vendor lock-in? If that is the case then a generic EJB book coupled with the WebLogic manual should do the trick.

    Don't make me laugh, my lips are chapped.

    But seriously, yes that is the point. But each vendor has it's own little deployment nits. In my own experience, an app will cross deploy between BEA and JBoss with little/no effort. But cross deploying between BEA and iPlanet or WebSphere is a totally different (and far more frustrating) story.

    or actually give you a full fledged app server to begin with (JBoss)

    This is true, but BEA is the largest player in the app server market and many large organizations that currently are betting big on J2EE have a hard time basing their business on free software. You need someone on the hook when things go wrong. You need guarantees.
  • Re:Vendor lock-in (Score:4, Interesting)

    by pbur ( 88030 ) on Wednesday September 25, 2002 @11:34AM (#4327650)
    This is true, but BEA is the largest player in the app server market and many large organizations that currently are betting big on J2EE have a hard time basing their business on free software. You need someone on the hook when things go wrong. You need guarantees.

    Have you ever called BEA weblogic support? You practically have to tell them how to solve the problem. I have never really had anything successfully resolved without coming up with the solution myself. Not to mention they make you buy a support contract for every purchase of Weblogic. That means if you have a 4 CPU machine, you need to buy 4 1 year contracts of support that run concurrently. How crazy is that? They are a required purchase, there's no getting out of it.

    One of the many reasons we dropped them like a bad habit.
  • Weblogic & JBoss (Score:5, Interesting)

    by signe ( 64498 ) on Wednesday September 25, 2002 @11:49AM (#4327738) Homepage

    I'm actually in the middle of load/performance testing WebLogic and JBoss right now, and I'm suddenly realizing how pointless this is.

    Say our server hardware costs $6k. To use that box with WebLogic, it costs $40k total (hardware + 2 licenses because it's dual-CPU). To use that box with JBoss, it costs $6k (just hardware).

    It doesn't matter what the performance is. JBoss would have to perform incredibly poorly for it to be worth using WebLogic instead, because I can deploy 6 JBoss servers plus load balancing hardware for the cost of a single WebLogic server. So where WebLogic does 400 ops/sec for a particular load configuration, JBoss would have to do about 65 ops/sec to "break even". As it is, JBoss does about 300 ops/sec for the same load config.

    Now if I can just convince the developers that no, they do not *have* to have WebLogic...

  • Re:Weblogic & JBoss (Score:3, Interesting)

    by glwtta ( 532858 ) on Wednesday September 25, 2002 @11:55AM (#4327781) Homepage
    hmm, I am not going to go into WebLogic vs. JBoss (ok, I like JBoss), but it seems your developers are at least used to, or maybe even like WebLogic... how much is your company paying for their time? It's always something to consider.
  • Re:Small niche ? (Score:2, Interesting)

    by silversurf ( 34707 ) on Wednesday September 25, 2002 @12:06PM (#4327922)
    I don't think they meant "small" in terms of revenue or application size, I took it to mean size of deployment. The number of WebLogic users is relatively small because the number of possible customers is relatively small, they just pay alot of money for it. Sure the Enterprise Application Server market maybe 2 billion a year, that doesn't mean a company that makes products for it isn't in a niche. Niche just means you specialize for a specific industry and market and nothing else.

  • by samwhite_y ( 557562 ) <icrewps@yahoo.cRASPom minus berry> on Wednesday September 25, 2002 @03:50PM (#4330264)
    Nobody seems to be addressing some of the real painful spots in the current app server architectures. Jboss seems to do a better job of addressing these issues then other app servers, but I do not have the luxury of that choice.

    First, how are you supposed to do development in an environment where it takes almost a minute to restart the application and find out if your latest change is working properly? That type of coding harks back to the dark ages of coding when you had to wait minutes before the compile and run was finished. There are kludges for creating "simulated" app server environments that give you faster development times, but that can only take you so far.

    Secondly, it is practically impossible to create a distributable self-installing application that installs with no fuss into an app server environment. I am amazed that people are willing to put up with the configuration headaches for delivering app server solutions that they would never accept for their desktop applications.

    Thirdly, there is a constant confusion surrounding issues like "session" and "non-session" beans, maintaining "transaction compliance", and whole hosts of finagle issues. Many of these issues have a drastic impact on performance depending on your choice, and usually the choices that give sufficient flexibility and acceptable performance are only available with completely proprietary vendor specific solutions.

    As far as I can tell, the original vision of having easily developed, easily deployable, and high performing server-side application solutions has been lost and has been replaced by an environment in which it is difficult to create code, painful to deploy solutions, and a real headache to tune for speed.

    This is such an unfortunate fate for EJBs. In the original vision, EJBs were to be the server side equivalent of Microsoft's ActiveX controls for the desktop. There are still some good ideas buried in the EJB specs, but the heavy weight app servers have buried these little nuggets inside massive overachieving bloat ware.

Machines that have broken down will work perfectly when the repairman arrives.