[aosd-discuss] Aspects in Early Stages

[Andrei Popovici]

Hi Dean, Hi Arno

I think I gave you the impression of praising J2EE and the EJB model,
(.. and that everything else is useless).
On the contrary, I fully agree with you on its limitations. EJB/J2EE
does separation of concerns, but THEIR concerns: as Arno says
in his last E-mail, you have to decide early in the design
whether to use entity beans or session beans, use JDO or not, etc.

My initial e-mail was about *identifying* aspects. IMHO
in the EJB model, the most important kinds of aspects and their 
interactions  (e.g., transactions) are already identified.

The problems you describe are a consequence of  EJB
containers not exposing their weaving/AOP API. This
leads to phenomena like 'I have to decide early between IIOP and RMI'.
However, this has started to change: see JBoss; Another effort
I am aware of is AspectEJB, developed by a company in Zuerich (Navit).



> However, even in this case, I'm not sure I would "skip" AO analysis an
> design (once it's a mature discipline...). 
[..]


Neither would I. I think it is important, and as ARNO points out,
these aspects that have (yet) to be identified are related to the
business types & requirements.

.. and of course, for non-typical enterprise applications, AO analysis
will certainly help.

> Now, I realize this is somewhat "blue sky" thinking at this stage. It is the
> vision of MDA, although it is not at all clear that this vision can be
> realized. However, by starting with these premises, we can hopefully make
> them viable, while at the same time making the usual practical compromises
> to get our real work done ;^) 
> 

Regards,

Andrei

> 
> It's interesting to consider how this would work. The most common, non-AOP
> approach is to create Frameworks for each industry. Experience has shown us
> that it's very hard to create flexible and reusable frameworks that still
> provide acceptable performance, ease of use, etc. Furthermore, services like
> security, transaction, etc. are usually implemented as libraries, the use of
> which results in the "code tangling" that AOP seeks to solve.
> 
> If we can figure out how to replace the framework approach with an AOP
> approach, where the capabilities provided by the framework are woven
> together with our business logic, that will be an important advance!
> 
>
-- 
------------------------------------------------------------------------
Andrei Popovici
Institut fuer Informationssysteme
ETH Zurich
ETH Zentrum, 8092 Zurich
Tel: +41 1 632 7609
Fax: +41 1 632 1172