7.1 Overview of P2P-PL
7.1.1 Aspectual Feature Modules in P2P-PL
14 of the 113 end-user visible features of P2P-PL (12%) use aspects (see Tab. 7.1);
the remaining 99 features were implemented as traditional feature modules – without aspects. To give the reader an impression of how aspects and mixins have been combined in P2P-PL, we explain two simplified examples of AFMs.
aspect description
responding sends message replies automatically forwarding forwards messages to adjacent peers message handler base aspect for message handling pooling stores and reuses open connections serialization prepares objects for serialization illegal parameters discovers illegal system states
toString introducestoStringmethods to several classes log/debug a mix of logging and debugging
dissemination piggyback meta-data propagation feedback generates feedback by observing peers query listener waits for query response messages command line provides command line access caching caches peer contact data
statistics collects and calculates runtime statistics
Table 7.1: Aspectual Mixin Layers used in P2P-PL.
Feedback Generator
feedback counters free riders
The feedback generator feature is part of an incentive mechanism for penalizing free riders – peers that profit by the P2P network but do not contribute adequately [BB06].
A feedback generator feature, on top of a peer implementation, identifies free riders by keeping track of whether other peers respond adequately to messages. If this is not the case, an observed peer is considered a free rider. Specifically, the generator observes the traffic of outgoing and incoming messages and traces which peers have responded in time to posted messages. The generator creates positive feedback to reward cooperative peers and negative feedback to penalize free riders. Feedback information is represented by objects of class Feedback and stored in a repository (FeedbackRepository); it is passed to other (trusted) peers attached to outgoing messages in order to inform them about free riding. Based on the collected information, a peer judges the cooperativeness
of other peers. Messages from peers considered free riders are ignored – only cooperative peers profit by the overall P2P network [BB06].
feedback generation is crosscutting
The implementation of the feedback generator crosscuts the message sending and receiv-ing features. As Figure 7.2 shows, the feedback generator AFM contains an aspect (dark gray) and introduces four new classes for feedback management. Additionally, it refines the peer abstraction (by mixin composition) so that each peer owns a log for outgoing queries and a repository for feedback information.
MessageSender
Feedback Generator
Feedback Feedback
Repository QueryLog
Feedback QueryListener
Peer Peer
Handler Feedback
Generator
Figure 7.2: Feedback generator AFM.
While the feedback generator feature implements a heterogeneous crosscut, it relies on dynamic context information, i.e., it is an advanced dynamic crosscut. Figure 7.3 lists an excerpt of the aspectFeedbackGenerator. The first advice refines the message sending mechanism by registering outgoing messages in a query log (Lines 2-7). It is executed only if the methodsendwas called in the dynamic control flow of the method forward.
This is expressed using thecflowpointcut (Line 5) and avoids advising unintended calls to send, which are not triggered by the message forwarding mechanism1. The second advice intercepts the execution of a query listener task for creating feedback (Lines 8-10).
Figure 7.4 lists the refinement of the class Peer implemented as a mixin2. It adds a feedback repository (Line 2) and a query log (Line 3). Moreover, it refines the constructor by registering a feedback handler in the peer’s message handling mechanism (Lines 4-7).
AFM encapsulates multiple artifacts
In summary, the feedback generator AFM encapsulates four classes that implement the basic feedback management, an aspect that intercepts the message transfer, and a mixin that refines the peer abstraction. Omitting AOP mechanisms would result in code tangling and scattering since the retrieval of dynamic context information crosscuts
1 The background of usingcflowit that the methodsendis called many times inside a peer, but we wanted to advise only those executions of send that occur when forwarding a message to another peer.
2 The actual syntax for constructor refinement in Jak differs slightly [BSR04].
7.1 Overview of P2P-PL
1 aspect F e e d b a c k G e n e r a t o r { ...
2 a f t e r( M e s s a g e S e n d e r sender , Message msg , PeerId id ) : 3 target( sender ) && args( msg , id ) &&
4 c a l l(boolean M e s s a g e S e n d e r . send ( Message , PeerId )) &&
5 cflow(execution(boolean F o r w a r d i n g . forward (..))) &&
6 i f( msg i n s t a n c e o f Q u e r y R e q u e s t M e s s a g e )
7 { /∗ . . . ∗/ }
8 a f t e r( Q u e r y L i s t e n e r l i s t e n e r ) : target( l i s t e n e r ) &&
9 execution(void Q u e r y L i s t e n e r . run ())
10 { /∗ . . . ∗/ }
11 }
Figure 7.3: Feedback generator aspect (excerpt).
1 r e f i n e s c l a s s Peer {
2 F e e d b a c k R e p o s i t o r y fr = new F e e d b a c k R e p o s i t o r y ();
3 Q u e r y L o g ql = new Q u e r y L o g ();
4 Peer () {
5 Super();
6 F e e d b a c k H a n d l e r fh = new F e e d b a c k H a n d l e r (t h i s);
7 t h i s. g e t M e s s a g e H a n d l e r (). s u b s c r i b e ( fh );
8 }
9 }
Figure 7.4: Feedback management refinement of the classPeer.
other features, e.g., clients of the message forwarding mechanism. On the other hand, implementing this feature as one standalone aspect would not reflect the structure of the P2P-PL framework that includes feedback management. All would be merged in one or more aspect(s) that would decrease program comprehension. Our AFM encapsulates all contributing elements coherently as a collaboration that reflects the intuitive structure of the P2P-PL framework we had in mind during its design.
Connection Pooling
reusing open connections
The connection pooling feature is a mechanism to save time and resources for frequently establishing and shutting down connections. To integrate connection pooling into P2P-PL, we implemented a corresponding AFM. Figure 7.5 shows this AFM consisting of the aspect Pooling and the class Pool. The aspect intercepts all method calls that create and close connections3. The pool stores open connections.
Figure 7.6 lists the pooling aspect; it uses a pool for storing references to connections (Line 2). The pointcuts close (Lines 3-4) and open (Lines 5-6) match the join points that are associated to shutting down and opening connections. Named advice putPool (Lines 7-9) intercepts the shutdown process of connections and instead stores the associ-ated ClientConnection objects in aPoolobject. Named advice getPool (Lines 10-13)
3 Note that this is not ideally visualized because the calls are intercepted at the client side.
Connection Pooling Pool
Peer
Pooling Connection
Figure 7.5: Connection pooling AFM.
recovers open connections (if available) and passes them to clients that request a new connection. This aspect makes use of the built-in pointcut this to limit the advised calls to those that originate from MessageSender objects.
1 aspect Pooling {
2 s t a t i c Pool pool = new Pool ();
3 pointcut close ( C l i e n t C o n n e c t i o n con ) :
4 c a l l (void C l i e n t C o n n e c t i o n . close ()) && target ( con ) && t h i s( M e s s a g e S e n d e r );
5 pointcut open ( C l i e n t S o c k e t socket ) :
6 c a l l ( C l i e n t C o n n e c t i o n .new( C l i e n t S o c k e t )) && args( socket ) && t h i s( M e s s a g e S e n d e r );
7 Object around putPool ( C l i e n t C o n n e c t i o n con ) : close ( con ) { 8 pool . put ( con ); return n u l l ;
9 }
10 C l i e n t C o n n e c t i o n around getPool ( C l i e n t S o c k e t socket ) : open ( socket ) { 11 i f ( pool . empty ( socket )) return proceed( socket );
12 return ( C l i e n t C o n n e c t i o n ) pool . get ( socket );
13 } 14 }
Figure 7.6: Connection pooling aspect (excerpt).
Why not using a feature module?
Implementing this feature using FOP exclusively would lead to code tangling and scatter-ing. We would have to modifyMessageSenderat every place at which the methodclose and the constructor of ClientConnection is called. Simply extending both is not pos-sible since this would affectall calls, not only those that originate fromMessageSender.
We solve this problem elegantly using advice that advises calls conditionally, i.e., depen-dently on the type of the caller, which is an advanced dynamic crosscut.
Furthermore, we did not implementPoolas a nested class within the aspectPooling to emphasize that it is regular part of the P2P-PL. We consider it part of the collaboration of artifacts that implement the feature. Subsequent refinements may extend and modify the classPool.