[aosd-discuss] Hyper/J vs Apect-J

Wed Sep 18 03:11:18 EDT 2002

RE: [aosd-discuss] Hyper/J vs Apect-JArno,

Sorry I missed this message.
  Hello awais,
  good point, but this scenario would fit in one of the two cases:

  1. accicdential advice, where a strict order and a "need to know about"
relation is not existent, (no intended influencing side effects) (for this
case dominates and subordinates would be IMHO sufficent)

  I don't think dominates and subordinates will be sufficient. Dominates and
subordinates in fact work well when there are a small number of aspects and
the interaction relationship is known. For unplanned interactions we need a
more well-defined mechanism. Perhaps we could learn from the feature
interaction community.

  2. the advice could be rewritten to advice not the original advice,
   but the advice for the advice, and so on.

  So would you think that 2 is not practical, or that we need some new more
efficent
  construct?

  I think 2 is doable. However, this could get extremely complex and I feel
this is a mechanism to circumvent the interaction problem not provide a
solution to it. Also, I see this getting very complex in a larger system and
even more complex if the system has gone through a few evolution cycles.

  Kind regards,

  Awais.

  regards
     Arno

  -----Original Message-----
  From: Awais Rashid
  To: Arno.Schmidmeier at sirius-eos.com; elrad at iit.edu
  Cc: memmert at jpmdesign.de; discuss at aosd.net
  Sent: 9/12/02 5:10 PM
  Subject: RE: [aosd-discuss] Hyper/J vs Apect-J

  -----Original Message-----
  From: discuss-admin at aosd.net [mailto:discuss-admin at aosd.net]On Behalf Of
  Arno.Schmidmeier at sirius-eos.com
  Sent: 11 September 2002 09:44
  To: marash at comp.lancs.ac.uk; elrad at iit.edu
  Cc: memmert at jpmdesign.de; discuss at aosd.net
  Subject: RE: [aosd-discuss] Hyper/J vs Apect-J

   Hello Tzilla,
  hello Awais,
  hello everybody else,

  Based on my experinece with aspectJ in comercial projects,
  ordering the aspects is a real problem. This lead to my submission of
  the
  "construct of the opposite of dominates". (Let's call it subordinates
  for now)
  Dominates and subordinates are IMHO more than sufficent, for simple
  ordering
  of the execution of advices form nearly independent aspect.
  in other words for aspects who "accidential" advice the same pointcut.

  e.g. I have aspects for logging, caching, and billing:
  billing and logging can be executed in any order, however caching
  must be always executed after logging and billing or otherwise round.
  These simple orders can be expressed quite simply.

  However I find many places, where I want to wrap an around advice
  around an around advice. Because aspectJ does not support (hopefully
  jet)
  a pointcut for advices, I have to hack this functionality with
  dominates/subordinates.
  These are the places in the code, where I got plenty of tangling
  pointcuts,
  tangling dominates-statement etc.

  With such a construct the composition from A, around B, on some places
  in C
  could be done easier, and much more easier to maintain.
  Currently A and B depend from the same pointcut definition (pcd) of C.
  With such a mechanism A would then only depend from B where B would only
  depend
  from the pcd of C.

  Much easier to maintain, expecially if asbstract aspects are involved.

  Awais, would such a mechanism also solve your interaction scenarious?

  Not necessarily. I think this would solve the problem of having aspects
  of aspects. Interactions could still exist with multiple aspects
  defining poitcuts based on the same advice!

  Awais.

   Arno

  -----Original Message-----
  From: M. Awais Rashid
  To: Tzilla Elrad
  Cc: memmert at jpmdesign.de; discuss at aosd.net
  Sent: 9/11/02 10:02 AM
  Subject: Re: [aosd-discuss] Hyper/J vs Apect-J

  Tzilla,

  > >Also, I do not agree that in the AspectJ model aspects are not
  supposed
  > >to
  > >talk to each other. In most applications (in my experience) they have

  to,
  > >directly or
  > >indirectly (by influencing the same joinpoint). However, the latter
  leaves
  > >much to be desired of the interaction resolution model in
  > >AspectJ. Dominates and simple advice ordering does not really cut it
  when
  > >you have a few largish aspects in your application.
  > >
  > >Awais.
  >
  > I would like to refer to one point only, so for the sake of simplcity
  I
  > deleted the rest of the corospondences.
  >
  > MIR:  Multi-Interacion-Resolution
  >
  > The issue is when, how, by whom and on what visability rules
  interaction
  > resolutions could be made. It is true that in AspectJ we have the
  "base"
  > and "aspects" that are reated differently where as in Hyper/J any two
  pieces
  > os software can be combind with each other.
  > Both hyper/j (?) and AspectJ are limited to interaction of TWO pieces
  of
  > software at a time. This makes interaction resolution based on a group

  of
  > software pieces complicated.  many times there is no simple
  serialization
  >  sequence of pairs-interactions that can simulate this
  > Multi-Interacion-Resolution
  >
  > How would you simulate a general MIR- Multi-Interacion-Resolution in
  AspectJ?
  > Hyper/j?

  I don't think there is any easy way to do this in AspectJ. AspectJ
  allows
  one to express logical combinations of aspects in the dominates clause:

  Aspect A dominates (B || C)
  Aspect D dominates (E && F)

  etc.

  However, the above example further demonstrates how complex interaction
  resolution can become in an application with just a few aspects let
  alone
  with tens or hundred of them. One of the main problems with the above
  model is that it specifies the interaction with reference to a
  "base" aspect. As a result if aspects B and C change and now B dominates

  A
  and C you need to change the two aspect definitions. Of course, one
  could
  argue that it is just the dominates clause that needs change. However,
  it
  is quite easy for a programmer to forget this which can lead to
  undesirable behaviour in the program.

  Personally, I feel that interactions cut across an AO system and should
  be
  specified as an "aspect" themselves. However, I don't mean to say "as an

  aspect in AspectJ as it stands today". We need a clearer interaction
  resolution model not just for AspectJ but for AOP techniques in
  general.

  Kind regards,

  Awais.

  >
  > -Tzilla
  >
  >
  >
  >
  >
  > Dr. Tzilla Elrad
  > Research Professor
  > Department of Computer Science
  > Illinois Institute of Technology
  > (312) 567-5142
  > http://www.iit.edu/~elrad <http://www.iit.edu/~elrad>
  >
  >
  > _________________________________________________
  > AOSD discuss mailing list    -   discuss at aosd.net
  > To be removed send mail to discuss-admin at aosd.net
  > or visit http://aosd.net <http://aosd.net>
  >

  _________________________________________________
  AOSD discuss mailing list    -   discuss at aosd.net
  To be removed send mail to discuss-admin at aosd.net
  or visit http://aosd.net <http://aosd.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://server2.hostvalu.com/pipermail/discuss_aosd.net/attachments/20020918/38775e8a/attachment.htm