aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Bitter EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Bitter EJB" Watch "Bitter EJB" New topic
Author

Bitter EJB

Mike Southgate
Ranch Hand

Joined: Jul 18, 2003
Posts: 183
I'll be teaching myself EJB shortly. At what point in my learning should I consider getting this book? I understand that the book's not a nuts-and-bolts how-to but rather an implementation guide. I find, however, that very often you can spin your wheels pretty quickly when learning something simply because your trying to do something the hard way.
ms


ms<br />SCJP, SCJD
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
if you can wait,
buy this
Head First EJB
then I guess you can ofcourse pick up Bitter EJB.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

HeadFirstEJB is not yet out.


Groovy
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Pradeep Bhat:
HeadFirstEJB is not yet out.

did'nt u notice that I asked him if he c'd wait
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

I never said that you are wrong! Did I?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Why is book called "bitter ejb"?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Pradeep Bhat:
Why is book called "bitter ejb"?

Bitter EJB is what is known as an Anti-Patterns book. It is basically the complete opposite of a Patterns book (hence the name Anti-Patterns :roll: ) . Where Patterns you how to properly design, Anti-Patterns show how not to design.
Bitter EJB identifies a number Anti-Patterns that are typically found in J2EE Applications that use EJB. The idea is that once you know what the Anti-Patterns are, you can avoid making the same mistakes in your design.
For more details on the book see: Bitter EJB.
[ August 13, 2003: Message edited by: Chris Mathews ]
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
Have you read this book Chris?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Rufus BugleWeed:
Have you read this book Chris?

I have read some of the chapters when they were up for public review at TheServerSide, but I don't actually have a copy yet (it is in my list). From what I have read, it looks to be an excellent book and would definitely by a worthwhile purchase. EJBs have to be one of the most abused technologies around...
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by Mike Southgate:
I'll be teaching myself EJB shortly. At what point in my learning should I consider getting this book? I understand that the book's not a nuts-and-bolts how-to but rather an implementation guide. I find, however, that very often you can spin your wheels pretty quickly when learning something simply because your trying to do something the hard way.
ms

I would get it right away. I thought back over my experiences while learning EJB and I tried to clarify a lot of my personal misunderstandings and to clear away some of the obstacles I ran into along the way.
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by Pradeep Bhat:
Why is book called "bitter ejb"?

It contains EJB AntiPatterns, problems and pitfalls we've run into while using EJB, obstacles that left us with a bitter taste in our mouths.
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
I think the right time to buy this book would be when you have fully understood the EJB concept,worked on it for a few weeks,designed a project and then if you want to know where you went wrong ,this book would make a good reference.Right?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Vedhas Pitkar:
I think the right time to buy this book would be when you have fully understood the EJB concept,worked on it for a few weeks,designed a project and then if you want to know where you went wrong ,this book would make a good reference.Right?

So you recommend that he screw up in a real project before attempting to learn? That sounds like crazy talk to me... :roll:
Personally, I am all for avoiding mistakes.
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
I think you should read a book on EJB and then combine bitter EJB with a design patterns book.


I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
So you recommend that he screw up in a real project before attempting to learn? That sounds like crazy talk to me... :roll:

<drifting towards off-topic>
Sometimes that's the only way people agree that they need to learn something. I have seen the "we're ok (actually we're f*ed but I'm afraid to admit it)" in meetings sooo many times and I have only been in the industry for some 4 years.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Lasse Koskela:
Sometimes that's the only way people agree that they need to learn something. I have seen the "we're ok (actually we're f*ed but I'm afraid to admit it)" in meetings sooo many times and I have only been in the industry for some 4 years.

Well that is an entirely different situation.
As they said: Denile isn't just a river in Egypt.
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445

So you recommend that he screw up in a real project before attempting to learn? That sounds like crazy talk to me...

We dont realize that we have made a mistake unless we make a mistake in the first place.Sounds philosophical,but true.
And after all,you dont expect to get everything perfect in the first go,do you.?
Paul Stevens
Ranch Hand

Joined: May 17, 2001
Posts: 2823
Originally posted by Andres Gonzalez:
I think you should read a book on EJB and then combine bitter EJB with a design patterns book.

I agree. That is the approach to take.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Some mistakes cost a lot. It is better to avoid mistakes.
Originally posted by Vedhas Pitkar:

We dont realize that we have made a mistake unless we make a mistake in the first place.Sounds philosophical,but true.
And after all,you dont expect to get everything perfect in the first go,do you.?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Some mistakes cost a lot. It is better to avoid mistakes.

Some mistakes are worth the pain. Thus, it is even better to embrace mistakes and learn from them.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

You have a pay a heavy price for some mistakes. I am talking about those.
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by Lasse Koskela:

Some mistakes are worth the pain. Thus, it is even better to embrace mistakes and learn from them.

Well, I don't mind learning from others' mistakes (or others learning from mine).
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
I handled a lot of the design-related material in _Bitter EJB_. One of the things that always bugged me about entity beans is the fact that they inhibit true OO domain models (at least I thought they did). Other than that, I think they're a perfectly viable persistence framework. An OO domain model is a must for an application with almost any degree of business logic.
My last project was 80% complete when I joined and they were already using entity beans. It wouldn't have been prudent to start using something else, so I made them work, and I was quite happy with the results.
I started out using the design proposed in the TSS article on the two layer domain model (http://www.theserverside.com/resources/article.jsp?l=TwoLevelDomainModel). They suggest having a pure implementation class with your business logic and abstract getters/setters and then extending that implementation class with your entity bean implementation. This is to enable more testability, better abstraction, etc.
I ran into a couple of problems. One, I still couldn't easily swap out my persistence implementation for something else (i.e. Hibernate, a transient implementation, etc.). The "this" references posed a problem. In the case of a Hibernate implementation, I'd want to use the actual "this" reference. In the case of the entity bean implementation, I'd need to look up the client reference and use that. I could get around this by implementing a getThis() method in each of my business object, but that just seemed kludgy.
Second, I still couldn't have polymorphism. As as I said, this is a must for maintainability. Third, there's the problem with reentrance, but this only becomes an issue if you're running multiple threads within the same transaction (I don't even know if this is possible in a pure J2EE context).
Long story short, I opted for a 3 level domain model where I wrapped the entity beans. I still had the first layer, the implementation class. Next, I had entity wrappers that extended my implementation class and delegated to entity beans. This solved the "this" reference problems and allowed for polymorphism, but how do we handled the wrapping/unwrapping code? We needed to wrap the entity beans on the way out (i.e. from finders in our DAO, and from relationships in our entity wrappers). We needed to unwrap them on the way in (i.e. before we set an entity bean relationship in our entity wrappers).
Unwrapping was easy. Each wrapper simply implemented an Unwrappable interface that returned the wrapped entity bean. Wrapping would be the hard part. Did I need to strewn wrapping with if/else blocks throughout my wrapper code, writing custom Collections wrappers for each multiple relationship? Nope. Using the Visitor pattern, I isolated all of the wrapping code into a simple WrappingVisitor class and I also removed the cyclic dependency between my entity wrapper and entity bean layers at the same time.
Basically, each entity bean was visitable. To wrap it, you simply needed to visit it with the WrappingVisitor. The WrappingVisitor simply implemented a visit method for each entity bean type that would return the wrapped version. All of the polymorphic code went here. For example, a visitor method could return a different subclass based on a field value in the entity bean. As an added bonus, I only needed one Collection wrapper for the entire application. The generic wrapper would simply wrap the collections returned by CMR relationships, wrap entity beans on the way out (from the get() method for example), and unwrap them on the way in.
As an added bonus, I employed code generation in my domain object layer. Using qdox, I wrote a utility that would autogenerate the interfaces and plain bean implementations of each domain type. You determined what methods to include in the public interface using an @interface tag in the implementation class.
I used the bean implementations in a transient DAO implementation that could be swapped out for the entity bean DAO implementation. The transient, or in-memory DAO was useful for preliminary functional testing and deploying the application faster (i.e. you didn't have to worry about cleaning up the database or deploying the entity beans). I actually developed almost the entire application against this in-memory DAO, not having to worry about entity beans once. A coworker rolled the entity bean layer in a day and we had no problems. It was truly awesome.
Now, I had a truly OO domain layer for which the persistence layer was 100% abstracted away. Rolling a Hibernate DAO would have been a snap as I was already autogenerating the plain bean implementation classes. I can also say that this work paid off in maintainability and predictability as I brought the application in on time. What do you think?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Sounds very interesting, Bob. You wouldn't happen to have any sample source to distribute, would you?
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by Lasse Koskela:
Sounds very interesting, Bob. You wouldn't happen to have any sample source to distribute, would you?

I'm getting something together for my NFJS Great Lakes Java Symposium talk next month. Keep an eye on my web site as I'll post the slides, etc. there, http://crazybob.org/.
B Tate
Author
Greenhorn

Joined: Aug 14, 2003
Posts: 12
Antipatterns provide a faster way to learn. Good programmers know what to do; great programmers know this, and also what not to do. The fastest way to learn is to learn the syntax, then study good code (do both of these with a book like Effective Java or The Pragmatic Programmer), then study bad code (Bitter EJB), and only then, study design patterns. You should not study design patterns too soon, without also accumulating the knowledge about the problem domains that those patterns address.
With that in mind, it would be very much a good idea for Bitter EJB to be one of your first EJB books.
I hope this helps.
B Tate
Author
Greenhorn

Joined: Aug 14, 2003
Posts: 12
EJB entities are better than they used to be, but you have to do a whole lot of implementation to abstract away the shortcomings:
- Transparency
- Query Language bind time (can't build dynamic queries at run time)
- model support (poor support for abstract classes, inheritance, etc)
I could go on and on. But if you're not like Bob, where you're roped into that framework, why go through the trouble? There are just better and simpler persistence frameworks out there in JDO (eg. Kodo), OJB, Hibernate, etc.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
There are just better and simpler persistence frameworks out there in JDO (eg. Kodo), OJB, Hibernate, etc.

What, more hogs let loose ? The way I see it the only skill that makes sense anymore is good coding and design skills. The rest seems like a lottery. ( I agree with you there, B Tate BTW , Bitter Java , Effective Java , Code Complete and Pragmatic Programmer are must haves for any serious programming). Should you find yourself in an EJB shop, or JDO shop
just reach out for the relevant Bitter Books and the Patterns book.
But I'd still add EJBs on the list of to-dos. It has had some time to develop and mature.Though I wonder what the early adopters are doing.
regards
[ August 14, 2003: Message edited by: HS Thomas ]
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by HS Thomas:

Though I wonder what the early adopters are doing.
[ August 14, 2003: Message edited by: HS Thomas ]

AOP
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Though I wonder what the early adopters are doing.

More abstraction... That's where the improvements in productivity, quality, etc. come from in general. AOP is an example but not the only "hot topic", I'm sure.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks. Is abstractions another word for refactorings ?
regards
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Is abstractions another word for refactorings ?

No, although many refactorings produce an additional abstraction/indirection. Refactorings are changes to the design that don't affect functionality. In other words, cleaning up code smells.
Fowler's refactoring pages is a good start before you go out and buy the book.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
posted by Crazy Bob:

Originally posted by HS Thomas:
Though I wonder what the early adopters are doing.
[ August 14, 2003: Message edited by: HS Thomas ]
--------------------------------------------------------------------------------
AOP

I guess they'd still want to be ahead of the game.

Entity beans prohibit true OO domain models

Do you mean you can't model concepts like inheritance ?
You seem to have been run through the mill, doing what sounds like the hard way. If you don't mind my asking, what are you working on now ?
EJB 2.0, AOP ?
Also , it seems to me that doing new things like Component Based Development, Test Driven Development might need adjustment of pre-conceived OO design principles. Do you have any advice or links which will not make it as painful as it was for you ? (In addition to what you have included in the Bitter EJB book. Darn missed out on that giveaway ) This question is for the other Authors also.
regards
[ August 16, 2003: Message edited by: HS Thomas ]
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by HS Thomas:

Do you mean you can't model concepts like inheritance ?

Exactly.
Originally posted by HS Thomas:

You seem to have been run through the mill, doing what sounds like the hard way.

How so?
Originally posted by HS Thomas:

If you don't mind my asking, what are you working on now ?
EJB 2.0, AOP ?

Both.
Originally posted by HS Thomas:

Also , it seems to me that doing new things like Component Based Development, Test Driven Development might need adjustment of pre-conceived OO design principles. Do you have any advice or links which will not make it as painful as it was for you ? (In addition to what you have included in the Bitter EJB book. Darn missed out on that giveaway ) This question is for the other Authors also.

Great question. I try to keep a strict divide between my component and OO development; they address two different problems. I use OO concepts for the fine grained stuff, i.e. my domain model, business logic, etc. I use component-oriented concepts for the coarse grained stuff, i.e. services and other heavy reusable items. OO concepts do not apply well to these course grained components because they are typically accessed remotely (I go more into this in the Bitter Interfaces chapter). What I end up with is a pure OO system wrapped in a thin facade to make up a component. I unit test the OO portions and functionally test through the component interface.
I think Fowler's _PoEAA_ combined with _Bitter EJB_ is a great start.
Bob
[ August 17, 2003: Message edited by: Crazy Bob Lee ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
quote:
--------------------------------------------------------------------------------
Originally posted by HS Thomas:
You seem to have been run through the mill, doing what sounds like the hard way.
--------------------------------------------------------------------------------
How so?

What I meant to say is , Thank you for collectively sharing your EJB development experience in Bitter EJB. It's a daunting subject.
Thanks for the other pointers given here also.
Is there a story behind the Crazy Bob handle you'd like to share ?
regards
Crazy Bob Lee
Author
Greenhorn

Joined: Aug 13, 2003
Posts: 8
Originally posted by HS Thomas:

Thanks for the other pointers given here also.

No problem.
Originally posted by HS Thomas:

Is there a story behind the Crazy Bob handle you'd like to share ?

Hmmmmmm... better not. Flag me down if we ever meet in person.
wr nieman
Greenhorn

Joined: May 16, 2003
Posts: 10
Hi,
I just read Bitter EJB..really good book!!! Really usefull and practical.
Higly recomended.
regards
Wouter
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bitter EJB