My current application uses the following architecture. JSPs use our own taglib which calls EJBs backing onto a DBMS. In the case of UI presentation pages which produce views the tag handlers build XML from querying the Entity Beans and run it through an XSTL stylesheet. For 'write' type operations from forms or whatever the tag handler use a SessionFacade (SessionBean) to provide TX integrity.
I have a nagging doubt that I shouldn't be putting EJB client code in the tag handlers for the UI presentation pages. For some of the larger tag handlers I have refactored them into Session Facades to speed up performance. This also feels a little odd as I am now putting presentation tier logic into the business tier. Performance isn't a problem right now as I'm using JBoss and Tomcat in the same JVM.
Comments/suggestions greatfully received.
I agree that putting EJB logic into tag handlers is a bad approach. Jumping straight from tags to Session EJB may not be the best solution, though.
I suggest you create set of POJO (Plain Old Java Object) between you tags and your EJBs, following the Business Delegate pattern.
Tag -> Business Delegate (POJO) -> EJB
These POJOs should be relatively easy to write, since you can basically cut and paste code out of your tags.
Later you can do something more sophisticated, as you need it:
Tag -> Business Delegate (POJO) -> Session Facade -> EJB
Since all your future changes will be hidden under your POJOs, you won't need to rewrite your tag libraries.
Thanks Paul. I was sort of thinking the same thing myself. wrt POJOs/Business Delegators. Your point on the POJOs hiding the possible shift to SSBs is well taken.