1. AspectJ Based Implementation of Dynamically Pluggable Filter Objects in Distributed Environment Rushikesh K. Joshi, Neeraj Agrawal Department of Computer Science and Engineering Indian Institute of Technology Bombay, India Contact: Rkj@cse.iitb.ac.in

2. The Filter Object Model based on Interclass Filter Relationship server.m m () another pass return bounce downfilter upfilter client afilter server

3. Modeling an Interclass Filter Relationship AClient Cache SearchBase remote () ser search () upFilter() | search() downFilter() | search()

4. Modeling an Inter-instance Filter Relationship: A Dynamic State trans:Client cache:Cache sb:SearchBase ser logger:Log

5. Properties of Filter Objects Filter Object Specification decoupled from Client/Server class specifications Filter Objects are instance of classes Transparency: client and server code unaware of filter objects Filtering of upward and downward messages Dynamic Pluggability: specify, create, plug, reconfigure at runtime Chaining and Grouping

6. Key Features of the AspectJ Implementation of Filter Objects An Aspect specification - To model filter objects Calls delegated to a filter pipe – pointcuts and around advice Filter Pipe - Organizes the chain of filter objects, which may themselves be distributed –Filter pipe is a remotely available object –Maintains Mappings from client-server pairs to vectors of filter objects (upfilters and downfilters)

7. The Solution Aspect FilterObject upFilter1 () downFilter1 ().. FilterObjectN upFilter1 () downFilter1() FilterPipe upFilter1 () downFilter1 (..) For all f in FOs f->upFilter() FilterObject1 upFilter1 () downFilter1() FOs …..

8. Development Process Base Code  Filter Class Abstraction  Base Code Compilation with Abstraction (needed if environment is not ‘filter aware’)  Base Code in execution  Filter Object Development may be developed as late as this point after their abstraction is known  Inject filters into the system, reconfigure as programmed for

9. A Server Implementation Class CSearch implements ISearch extends UnicastRemoteObject { String search (String query); } Class SearchFactory {.. main () { …create and bind a CSearch component … }} CSearch is a remotely available object

10. A FilterPipe Implementation Class CSearchFilterPipe implements ISearchFilterPipe extends UnicastRemoteObject{ static vector upFilterVector = new Vector; static vector downFilterVector = new Vector; boolean searchUp (..)…go through all upfilters if earlier not bounced … void searchDown (..).. Go through all downfilters … } FilterPipeFactory creates and binds a filterpipe Filter pipe holds filter objects

11. Implementation of Filter Objects Class Replacer implements ISearchFilter { Boolean searchUp (..)… searchDown (..)… } Class Repeater implements ISearchFilter { ….. }

12. Implementing the client Class SearchClient {..main (..) { …lookup and bind to intended server… …invoke desired methods... }

13. The Aspect Code aspect SearchAspect { ISearchFilterPipe seFp; ….. pointcut on search call/execution.. around advice on search call { …lookup and bind to filter pipe.. …call upfilter member on filter pipe.. …if not bounced, proceed to intended server.. …call downfilter member on filter pipe… return result }

14. Filter Binding Types One-to-OneOne-to-Many Many-to-One Many-to-Many

15. Typical Deployments One-to-OneClient Side/Server Side –Low network overhead One-to-ManyClient Side –Client side deployment more efficient since all filtered messages originate from one client May-to-OneServer Side –Server side deployment more efficient since all filter messages are against one server Many-to-ManyPossibly on an Independent Machine –Depends on network overheads, load Per Class/Per Object/Per Machine Filter Pipes

16. Conclusions Proposed a scheme for implementation of dynamically pluggable and distributed Filter Objects on top of AspectJ Requires base code to be filter aware when in execution Supports rich possibilities of configuring filter objects Brought out the need for a careful selection of a Deployment Strategy

17. Issues put forward for Discussion Is the requirement of Filter Aware Base Code a desirable property? –Consider Static vs. dynamic awareness Is there an advantage in turning Programming Environments themselves Filter Aware What is the right granularity of filter specifications and is there synthesis? – per process, per object, per message, per machine, per class, per client..chains,groups.. Is there separation of high level abstractions of filters from their low level generalizations? How efficient can the mappings from former to latter be?