permaculture playing cards*
The moose likes EJB and other Java EE Technologies and the fly likes Moving bean logic to regular java classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Moving bean logic to regular java classes" Watch "Moving bean logic to regular java classes" New topic
Author

Moving bean logic to regular java classes

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20488
    ∞

In the environment I'm working in, we have a pile of session beans and a pile of entity beans. Many of the session bean methods will call methods in other session beans which call other methods in other session beans, etc. So there's a lot of JNDI stuff and home and remote interfaces being tossed around.
I've been making some session beans extend a common class that contains some common methods. This is starting to simplify a lot of code, but the common class is starting to get kinda big.
Have an idea, but it sounds kinda radical.
Suppose I have a session bean called EmployeeBean that has, say, a dozen public methods
and a dozen private methods. It calls other beans and uses other common code. And I
have 80 other session beans that are about the same size, but, naturally, do different
stuff.
What if I made a new class called EmployeeInnards that did all the work and EmployeeBean
just was a shell that would use the EmployeeInnards class? Then, if, say, BossBean
needed to use EmployeeBean, then rather than talking to JNDI, it could just talk directly
to EmployeeInnards.
Good idea? Bad idea?


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Um, well, I'm relatively new to EJBs, but I think the problem is you've got two piles of beans. If you mix then together and add a little salsa, and stew over low heat for 3 hours, you'll find it's quite tasty.
More seriously, I think it depends on how you do this. If you have each WrapperBean have it's own unique instance of the EmployeeInnards,* then it's fine.
However, if you have a bunch of instances of EmployeeInnards floating around, and EmployeeBeans picked them up and use them, well, then what's the point of using EJBs?
I have a feeling I misunderstanding your question.
--Mark

*You may find HR will want to do a pysch analysis of you if they see you using a class with this name.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20488
    ∞

I've now talked to somebody that has used this architectur before and supports it whole heartedly.
The advantage is that your code looks much cleaner cuz you don't have to do the home and remote dance (with all the try/catch/finally stuff involved with that).
And about the name: suggestions?
Innards, Meat, BackEnd, WorkHorse, Guts ... ???
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
I concur with Mark's opinion. Although it is a good design to encapsulate some business logic in "innards" and use SBs as service access points, if innards talk to other innards directly, you will have to question why use EJBs in the first place?
By making innard to innard direct calls, you are bypassing some container goodies such as passing on login credentials, maintaining transaction contexts etc. See this post for a related discussion.
If JNDI lookups and home/remote dancing is making you mad and your code look cluttered, use a ServiceLocator implementation.
A last comment about SB design - It is good to have a fewer session beans each with a large number of methods than a large number of SBs each with fewer methods.
Hope that helps!


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
Originally posted by Paul Wheaton:

And about the name: suggestions?
Innards, Meat, BackEnd, WorkHorse, Guts ... ???


hmmmmm. . . Beans and BackEnds seem to go naturally together .


"JavaRanch, where the deer and the Certified play" - David O'Meara
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20488
    ∞

<i>if innards talk to other innards directly, you will have to question why use EJBs in the first place?</i>
Because my boss says so.
The stateless session beans provide a common layer of logic to several applications.
<i>By making innard to innard direct calls, you are bypassing some container goodies such as passing on login credentials, maintaining transaction contexts etc.</i>
I thought of that (at least I hope I figured it out enough). The thing that is important is bean managed transactions. So it would seem that an Innards class should never attempt to get a connection. Each method that requires a JDBC connection should instead have it passed in as a parameter. So the connection will be grabbed while in the session bean and passed to the innards class method. I'm thinking that this will preserve any container managed transactions.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Horsehockey guys. Paul's idea is the way you SHOULD be using EJB's in the first place! What you've discovered, Paul, is the Session Facade pattern.
You need to read this article that goes into enormous depth on why this is the right way to use Session EJB's. Then sit down and read the section on the same thin in Martin Fowler's wonderful "Patterns of Enterprise Application Architectures", where he says basically the same thing.
You get ALL the benefits from Session beans that you can possibly get (transactions, security, and distribution) by just putting a thin veneer of them over a much larger framework of Plain Old Java Classes (Martin Fowler's term, not mine). This is basically accepted wisdom now.
You've got the right instincts, Paul -- just go with them.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Paul Wheaton:

I thought of that (at least I hope I figured it out enough). The thing that is important is bean managed transactions. So it would seem that an Innards class should never attempt to get a connection. Each method that requires a JDBC connection should instead have it passed in as a parameter. So the connection will be grabbed while in the session bean and passed to the innards class method. I'm thinking that this will preserve any container managed transactions.

Nope, "Innards" classes can get connections themselves. The transaction context is on the THREAD, not the object itself. As long as the call tree began with the EJB, you're hunky-dory. See this article where I show this.
Kyle
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

I second Kyle's points, as if that's necessary.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20488
    ∞

There's still the discussion about what we call this "innards" class.
Marcos Maia
Ranch Hand

Joined: Jan 06, 2001
Posts: 977
Hi,
I�ve worked on a project where we use most ejbs using the session facade pattern and this facade controled the scope of transactions and communication with other sessios, entity and the access to other services.
We also used a home cache pattern to make access to other services faster.
What I was thinking is that using ejb�s I get a much easyer way to manage instances and reuse them and with a fine tunning on the server and components I believe we could gain more performance and easly managment of instances and tunning(ejb dd�s provide this for components).
Well I�ve read this discussion and would like to share some thoughts:
1-To access the plain java classes from a session facade that tipically is a stateless one I would have to often construct new objects from the plain java classes that have my business logic and this could became a chain of objects being created if we don�t take care of it, well in my opinion this will degrade performance, pls post comments on this.
2-I believe we could build some cache mecanism to avoid the creation of classes, but as long as I�m concerned this would be harder and more dificult to manage and build.
3-With ejb 1.1 I believe the best approach was to build using a facade, plain java classes and DAO�s.

Well the fact is that I�m not sure if we should keep using the approach u mention that as I understand was the best for the ejb1.1 model or use the model I mentioned first.
I would really appreciate comments on this.

Would be nice if we could build or find some ready application that was written using both approaches to do exactly the same thing and then we could test it using the same hardware/software to watch the behavior and do some experiments, if anyone knows something like this or would like to try to build it pls contact me I would be a volunteer to do it.
Marcos Maia.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Marcos Maia:
Hi,
I�ve worked on a project where we use most ejbs using the session facade pattern and this facade controled the scope of transactions and communication with other sessios, entity and the access to other services.
We also used a home cache pattern to make access to other services faster.
What I was thinking is that using ejb�s I get a much easyer way to manage instances and reuse them and with a fine tunning on the server and components I believe we could gain more performance and easly managment of instances and tunning(ejb dd�s provide this for components).
Well I�ve read this discussion and would like to share some thoughts:
1-To access the plain java classes from a session facade that tipically is a stateless one I would have to often construct new objects from the plain java classes that have my business logic and this could became a chain of objects being created if we don�t take care of it, well in my opinion this will degrade performance, pls post comments on this.
2-I believe we could build some cache mecanism to avoid the creation of classes, but as long as I�m concerned this would be harder and more dificult to manage and build.
3-With ejb 1.1 I believe the best approach was to build using a facade, plain java classes and DAO�s.

Well the fact is that I�m not sure if we should keep using the approach u mention that as I understand was the best for the ejb1.1 model or use the model I mentioned first.
I would really appreciate comments on this.

Would be nice if we could build or find some ready application that was written using both approaches to do exactly the same thing and then we could test it using the same hardware/software to watch the behavior and do some experiments, if anyone knows something like this or would like to try to build it pls contact me I would be a volunteer to do it.
Marcos Maia.

Instance caching is a total red herring. Java is DESIGNED to create instances and efficiently destroy and garbage collect them. We've spent nearly 8 years learning how to build highly efficient JVM's (based on the previous 20 years of Smalltalk and Lisp VM and garbage collection technology). You almost NEVER end up with a performance problem whose solution is "create fewer instances of my business objects".
I've never claimed that this is a big benefit of EJBs. Instance caching is an optimization step, and you should ONLY do optimization when you absolutely need it. In the words of Don Knuth "Premature Optimization is the root of all evil." That's true in EJB as in all other branches of programming.
Kyle
Marcos Maia
Ranch Hand

Joined: Jan 06, 2001
Posts: 977
Tx Kile, I would also apreciate if u could do some coments on the best model u believe fits for the ejb1.1 and 2.0 specs.
Marcos Maia
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Marcos Maia:
Tx Kile, I would also apreciate if u could do some coments on the best model u believe fits for the ejb1.1 and 2.0 specs.
Marcos Maia

I'm not sure what you mean. I don't have anything to add beyond the articles I've already written on the subject, which apply equally well to either EJB 1.1 or 2.0.
Kyle
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
Originally posted by Kyle Brown:

Nope, "Innards" classes can get connections themselves. The transaction context is on the THREAD, not the object itself. As long as the call tree began with the EJB, you're hunky-dory. See this article where I show this.
Kyle

Kyle, I have a question related to the article referenced above.
I understand why( and how ) access to entity beans( you call them "datasources" ) should be layered through the use of session beans and factories. I also appreciate the concept of mappers that help alleviate the OR-mapping problems.
But why cannot ProjectMapper directly talk to ProjectFactory instead of going through TimesheetProcessor session bean? After all, the TimesheetProcessor bean is simply "passing the buck" as you reckon in the article.
I am unable to appreciate the additional layer of abstraction when we already have the Factory layer. Can you throw in some words of wisdom?
Cheers,
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
ProjectMapper is acting (more or less) as a BusinessDelegate. It's optional. The session bean is most certainly NOT optional if you want EJB transactions or distribution. That's the heart of the SessionFacade pattern. I believe in that article I talk about how blasted inefficient it is to allow direct access to Entity beans from a client -- thus the requirement for the Session bean.
Kyle
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Moving bean logic to regular java classes
 
Similar Threads
SessionBean to SessionBean call
few questions on entity beans
Retrieve reference to (all the) session beans at runtime with EJB3 and JBoss?
unit testing without brittle code
SessionBean to SessionBean call