Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Bitter EJB

 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if you can wait,
buy this
Head First EJB
then I guess you can ofcourse pick up Bitter EJB.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HeadFirstEJB is not yet out.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I never said that you are wrong! Did I?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why is book called "bitter ejb"?
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you read this book Chris?
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 445
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you should read a book on EJB and then combine bitter EJB with a design patterns book.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 445
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 2823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have a pay a heavy price for some mistakes. I am talking about those.
 
Crazy Bob Lee
Author
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds very interesting, Bob. You wouldn't happen to have any sample source to distribute, would you?
 
Crazy Bob Lee
Author
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. Is abstractions another word for refactorings ?
regards
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I just read Bitter EJB..really good book!!! Really usefull and practical.
Higly recomended.
regards
Wouter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic