File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Moving bean logic to regular java classes

 
paul wheaton
Trailboss
Pie
Posts: 21187
Firefox Browser IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Mark Herschberg
Sheriff
Posts: 6037
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 21187
Firefox Browser IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5782
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Wheaton:

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


hmmmmm. . . Beans and BackEnds seem to go naturally together .
 
paul wheaton
Trailboss
Pie
Posts: 21187
Firefox Browser IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
<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
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7292
Netbeans IDE VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I second Kyle's points, as if that's necessary.
 
paul wheaton
Trailboss
Pie
Posts: 21187
Firefox Browser IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's still the discussion about what we call this "innards" class.
 
Marcos Maia
Ranch Hand
Posts: 977
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 977
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5782
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic