'. '

VerificationViaAOP

From APIDesign

Revision as of 09:43, 22 March 2009 by JaroslavTulach (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other modules depend on such API modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.

Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to synchronization and deadlocks to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work on everyone running on background. When you are supervising such modular system this is the first thing that you want to prevent.

There are various extensions to NetBeans Virtual File System library.
One of them is support for CVS, Subversion or Mercurial. Their job
is slightly harder then traditional task of regular file system. Some times
they need to make decisions and they needed to ask user questions. Indeed this
was very deadlock prone and needed to prevented and fixed.

Simplest fix, especially if you own both APIs is to set some ThreadLocal variable whenever a method from storage API is on the stack and whenever one tries to show a wizard or dialog verify that this ThreadLocal is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.

As such I was very pleased to see Srini Penchikala's presentation describing use of AOP for the same task. Instead polluting the both API with ThreadLocal tricks and making them semi-aware of each other (wizard often do not need storage), one can define one or two aspects externally and achieve the same.

For preventing these kinds of unwanted compile or runtime dependencies the AOP seems to be perfect. Get more inspication by Srini.

<comments/>

Personal tools
buy