Shahzad Bhatti

March 23, 2005

AOSD 2005

Filed under: Computing — admin @ 8:35 am

AOSD 2005

AOP with Metadata: principles and practices (Ramnivas Laddad)

Guideline: don’t use annotations when you can do without them. Eg. you want to capture all RMI operations. You can write a simple, stable pointcut: execution(* Remote+.*(..) throws RemoteException) – no need for an annotation here. Likewise you can write a stable pointcut for all thread-safe calls to the Swing library – you don’t need annotations for this either.

Not sure if Ramnivas is going to mention this, but there are also expressibility limitations with annotations – you can’t say for example “all calls to x within y” since you can’t annotate calls (you can say “all calls to a method with an annotation X made within y” – but that’s a slightly different thing). There are other examples too…

A second guideline from Ramnivas: employ aspect inheritance to defer pointcut specification to a sub-aspect. Now write one pointcut per “subsystem” this will be much easier than trying to write a single global pointcut that works across the whole system.

A third guideline – make use of existing annotation types – eg. EJB

A fourth guideline – if you create annotation types, use names that describe a property of the annotated element, not an instruction to some processor. Eg. @ReadOnly, not @ReadLock, use @Idempotent, not @RetryOnFailure, and so on.

A final guideline – wisdom comes with experience: start with something and refactor as you go along.

Ramnivas is now discussing whether metadata-fortified AOP harms “obliviousness”. His argument is that it does not if the guidelines are followed.

The final flourish in Ramnivas’ talk. You could have an aspect that matches on annotated methods… if you don’t want to annotate them individually, you can use an inner aspect (participant pattern) to declare them…

March 21, 2005

Bohrbug Vs Heisenbug

Filed under: Computing — admin @ 11:33 am

Bohrbug Vs Heisenbug
Bohrbug (Niel Bohr) – retrying will result in the same error.

Heisenbug (Werner Karl Heisenberg) – retrying may or may not result in the same error

  1. Omission Failure: abscence of response
  2. Timing Failure: system does not provide result within the specified timeframe (early timing failure/late timing failure)
  3. Response Failure – system provides incorrect value
  4. Crash Failure – no further responses until reboot

Principles of design

  1. Modularity
  2. Fail fast / heartbeat
  3. Independent failure modes
  4. Redundancy/repair – hot swapping
  5. Elimination of single point of failure – redundancy

Pair/Spare approach — provide two instances of critical resources and ability to swap one out.

Powered by WordPress