Discussions

News: Free Book: The J2EE Architect's Handbook

  1. Free Book: The J2EE Architect's Handbook (48 messages)

    TheServerSide is offering The J2EE Architect's Handbook for full download. Derek Ashmore's book is written for technical architects and senior developers tasked with designing and leading the development of J2EE java applications, providing numerous tips, tricks, and "best practices" along the way.

    Book Topics

    • Design J2EE applications so that they are robust, extensible, and easy to maintain.
    • Apply commonly used design patterns effectively
    • Identify and address application architectural issues before they hinder the development team
    • Document and communicate the application design so that the development team¬ís work is targeted
    • Avoid common mistakes that derail project budgets and timelines.
    • Guide the development team through the design and construction process.
    • Setup effective procedures and guidelines that increase stability and decrease bug reports
    • Effectively estimate needed resources and timelines
    Download the entire book: The J2EE Architect's Handbook

    Threaded Messages (48)

  2. That book claims that "Caller platform requirements" for EJB is "Java compliant only" and "Communication method supported" is "Synch. only". Both claims are wrong for EJB 2.0+.

    Since that book have been published in 2004 it makes all that touting about "successful arhitects" and "knowledgeable examples" quite questionable. Also those examples use some weird naming standart with variable names starting with underscore.

    The author is aware of Message Driven Beans however that table in page 38. states that coupling for EJB is "tight", but for JMS "loose".

    Also the same table states that Web Services standard supports JTA and HTTP supports "local" transactions. Very doubtful ideas.
  3. It's a shame to have a book of such a poor level available to download in the TheServerSide
  4. It's a shame to have a book of such a poor level available to download in the TheServerSide
    I tend to agree.
    The book is not at all up to date. TopLink is mentioned, but not Hibernate!
  5. Free Book: The J2EE Architect's Handbook[ Go to top ]

    At first glance, I wouldn't recommend this book to someone who doesn't have good experience in Java development. They need to be able to separate the wheat from chaff.

    For instance:

    The good: "Consider recording use Cases in database."
    The bad: involving Data Modelers in OO developement.
    The Ugly: recommending Value Objects for transfering data between layers.
  6. Free Book: The J2EE Architect's Handbook[ Go to top ]

    The Ugly: recommending Value Objects for transfering data between layers.
    What is a better way ?
  7. The Ugly: recommending Value Objects for transfering data between layers.
    What is a better way ?
    Transfer Objects ;-)
  8. Free Book: The J2EE Architect's Handbook[ Go to top ]

    The Ugly: recommending Value Objects for transfering data between layers.
    What is a better way ?
    Don't transfer data/values. If you must, at least do it via interface - i.e. PersonVO implements Person.
  9. Free Book: The J2EE Architect's Handbook[ Go to top ]

    The Ugly: recommending Value Objects for transfering data between layers.
    What is a better way ?
    Don't transfer data/values. If you must, at least do it via interface - i.e. PersonVO implements Person.
    That still means you have to write code for interface as well as the implementation. Not a optimum slution when your application business objects are going to evolve

    My preferred solution , far from perfect , is to use Dynabeans + beanutils .
  10. Free Book: The J2EE Architect's Handbook[ Go to top ]

    The Ugly: recommending Value Objects for transfering data between layers.
    What is a better way ?
    Don't transfer data/values. If you must, at least do it via interface - i.e. PersonVO implements Person.
    That still means you have to write code for interface as well as the implementation. Not a optimum slution when your application business objects are going to evolveMy preferred solution , far from perfect , is to use Dynabeans + beanutils .


    Use a better IDE? In Eclipse - extract interface. Then refactor as needed.
  11. Free Book: The J2EE Architect's Handbook[ Go to top ]

    Use a better IDE? In Eclipse - extract interface. Then refactor as needed.
    Why ? You are still creating clases and code for obejcts that have no fucntion other than to tranfer data. What benefit would you get by maintaining these classes ? Every time your domain object changes, you would have to create new classes. Why not use a dynabean and bind properties to it using reflection and use the dynabean to serve as DTO ?
  12. Free Book: The J2EE Architect's Handbook[ Go to top ]

    Why ? You are still creating clases and code for obejcts that have no fucntion other than to tranfer data.
    I wouldn't create classes for that.
     What benefit would you get by maintaining these classes ? Every time your domain object changes, you would have to create new classes.
    Nope. Just redesign/refactor.
     Why not use a dynabean and bind properties to it using reflection and use the dynabean to serve as DTO ?
    I don't use DTOs. No reason this can't be used with real objects, though. :)
  13. Free Book: The J2EE Architect's Handbook[ Go to top ]

    I think our disconnect is that I am assumimg we are using entity EJBs at the integration layer. I think you are using Hibernate/or other ORM etc. at this tier. So thats why I have a need for a POJO to transport the data through the tiers where as you don't.

    So with entity EJBs , there is no alternative to usiing DTO or Dynabean/Map to serve this purpose.
  14. Free Book: The J2EE Architect's Handbook[ Go to top ]

    I think our disconnect is that I am assumimg we are using entity EJBs at the integration layer. I think you are using Hibernate/or other ORM etc. at this tier. So thats why I have a need for a POJO to transport the data through the tiers where as you don't. So with entity EJBs , there is no alternative to usiing DTO or Dynabean/Map to serve this purpose.
    I was wondering the same thing. I see your point. I still would hide the fact I was using DTOs. Contain the madness. :) And put up big warning signs.
  15. Free Book: The J2EE Architect's Handbook[ Go to top ]

    Don't transfer data/values. If you must, at least do it via interface - i.e. PersonVO implements Person.
    You mean not to use distributed arhitecture ?
  16. Free Book: The J2EE Architect's Handbook[ Go to top ]

    Don't transfer data/values. If you must, at least do it via interface - i.e. PersonVO implements Person.
    You mean not to use distributed arhitecture ?
    Nope. This is easily done with interfaces. Value objects are not required to do a distributed architecture.
  17. The author advocates using value object for communication between all layers in an application. He has the data layer create a value object that is sent to the services (or deployment layer as he calls it) that is then used to create business objects, which then pass another value object up to the presentation tier. The value object patter was originally developed as a necessary evil for reducing the calling overhead between PHYSICALY DISTRIBUTED LAYERS of an application, and should be considered an unfortunate necessity when one is forced (based on the requirments of the application)to physicaly distribute his application layers. The author just seems to assume a distributed architecture and provides no good discussion on the tradeoffs of distribution.
  18. The author advocates using value object for communication between all layers in an application. He has the data layer create a value object that is sent to the services (or deployment layer as he calls it) that is then used to create business objects, which then pass another value object up to the presentation tier. The value object patter was originally developed as a necessary evil for reducing the calling overhead between PHYSICALY DISTRIBUTED LAYERS of an application, and should be considered an unfortunate necessity when one is forced (based on the requirments of the application)to physicaly distribute his application layers. The author just seems to assume a distributed architecture and provides no good discussion on the tradeoffs of distribution.
    I agree. I left the EJB issue alone, but thanks for going there.
  19. Free Book: The J2EE Architect's Handbook[ Go to top ]

    "The bad: involving Data Modelers in OO developement.
    Data Modelers bring with them their expertise in building models which can actually work in enterprise environments. At the end of the design phase, if your object model is not backed up by a rock solid data model -- your project is DOA.

    Also remember, OLTP is only one part of your enterprise application's duties; it must also play nice with Data Mining and warehouse, legacy data conversion and external data feeds.

    My personal approach is to bring in data modeling team and use the Logical Data Model as a starting point of object model -- keeping a mostly a one-to-one correspondence between LDM entities and the java domain objects e.g . entity ejbs.
  20. Free Book: The J2EE Architect's Handbook[ Go to top ]

    "The bad: involving Data Modelers in OO developement.
    Data Modelers bring with them their expertise in building models which can actually work in enterprise environments. At the end of the design phase, if your object model is not backed up by a rock solid data model -- your project is DOA.Also remember, OLTP is only one part of your enterprise application's duties; it must also play nice with Data Mining and warehouse, legacy data conversion and external data feeds. My personal approach is to bring in data modeling team and use the Logical Data Model as a starting point of object model -- keeping a mostly a one-to-one correspondence between LDM entities and the java domain objects e.g . entity ejbs.
    The problem is people bring in old bad habits. I'm not saying all data modelers are bad. I guess it depends on what your definition of a rock solid data model is.

    If I am starting from scratch, a database is some where to persist my objects.
      
    As for datawarehouse and data mining - well not much you can do except "wall it off". Those are affectively "exploded" objects. In other words, take objects and apply business rules and export. Treat it as output in the same same sense that a PDF should be. Getting it "back in" is more difficult. Probably should never happen.

    Passing "data" around, especially large volumes, is the/a bane of modern computing. We end solving problems that shouldn't have been problems in the first place.
  21. Free Book: The J2EE Architect's Handbook[ Go to top ]

    The problem is people bring in old bad habits. I'm not saying all data modelers are bad. I guess it depends on what your definition of a rock solid data model is.If I am starting from scratch, a database is some where to persist my objects.  As for datawarehouse and data mining - well not much you can do except "wall it off". Those are affectively "exploded" objects. In other words, take objects and apply business rules and export. Treat it as output in the same same sense that a PDF should be. Getting it "back in" is more difficult. Probably should never happen.Passing "data" around, especially large volumes, is the/a bane of modern computing. We end solving problems that shouldn't have been problems in the first place.
    I am not sure not starting without an LDM is agood idea in the first place. Typically, enterprises already have data repositier and applications. You really can't ever code an enterprise application from scratch and you cant "wall it off" as well : walled off data is one reason why business outgrows its applications. An ERwin diagram ( or whatever LDM tool you prefer) is your guarantee that everyone will be able to figure out what you appliaction is doing, extract metadata if needed and integrate as desired.
  22. Free Book: The J2EE Architect's Handbook[ Go to top ]

    I am not sure not starting without an LDM is agood idea in the first place. Typically, enterprises already have data repositier and applications.
    Then trying to shoehorn a Java app on top of it is bad thing. Use COBOL instead.
    More than one app accessing a "data store" is a bad thing, no matter the language though.
      You really can't ever code an enterprise application from scratch and you cant "wall it off" as well : walled off data is one reason why business outgrows its applications.
    I would say coding applications around data stores is a bigger reason. The biggest is changing needs of the business. The more flexible the app (which includes the "data") the longer lasting it will be.
     An ERwin diagram ( or whatever LDM tool you prefer) is your guarantee that everyone will be able to figure out what you appliaction is doing, extract metadata if needed and integrate as desired.
    Ok. If you think so. So, then create one after the fact. Most ERD tools reverse engineer dbs.
  23. The worst Java book I have ever seen[ Go to top ]

    Usually I do not write reviews, but this book is so bad that I feel compelled to speak out.

    The book is highly unorganized. Althoug it is devided into four sections: planning, designing, building, and testing and maintaining, the content seems to have been randomly scattered throughout the sections. In the planning section you will find subsections that seem unrelated to planning, and that should have gone into the design section. And, in a subsection in which, from the title, you would expect to find a discussion of tradeoffs between different architectural styles (there is no such discussion in the book) you get a seemingly ad-hoc sampling of some low level coding advice that looks like it was inspired by Bloch’s Effective Java book.
     
    Much of the material is dated. An example of this is that he describes patterns that may have been valid if you were developing an EJB 1.1 application with entity beans, such as using a coarse grained value object to reduce the overhead of calling multiple get methods on a entity bean.

    All the material in the book is presented at a 50,000 foot level. For example, even though transaction management is a critical consideration in J2EE applications, it is glossed over in a few pages without a single mention of transaction isolation, and optimisitic vs. pessimistic locking.

    For a book that claims to be a comprehensive handbook there are huge gaps in the material covered. For example, you will not find any discussion of IoC frameworks such as Spring, Avalon, or Pico Container, even though these frameworks have become very popular in the J2EE world. In fact you will not even find any discussion of alternatives to singleton style factories for accesing resources. Also there is no discussion of agile development techniques such as test first development, continues integration, etc. The only place wehre he mentions including the running of unit tests in the build is in the senctence: "I've seen projects that have gone so far as to include the running of unit tests in the build script". This is of course a common practice, yet he presents it as if it is surprising to find people going to such an extream. It would be more surprising to have been on a project in the last couple years that did not take this aproach.

    The book describes the “layers’ of a J2EE application as:
    1. The DAO Layer
    2. Business Object Layer
    3. Value Objects Layer
    4. Deployment Layer
    5. Presentation Layer
    6. Architectural Component Layer

    One problem with this structure is that the layers of a J2EE application have been around for a long time, and have well established names. Eschewing the common terms in favor of your own terminology (i.e. changing Services Layer to Deployment Layer) is not going to help someone who must communicate with other’s who probably only know the common J2EE terminology.

    A far more serious problem is that value Objects and Data Access Objects are not architectural layers at all. The value object pattern is one pattern for transferring data between layers (The author makes no mention of the fact that many consider this use of value objects to be an anti-pattern, rather than a pattern, and omits any mention of other options)

    The DAO pattern is used to implement a consistent interface that decouples the domain layer from the persistence layer. Obviously the author completely misunderstands this point, as he refers to Entity EJB’s as being a possible implementation of a DAO. The DAO pattern might be used to access the entity bean, which is one way of implementing the data access layer. Elsewhere in the text, the author seems to use DAO in the correct context, but then provides the dubious advice that DAO layers should only be used if the application must access multiple databases. He makes no mention that even if you are using the same database you may want to use different data access technologies, and programming to an interface instead of an implementation will allow this in a consistent way. For example you may want to use Both Hibernate and JDBC, and you don’t want your domain objects to be coupled to either of these technologies.

    Another example of a very fundamental mistake that the author makes is in his description of use cases. He touts the advantages of use cases, and then provides examples of the following form:

    All use cases should be of the form: The system shall <X>

    He then lists a number of examples of this as in:

    1. The system shall authenticate the user
    2. The systems shall …

    Obviously these are not use cases, but are exactly the sort of traditionally structured functional requirements that use-cases were designed to avoid. I can imagine the embarrassment that making such an obvious mistake would cause to the unsuspecting Jr. Developer, who had uncritically relied on the advice in this book.

    Although I could go on for a number of pages (Nearly every page of this book is deserving of criticism) I don't have the stamina to go on much further. Overall, I feel as if the author must have skimmed a number of J2EE books, and then, based on these sources, compiled a hodge-podge of spotty, dated, inaccurate, and misleading advice.

    FYI, the best books I have read, that cover the topics that this book was intended to cover, are: Expert One-on-One J2EE Design and Development (a book that actually is a J2EE architect's handbook), by Rod Johnson and Applying UML and Patterns, by Craig Larman. Although these books are not free, they both contain invaluable knowledge for aspiring J2EE Architects.
  24. who would buy it ?
  25. Must read on this subject is expert "One-on-One" series by Rod Johnson.
    Best I have read so far on this subject.
  26. This is a self published book![ Go to top ]

    After posting my review, I was feeling perplexed as to how a book with so many fundamental problems could ever make it to press. I decided to check with the publisher to find out how they had done their technical review. I quickly realized, however, that this is a self-published book. The author is the CTO of DVT, which is also the Publisher of the book. I didn’t bother contacting the publisher, after I made this realization.
  27. When I looked up this book on Amazon (it was easy to find because the author/publisher had purchased a paid placement), I was astonished to find that it had recieved excellent reviews. Two of the reviews were from individuals, and one from an entity called the Midwest Book Review. Each of the In fact there were three reviews, each of which lavished praise on the author, and gave the book 5 stars:

    My first thought is that maybe I had the wrong book, but this was not the case. How could this be possible? When I examined these reviews in detail my naturally cynical personality took over.

    <REVIEW 1>
    There are a lot of J2EE books on the market and many of them are very good, but they are all focused on one or two aspects of a J2EE project. The J2EE Architect's Handbook is unique in that it is the only book I have found that takes you through the complete process of delivering a J2EE based project.
    I would highly recommend this book to anyone involved in delivering J2EE based applications, regardless of whether you are new to J2EE or have been delivering J2EE projects for years.
    </REVIEW 1>

    <REVIEW 2>
    This is a practical book targeted toward working architect's and designers in a business setting. This book concentrates on making you successful in an architect role and manage the project.
    I liked the fact that it concentrated on the most heavily used portions of J2EE and didn't bog me down with stuff I don't use. It's also organized well and concise so I can get the important points in very little time.
    </REVIEW 2>


    I found a number of suspicious elements to the two reviews submitted by individuals. For one, the structure and grammar seem to be unnervingly similar. Second, both reviews happened to be posted from Chicago, The same city DVT is located in. Third, they were both posted on the exact same date. What makes these points all the more suspicious is that these are the only individuals to have reviewed the book on Amazon, even though it was published in May. I tried to find information about the reviewers but neither of them had ever reviewed a book before, and neither had provided personal information.

    So, being unable to pursue these leads any further, I decided to try to find out about the review process at Midwest Book Review. Unfortunately, I was unable to determine who there had written the review. I did, however, find a few interesting statements on their website:

    The Midwest Book Review is an organization of volunteers

    The Midwest Book Review gives priority consideration to small publishers, self-published authors, academic presses, and specialty publishers

    I then tried to find out information about DVT. I went to dvt.com, a very amateurish looking website, but could find no mention of corporate history, executives, or even any other employees besides the author. The only thing that would lead me to believe that this is a real company is that they are trying to sell high end J2EE Project Management, Architecture Review, and Training services, which are all based on the "development philosophy" espoused in his/their book (Thankfully, this is the only book that DVT Publishing has ever published, and with any luck it will be the last).

    Perhaps this all just a big coincidence (I am by nature a bit of a cynic) but it would be interesting if anyone else has information on this company or the reviews that this book has received.
  28. make a whois...[ Go to top ]

    http://www.whois.net/whois.cgi2?d=dvt.com

    and you will not be surprised by the results...
  29. make a whois...[ Go to top ]

    Thanks,
    I should have thought of that myselft;)
  30. CementJ[ Go to top ]

    The author seems to tout cementJ. Does anyone have any experience with this product?
  31. Not Recommended[ Go to top ]

    I have given a bird's eye view to this book, and will recommened every one not to get thier cocepts get ruined by the text in the book.

    I feel sorry for the author. Not a worthy book.
  32. What is a good book?[ Go to top ]

    After reading the above comments, I'm curious as to what some of you recommend to read?

    I would be more interested in areas such as:
    Chapt. 6 - Creating the Object Model
    Chapt. 7 - Creating the Data Model
    ... and so forth.

    I started reading this book yesterday (chap1 - chapter7) and now I'm afraid I may have been getting the wrong information based on what this thread has to say about the book.

    I liked how the author didn't talk over you and got straight to the point with examples. For instance, how he gave examples of a UML statement and then gave an object identification table.

    For example:
    Noun(From UML) | Java Object
    ------------------------------------
    Interface | ReportTemplateInterface
    ...
    Trust Customer User | TrustCustomerMember

    I thought 'GREAT! This is want I needed!' but I guess I may have been 'duped'.
    So I'm looking for any suggestions you may have.

    thanks

    BjM
  33. What is a good book?[ Go to top ]

    Not to be mean ...

    But if you need a book and are not able to separate the "wheat from the chaff", then I suggest getting a mentor. That is the best way to learn. Someone you can bounce ideas off of.

    I don't think any part of this book doesn't have quicksand mixed in with solid ground.
  34. What is a good book?[ Go to top ]

    Not to be mean ...But if you need a book and are not able to separate the "wheat from the chaff", then I suggest getting a mentor. That is the best way to learn. Someone you can bounce ideas off of.I don't think any part of this book doesn't have quicksand mixed in with solid ground.
    Hmmmm. That's a good idea actually.
    Any takers?

    I like Matt Raible's new books Spring Live. He'd be great. But the guy doesn't have time to breath right now.

    There is NO ONE in my area ... so it has to be a 'virtual' mentor.

    Anyone bored?

    BjM
  35. What is a good book?[ Go to top ]

    I would just add, that I have seen many "Mentors" who are very good at selling themselves, but don't actually have a very good understanding of software development. For this reason, I would recommend that you take a look at some of the aformentioned resources before you start looking for a Mentor. This way you will have some background to be able to judge the quality of a potential Mentor.
  36. What is a good book?[ Go to top ]

    I would just add, that I have seen many "Mentors" who are very good at selling themselves, but don't actually have a very good understanding of software development. For this reason, I would recommend that you take a look at some of the aformentioned resources before you start looking for a Mentor. This way you will have some background to be able to judge the quality of a potential Mentor.
    True. I wasn't so much thinking of someone who was selling a Mentor service. Definitely avoid someone who has reason to sell you their prefered vendors product or service.

     
    The best thing to have is instinct. How does he know the books you suggested are good? Guess he will have to trust you. :) From what I've seen you say here, I think he can. For what my word is worth.

    What would be nice is a mentor network. Maybe via JXTA.
  37. What is a good book?[ Go to top ]

    A Very Good point.

    I think the reason that I was so irate about this book is that there is already a very high signal-to-noise ratio in the software development industry which makes it hard, when you are first starting out, to decide who is BS-ing you and who actually knows what they are talking about (I, as I believe is the case with most developers, learned this lesson the hard way).

    When someone produces a book (which seem to me to be for no other purpose than to increase his/her consulting revenue) that simply regurgitates what many others have already said with a few changes of terminology for good measure), it simply adds more noise and confusion to an already loud and confusing environment.

    I guess part of the "starting out" process must be to wade through all the crap out there in hopes of bumping into something worthwhile; For, as you have pointed out, everyone must start somewhere, and when you do you are necessarily placing a great deal of trust in someone without actually having the requisite background knowledge to judge their quality.

    Perhaps the best advice for neophytes then, would be to look into what resources the industry as a whole has singled out for distinction, at least then you have a somewhat better chance of having started with something that has been tested and reviewed by others (Although, of course, there are still no guarantees).

    JJ
  38. What is a good book?[ Go to top ]

    I've been lucky. Since about 1998 I've found a kindred soul at all the places I've been. Not that we agreed 100%. I have up till now. Man, it is tough not having one.
  39. What is a good book?[ Go to top ]

    I would just add, that I have seen many "Mentors" who are very good at selling themselves, but don't actually have a very good understanding of software development. For this reason, I would recommend that you take a look at some of the aformentioned resources before you start looking for a Mentor. This way you will have some background to be able to judge the quality of a potential Mentor.
    I think I'm going to purchase the book you mentioned above. I checked it on Amazon and the reviews seem quite good.

    As Mark mentioned earlier, it seems you have to watch our for what you read on those reviews as well.

    But, I will bite the bullet and purchase the book.

    Thank you both (Mark) for you comments.

    BjM
  40. What is a good book?[ Go to top ]

    Fortunatly, I can recommend a book that I think will satisfy your requirments. Like I said in my critique, it seems as if the author has skimmed a number of books, and then regurgetated, in his own words, some of the content from each.

    A great book that covers many of the same techniques for developing the Object Models is Craig Larman's Applying UML and patters, which is probably the source for the regurgited content that you gave as an example. There is also a short (2 CD) multimedia training CD based on the book that you might also find helpful.
  41. What is a good book?[ Go to top ]

    Well its been mentioned on here a few times already but Expert One-on-one J2EE Design and Development by Rod Johnson is one of the best and comes with a great library framework.
  42. One last comment[ Go to top ]

    I would urge anyone participating in this discussion to give an honest review of the book on Amazon. That way potential buyer can get a "greater range of perspectives" before buying the book.
    Thanks,
    JJ
  43. One last comment[ Go to top ]

    I'm glad it was FREE.
    Thank you TSS!

    But you are right, it is frustrating. I've been developing in PHP for 4+ years and when I think back to how I started, there were maybe 3 books out there in PHP.

    I bought one book, it got me started for about a week, but then I realized the BS you mentioned above on my own. So I do feel your pain.

    I really do not want to wait 4 years to feel very comfortable with Java! I'm really excited about finally learning it. I think I bought my first Java book in 1996 and never got past the first chapter (pretty much because I was more interested in Corel Draw at the time).

    I spend more time trying to find out what's good (books, sites, articles) on Java then I do learning the actual technology.

    It's not just finding out what is BS in the above resources, but there's the whole other thing about what Servlet Container, O/R Mapping, JDO,SQL Maps, etc.. then there is the whole thing about Tapestry VS Sitemesh, or JSP VS Velocity etc etc etc... Wheeewww I just want to program!!! haha.

    Seriously though, I have realized these technologies are the path I want to take:

    Spring/SpringMVC
    Sitemesh
    Hibernate (I'm lucky to have full control over the DB)
    Velocity

    My point is to NOT turn this into a debate over technologies, rather a debate over the actual learning process/resources there are out there.

    Rod Johnsons Book (expert one on one) is great.. took 3 months for me to get the damn thing. It was way over my head when I first.... 'read' through it. Still alot of it is over my head. I think its mostly terms like 'IOC', etc.. There is the assumption that I learned EJB's and CMP etc.. Well, in the learning process of trying to figure out what to learn in the first place, I have taken Rod's word as the word of GOD :-| and I haven't bothered down the sacret path of Jboss/Weblogic/Websphere etc... (Meaning EJB Containers) if I do not need to worry about them. (thank god really!)

    I find Informit a great site, because I get the book when I want it... (ie NOW), and I'm thinking of adding 'Faster, Lighter, (quicker?) Java' I think that's what it is... any thoughts?

    BjM
  44. One last comment[ Go to top ]

    Well, in the learning process of trying to figure out what to learn in the first place, I have taken Rod's word as the word of GOD :-| and I haven't bothered down the sacret path of Jboss/Weblogic/Websphere etc... (Meaning EJB Containers) if I do not need to worry about them. (thank god really!)... any thoughts?BjM
    In real life you will need all those J2EE servers. I have been developing in J2EE 4+ years and I have never lived a day without one or another J2EE server. After all you cannot deploy a single JSP without a WEB container.

    Middleware is everywhere.
  45. One last comment[ Go to top ]

    In real life you will need all those J2EE servers. I have been developing in J2EE 4+ years and I have never lived a day without one or another J2EE server. After all you cannot deploy a single JSP without a WEB container. Middleware is everywhere.
    I'm sorry, I didn't mean to disregard them entirely, I meant the EJB aspect. But I'm sure there is a factor of legacy code that a developer will run into, and I'm sure in the future, I may have no choice but to work with EJB's etc.
  46. Lessons learned[ Go to top ]

    Yep, this book was a great disappointment. I started out by reading it avidly and without any doubts, mainly because it was posted proeminently on TSS. Then as I read on, I couldn't help but notice increasingly the mediocrity of the material. Finally I identified some serious crap, and came to my senses. I was a great confort to read this thread. On the down side, I have to delete this crap from my brain. On the up side, it was an opportunity to exercice my judgment, and verify that my instincts were right! I'll be much more cautious in the future. And yes, TSS should definitely be more cautious too ;)

    Miguel
  47. The URL:
    http://computerbooks.web.com
    http://www.maththinking.com/boat/computerbooks.html

    It's the best free computer books web site in the world: if you search "Free Computer Books" in Goolge, Yahoo, MSN, etc, that site is the #1 in the result.

    The alternative URL:
    http://www.maththinking.com/boat/booksIndex.html

    Enjoy!

    -John
  48. Bad directions[ Go to top ]

    Somehow this book had some information that I condisdered good. I read a chapter or two. But now I read all these comments here and I wonder: why is it still available on TSS? I don't want to read crap, and I'm not in the position to decide what is good and what is bad quality yet..
  49. The J2EE Architect's Handbook[ Go to top ]

    After reading this book, I think, this book has been written by inexperienced programmer. The package 'CementJ' referred by author has legacy code and doesn't seems to have any quality of J2EE architecture like maintainable, reliable etc.

    -Vinit