|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 60
Messages: 60
Messages: 60
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Free Book: The J2EE Architect's Handbook
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
|
|
|
Message #134618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134638
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
The Ugly: recommending Value Objects for transfering data between layers. What is a better way ?
|
|
|
Message #134641
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
The Ugly: recommending Value Objects for transfering data between layers. What is a better way ?
Transfer Objects ;-)
|
|
|
Message #134645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The worst Java book I have ever seen
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.
|
|
|
Message #134647
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
"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.
|
|
|
Message #134652
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How the auther advocates using value objects
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.
|
|
|
Message #134654
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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 .
|
|
|
Message #134657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
"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.
|
|
|
Message #134660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How the auther advocates using value objects
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.
|
|
|
Message #134666
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134667
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't transfer data/values?
How do you write an application that does not transfer data? Pass objects. You know, OOA/OOD/OOP. :)
|
|
|
Message #134671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134699
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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 ?
|
|
|
Message #134700
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134726
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
Must read on this subject is expert "One-on-One" series by Rod Johnson.
Best I have read so far on this subject.
|
|
|
Message #134728
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is a self published book!
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.
|
|
|
Message #134735
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I am very suspicious about this book!
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.
|
|
|
Message #134747
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
CementJ
The author seems to tout cementJ. Does anyone have any experience with this product?
|
|
|
Message #134749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not Recommended
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.
|
|
|
Message #134756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS MUST WITHDRAW THIS BOOK FROM THEIR WEB SITE
It's a shame to have a book of such a poor level available to download in the TheServerSide
|
|
|
Message #134761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't transfer data/values?
How do you write an application that does not transfer data? Pass objects. You know, OOA/OOD/OOP. :)
What other are objects than ADTs, that encapsulate data and provide methods upon that data. Or is it the "setter/getter are evil"-thing again?
Regards,
Dirk
|
|
|
Message #134787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't transfer data/values?
How do you write an application that does not transfer data? Pass objects. You know, OOA/OOD/OOP. :)
What other are objects than ADTs, that encapsulate data and provide methods upon that data. Or is it the "setter/getter are evil"-thing again?Regards, Dirk
No, getters and setters are not bad. But an object that only has getters and setters is "a bad smell". And to come right out and call it a value/data/dt object, well you can see the pile that is making the smell. If the object has anything more than fields and accessors then it by definition is not a value/data/dt object. Funny how methods creep into them.
|
|
|
Message #134817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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 ?
|
|
|
Message #134853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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. :)
|
|
|
Message #134899
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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
|
|
|
Message #134900
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134902
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Free Book: The J2EE Architect's Handbook
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.
|
|
|
Message #134903
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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
|
|
|
Message #134915
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134919
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134924
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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
|
|
|
Message #134928
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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
|
|
|
Message #134929
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One last comment
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
|
|
|
Message #134958
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One last comment
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
|
|
|
Message #134981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a good book?
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.
|
|
|
Message #134983
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One last comment
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.
|
|
|
Message #134989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't transfer data/values?
How do you write an application that does not transfer data? Pass objects. You know, OOA/OOD/OOP. :)
What other are objects than ADTs, that encapsulate data and provide methods upon that data. Or is it the "setter/getter are evil"-thing again?Regards, Dirk
No, getters and setters are not bad. But an object that only has getters and setters is "a bad smell". And to come right out and call it a value/data/dt object, well you can see the pile that is making the smell. If the object has anything more than fields and accessors then it by definition is not a value/data/dt object. Funny how methods creep into them.
I think, objects just encapsulating data and exposing their data through getter/setter method doesn't have neccessarily a "bad smell". There might be parts of a system, that are just interested in data, depending on the architecture you choose for the system.
In my opinion it strongly depends on how you view your system: from a "business-centric" perspective, i.e. the system is composed of business- or domain-objects, or from a "service-centric" perspective, i.e. the system is composed of (more or less) loosely coupled services.
We often choose the latter when building web-applications, our architecture mainly looks as follows:
We have a presentation layer, responsible for presenting data to the user, collecting data from the user, realizing the "page-flow", and invoking components that encapsulate the business logic needed to fulfill the use-case(s). These components reside in a "use-case controller"-layer, and, technically, are stateless session beans. They invoke the services needed to fulfill a certain uses-case in the correct manner, i.e. the act as the "glue" between the services. The services (residing in a service-layer) provide interfaces for fulfilling their specific tasks, returning the results as data-transfer-objects (or value-object, whatever you may call it) back to the use-case controller. The use-case controller in turn collect the results from the services and (optionally) assemble objects, which are returned to the presentation layer.
This architecture, definetly, does not conform to "traditional" OOA/OOD. Nevertheless, it works very well (at least for us). I think you cannot say that this approach is better or worse than using "pure" OO, where you have the business logic encapsulated within you business object. It's just a _different_ architecture. I further think, that there isn't the _one_ good architecture, one may work better in some cases, while the other may work better in other cases. So, just saying DTOs have a "bad smell" just because it isn't OO is not (in my opinion) a valid statement.
Any comments, opinions? I'm really interested in what the "community" thinks upon that topic.
Regards,
Dirk
|
|
|
Message #135004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS MUST WITHDRAW THIS BOOK FROM THEIR WEB SITE
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!
|
|
|
Message #135015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One last comment
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.
|
|
|
Message #136328
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lessons learned
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
|
|
|
Message #166457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
I agree with Dirk on the subject of VO's. I use a very similar approach in creating the business tier. There is nothing wrong with objects that get/set data. Business objects can also be very similar to value objects by design. The business tier should model reusable business objects, and preferably each should be designed to an interface. I design the business tier wrapped using a service-oriented approach, and use the very common facade paradigm to access the business tier and the business objects on that tier. Software architecture can be challenging and really depends on the context of the system/application you are developing in, as well as the resources available, etc.
I also do not agree in 'pure' OO - there is always a balance between performance, simplicity and flexibility that must be weighed. Any architect knows that making everything an object is bad, and will increase complexity and decrease performance.
|
|
|
Message #168135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
I think there is a good reason for VO/DTO. In Java it is
not possible to use structs like in C++, C# or whatever. A
DTO is just an object instead of a struct to encapsulate data and it just exists because there is no other way.
Think of WebServices! Transfering an object to and from a webservice is nothing else than a DTO. There are no methods only public fields. This object contains data we want to
transfer and nothing else.
|
|
|
Message #168150
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
Any architect knows that making everything an object is bad, Hmmm. Everything in Java is an object, except primitives. In languages like SmallTalk - everything is an object.
and will increase complexity and decrease performance. From what I have seen misuse of DTO's increase the complexity of the application.
|
|
|
Message #168151
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
I think there is a good reason for VO/DTO. In Java it isnot possible to use structs like in C++, C# or whatever. Right. And there is a good reason there are none.
A DTO is just an object instead of a struct to encapsulate data Add methods to it and WALA, you have an OO object (odd to have to say it that way).
Think of WebServices! Transfering an object to and from a webservice is nothing else than a DTO. This doesn't sound like a selling point for [SOAP] webservices. This is one thing I have against webservices. If I send serialized objects, I can use the same class and language on both ends without having to duplicate logic.
There are no methods only public fields. This object contains data we want to transfer and nothing else. I suggest you check out how object serialization works. It will transfer only what you need it to.
|
|
|
Message #168174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
A DTO has methods, e.g. equals, hashcode (for hashmaps), compareTo(for sorted lists), and what ever you want. For me it is just a normal object (because it is just a normal object) which holds data, methods and is serializable. I think its a good choice to get data from entities to the client. Do you want to send the collection of entities from the finder methods straight to the client?!?
If you can explain a better way, please do it. Maybe I can use it in my actual project.
By the way, I know how object serialization works ;-) and JBoss is creating that "ugly DTOs" automatically.
You are right, WebServices are a little bit odd, but they are the easiest way for interoperability and they are standardized. Good choice to let C++, C# (and many more) Clients interact with service layer.
|
|
|
Message #168249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
A DTO has methods, e.g. equals, hashcode (for hashmaps), compareTo(for sorted lists), and what ever you want. For me it is just a normal object (because it is just a normal object) which holds data, methods and is serializable. I think we disagree on the definition of a DTO/VO. You are refering to a POJO. It looks like we agree on how things are to work.
If an object has anything more than fields and accessors - it is not a DTO. It is a dumb object. For that matter, the object doesn't really need accessors, just public fields. See Sun's Core J2EE Patterns - Transfer Object, about the 1/4 down the page. Notice how they call it a Transfer Object and not a "Data" transfer object. :)
Do you want to send the collection of entities from the finder methods straight to the client?!? By entities, do you mean Entity beans? Then no, I don't. If you mean POJOs (POJOs are not DTOs) then [more than likely] yes, I do.
|
|
|
Message #168349
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
VO/DTO
You are right. I was talking about Transfer Objects.
In the book (above-mentioned) the VOs also should have this
methods so I mixed it up and now I dont know whats wrong about
so called "Value Objects" :-/
|
|
|
Message #205256
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Bad directions
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..
|
|
|
Message #207737
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The J2EE Architect's Handbook
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
