File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes What's the right J2EE pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "What Watch "What New topic

What's the right J2EE pattern

Mark Herschberg

Joined: Dec 04, 2000
Posts: 6037
This follows the question I asked here.
Kyle pointed out that when I want to do a tranfer between two account objects (e.g. one gives moeny and gets stick, the other gives stock and gets money), I should have those accounts represented as entity beans and use a stateless session bean to take both of them and do the tranfer. Now this is client initiated, meaning client A says he wants to execute a trade between his account and account B (which had a standing order to allow this trade, hence client B is not notified of the trade until it has completed).
Client A can't directly access the entitiy bean which is client B's account. Instead, we were going to have each account have a unique ID and when client A requests the trade, it gives the unique ID of client B's account. (BTW, security isn't a major concern here.) So basically, the session bean will do a lookup to get a reference to client B's entity bean representing his account. But this kinda defeats some OO principles, since effectively we make these objects global, accessible to anyone who wants to ask for them. I've used this pattern in other places on occasion, but not with EJBs. We'll be doing this with accounts and a few other objects shared by each user. Is this an appropriate pattern to use? Is there a better one?
Thanks for any help.

Kyle Brown
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
I would probably create a "Transfer" object that you give both the key for "Buyer" and the key for "Seller" and that looks them both up and does the transfer. That way neither the buyer nor the seller know the details of the other -- they are both hidden in the Transfer.

Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at for other WebSphere information.
Mark Herschberg

Joined: Dec 04, 2000
Posts: 6037
OK, that sounds like what I was proposing. I'm not too worried about the buyer or seller finding the other's info (this is just a simulation, if some MBA student really wants to hack it, well, they can). Rather, I was just concerned about breaking OO principles by having a lookup to grab an object--this object may be used by other people, at other times.
By having this class that can return an account object to anyone who requests it, concepts such as abstraction layers and low coupling can be ruined. Lazy programers (not me, of course, I'm never lazy :-p ), don't have to owrry about passing objects around to get them to the classes who need them, then can just request them directly. You effectively turn these classes into "global variables."
I have used this techinque in J2SE projects. Sometimes it does make sense to have such a public repository. While there are no programmatic constraints on data access (everything is public), the system architect tells everyone to follow a certain design principle that these clasees may onyl be accessed under certain circumstances in certain ways, and he carries a big rubber hose to enforce those principles :-)
In J2EE, is it ok to do the same thing, or is there a better way to create such a repository? (Again, security isn't a major concern, but good OO design is.)
I agree. Here's the link:
subject: What's the right J2EE pattern
jQuery in Action, 3rd edition