Is AOP J2EE? Given that most of the industry is galloping toward it's implementation, why does/doesn't it make sense to include it in the architecture?
Rod Johnson in a new article on The ServerSide contends best practices now dictate POJO's contain business logic and session beans should call the POJO's. Is this J2EE?
What about Frameworks? As an architect, I wouldn't begin to suggest an architecture that doesn't include some frameworks like Struts etc. Given that most frameworks are already implementing patterns, I wouldn't waste my time showing a framework architecture. Thoughts, anyone?
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. AOP contributes no functional role to a J2EE architecture, so while recommending it makes sense, specs don't typically make non-functional recommendations. Rod Johnson's article points to a fashionable trend from recent case studies. Abstracting the container-driven mechanics of a session bean from the actual logic it will call seems to be more flexible and open to change than a more direct approach. I can also see how applying Johnson's recommendations quickly creates a rat's nest of objects, none of which actually do anything but delegate to other objects. 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. I saw hints of this in their stuff on the Domain Store pattern (really just a generic approach to JDO) in their recent edition. 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. [ October 14, 2003: Message edited by: Michael Ernest ]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
Joined: Nov 09, 2001
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.
A lot of so-called best practices, I think, should look like little more than formalized "common sense" to a person with your experience. Really, that's all they are: lessons many of us learned through repetition, followed by a glimmer of insight, followed by a head-thwacking "oh. of course." As I read it, the SCEA exam doesn't test the full ability of a person's skills as an architect. The aim is just competency. For me, the aim seems a little low, and for you I suspect it's the same. But it's reasonable, in the face of testing for competency, to consider solutions that don't make use of all the best strategies, so long as the design is valid and can be reasonably defended by its creator. By the way, I'm telling Alur and Malks what you said about AOP and Interception. I'd hide if I were you.
[ October 14, 2003: Message edited by: Michael Ernest ]