I can see AOP recommended as a best practice, but I don't see as self-evident why the J2EE specification would mandate its use.
. . .
This is a recommendation for a best practice that also seems to be finding it's way into the J2EE Patterns documented by Alur, Malks, and Crupi.
. . .
Frameworks: I agree with you. Incorporating a Framework like Struts should be a default choice. But again, as a matter of best practice, not as a mandate written into the J2EE spec.
Thanks for the response Michael. I guess my questions come in various flavors and in response to the mountains of information I read daily. I really don't mean to suggest that the items I specified have to be included in the J2EE spec.
Rod's recomendations make sense to me, however (in practice, much of what I have read in tomes like
Bitter EJB and in Rod's book are merely reiterating what I learned from 15 years of mainframe COBOL/CICS coding).
I suppose I'm struggling with the practicum of the assignment. If I am to provide a worthwhile document as an architect, I doubt I'd be letting developers choose the implementation generics (Struts, Jakarta Commons, etc.) for the design - more likely I would assemble a team of senior staffers and toss around the tools available (that I have personally reviewed an approved).
As for AOP, I really see it being necessary to include it in the design - frankly, most folks I know these days are using JDO, Hibernate or some other tool in place of entity EJB's and I usually do too. Many of these use AOP - which is, more or less, an Intercepting Filter and I doubt I'd be as subtle as Crupi, Alur and Marks about the AOP implementation (I know there are folks who shudder when someone mentions AOP = Interception, but there it it). How does it make sense not to mention this in the design?
As for POJO's being called by Session Beans, heck, for years I wrote psuedo-conversational COBOL/CICS programs and regularily made calls to COBOL programs outside the CICS container because I didn't want to have to load all that code in the CICS container. It was a pretty good idea then and it makes sense now in the EJB container.
Anyway, I just don't see how we can complete part II of the assignment in a vacumn absent the realities of the industry.