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
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?