This week's giveaway is in the Spring forum.
We're giving away four copies of Microservices Testing (Live Project) and have Chris Love & Andres Sacco on-line!
See this thread for details.
Win a copy of Microservices Testing (Live Project) this week in the Spring forum!


+ Follow
since Sep 27, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by bob-davis

First of all, I am not going to use J2EE security in the assignment. Why? Do to the fact of the users being able to add themselves at runtime (create profile). IMHO this is where the J2EE security falls short. One has to write a custom RealmAccessor to handle managing users at runtime.
So I decided I would take the route of the Petstore and have a very thin entity bean (username/password) that represents a "logon" in the system. So now I have the question as to where do I guard my resources. In the web tier or in the ejb tier?
Just wanted to get some other opinions on my approach.
Also is anyone using an EJBController pattern similar to the Petstore? I am going with a simple BusinessDelegate-SessionFacade where the SessionFacade is a SFSB that holds the currently logged in user among other things.
Hello all,
I am currently about to start on PartII. I keep banging my head around the simple question - "What good is a controller in the EJB tier?"
For the general architecture I am trying to decide whether to go w/ a framework such as the petstore. (Client tier creates events and ships them to an EJBController SFSB in the ejb tier. Business logic is executed and results are returned). Or with something using struts that uses a Business Delegate that holds N session facades. The session facades then execute the business logic on the server.
So basically EJBController (EJBCommand) vs. BusinessDelegate/SessionFacades.
Pros of EJBCommand:
* client is not affected at all by changes in business tier. If a session facades method signature changes, the client doesn't have to be updated as it only uses the "EJBCommand" or controller interface/stub.
* seperation of labor. Web developers need not know anything about the business tier.
Cons of EJBCommand:
* clumsy exception handling - have to pick apart the generic exceptions and make an application exception out of them
* bit heavyweight when you consider the petstore impl using SFSB - one for each user whose life is the complete user session
* TX settings have to be set to one and only one settting on the EJBCommand SFSB. (WORKAROUND - have N EJBCommand beans - one for each TX setting)
Pros of BizDel/SF
* isolation from the underlying impl
* tight exception handling
* maintainability
Cons of BizDel/SF
* client affected by changes in SF signatures - a bit tighter coupled
I am used to developing software that has only a web tier client. So I keep going back to the question of how other clients come into the equation. For a Swing client, the BizDel/SF could be used identically to the web tier. So if later FBN decided they wanted a different client type, how would one vs. the other architecture affect it?
In a nutshell, "What are the benefits of a controller in the EJB tier" and for those of you SCEAs out there, what path did you choose?