Transparent Filter Objects

1
Transparent Filter Objects

• Rushikesh K. Joshi
• Department of Computer Science Engineering
• Indian Institute of Technology, Bombay
• Mumbai - 400 076

2
About the Author

• R.K. Joshi is with the Department of Computer
  Science and Engineering at IIT Bombay as
  Assistant Professor, where he has introduced a
  course on Object Oriented Systems. He currently
  teaches courses on Object Oriented Systems and
  Operating Systems. He has provided consultancy
  and teaching in Object Oriented Technologies to
  academia and the Indian Industry. He has designed
  various programming paradigms focused on the
  principle of separation of concerns, among them
  are the Anonymous Remote Computing (IEEE TSE,
  1999) for parallel computing on loaded
  heterogeneous fail-stop workstations, Filter
  objects (SPE 1997), and Replicated Services (JPDC
  1999).
• He completed his PhD thesis from Indian Institute
  of Technology, Madras in 1996. He is with IIT
  Bombay since 1997. His current interests are
  software architectures, paradigms for evolution,
  interclass and interobject relationships and
  distributed object systems.

3
Outline of the Talk

• Messages in the conventional object model
• The filtered message delivery model
• The filter object programming model and its
  implementation for C
• Filter configurations
• Filter Objects for CORBA
• Filter Objects for Software Evolution

4
Interacting Objects

• Objects are the building blocks in an object
  oriented software
• Objects interact with each other through message
  invocations on each other
• e.g. to get something done by an object o2, o1
  invokes a method defined by o2

m
o1
o2
5
The Direct Delivery Message Model

• A message is directly delivered to the receiver
  object specified by the source object
• e.g. O2.m in object o1 specifies a message
  invocation m on o2 o2 is identified by o1.
• A message invocation on the receiver object is
  the immediate consequence of message generation
  at message source

6
Message Control and Message Processing

• Message Processing The actual code at the
  receiver provides the functionality desired by
  the caller
• Message Control Intermediate manipulations on
  messages
• In the direct delivery model, message
  manipulations cannot be performed on-the-fly and
  they must be taken care of by the message
  processing code itself

7
The Filtered Delivery Model

• Messages can be trapped by intermediate filter
  objects which are transparent
• Filter objects are also conventional objects and
  in addition to the conventional properties of
  object orientation, they possess message
  filtering capabilities

8
Transparency Property of Filter Objects

• Clients are unaware of the existence of filter
  objects, i.e. clients still identify the desired
  receiver objects as in the conventional object
  model

Server.m
f
m
Object Server
Object Client
Object Filter
9
Properties of Filter Objects

• Interception of upward messages
• Interception of downward results
• Manipulation of message arguments
• Pass and Bounce capabilities
• Capabilities of conventional objects
• Selective Filtering
• Dynamic binding at instance level
• Modular development

10
The Core Filter Object Model

another
bounce
upfilter
Invoke m ()
pass
Server.m
return
downfilter
Client
Server
Filter
11
Interclass Filter Relationship

• An instance of a class C1 that is in filter
  relationship with class C2 has the ability to
  transparently intercept the messages sent to an
  instance of class C2.
• Class Dictionary
• Class Cache filter Dictionary .

12
Dynamic Plugging of Filter Objects

• Filter relationships are statically established
  at class level but dynamically at the instance
  level
• The plug and unplug operations
• main ( )
• Dictionary d..
• Cache c..
• plug d c
• unplug d

13
Organization of a Filter Class The Filter
Interface

• Class Dictionary
• public Meaning SearchWord( Word)
• class Cache filter Dictionary
• upfilter
• Meaning SearchCache(Word) filters SearchWord
• downfilter
• Meaning ReplaceCacheEntry (Meaning) filters
  SearchWord
• public
• double hitRatio ( )

14
An Application of Filter Objects (D Janaki Ram
et. al, IEEE SMC march 1997)
Piston object
Crank object
Constraint object
Constraint object
notify
Apparent path
notify
Real Path
DESIGNER2
DESIGNER1
A Collaborative Designing Scenario
15
Extended Properties of Filter Objects

• Group Filtering
• Many instances of a server object may be plugged
  with a filter object which is an instance of a
  filter class in filter relationship with the
  server class
• Layered Filtering
• Filters to filters may be specified to achieve
  layered filtering

16
Implementing Filter Objects for C

filt
Class AbstractFilter
serviceA
filterA
serviceB
filterB
Class Server
filterA
filterA
filterB
filterB
Class ConcreteFilter1
Class ConcreteFilter2
17
Filter Configurations

• Replacer
• Router
• Repeater
• Value Transformer
• Message Transformer
• Request Logger

18
Replacer

• A filter member function operates as a
  replacement function to its corresponding server
  member function
• FastServer oldServer
• filter interface
• funcReplacer (in) upfilters oldServer func
  (in)
• v lt-- self.func (in) bounce (v)

client
filter
server
19
Router

• A filter member function operates as a router
  function
• balancer searchEngine
• filter interface
• searchRouter (item) upfilters SearchEngine
  search (item)
• newDest lt-- self.nextDest()
• vlt--newDest.search(item) bounce (v)

client
filter
server
server2
20
Repeater

• A filter member function dispatches the filtered
  invocation to multiple servers
• enrollFilter centralEnroller
• filter interface
• libEnroll (student) upfilters centralEnroller
  enroll (student)
• if (student.dept civil)
  civilLib--gtenroll (student)
• if (student.status minor)
  minorBody--gtenroll(student)
• pass

client
filter
server1
server2
server3
21
Transformers and Logger

• Value Transformer
• Message contents are changed before the message
  is delivered to the server e.g. to handle
  encryption
• Message Transformer
• A different message is called on the server e.g.
  to support clients that know of an older
  interface
• Logger
• A message is invoked on a different object and
  the member function is passed on to the actual
  server e.g. to implement the decorator design
  pattern

22
Filter Objects for Distributed Object Systems

• Need-to-filter principle A server is declared as
  Filterable Server
• A filter object cannot be plugged to a server
  that is not declared as filterable
• interface Filterable
• attach (in Object filter)
• detach ()
• interface Server Filterable
• service ()

23
Implementation of IDL Filterable

• A standard implementation of Filterable is
  provided in class Filterable_impl
• class Filterable_impl public Filterable_skel
• // library implementations of attach and detach

24
Implementing Filterable Servers

• An implementation of a filterable server must
  inherit the standard implementation of IDL
  Filterable
• class Dictionary_impl public Filterable_impl,
  public Dictionary_skel
• // implementations of Dictionary IDL

25
Implementing Filter Objects

• IDL precompiler generates a Filter Base Interface
  for each filterable server interface
• The Filter base interface is implemented by the
  filter object implementer
• interface Dictionary_Filter
• // up and down filter member declarations
• A post-translator is also required to modify the
  dispatcher

26
Activation and Deactivaton of Filter Objects

• A CORBA Object that acquires handles to a filter
  object and its corresponding filterable server
  object may carry out the plug and unplug
  operations
• main ( )
• .
• server_obj--gtattach (filter_obj)
• server_obj--gtdetach ( )

27
Filter Netwoks for Software Evolution

• Inject a network of collaborating filter objects
  into an existing object oriented software system
  to satisfy evolution requirements

Filter Object Network
Object2
Object1
Object3
Object4
28
Properties of the Injection Approach

• No need to modify the existing code Modified
  functionalities can be handled separately by the
  collaborating filter objects
• Evolution is reversible By lifting the filter
  network
• Original object oriented design must be
  filter-aware

29
An Example of Filter Based Evolution Readers and
Writers R.K. Joshi, PhD Thesis, IIT Madras,
India, 1996

• Original Code (Hansen 1978)
• process resource
• s int
• proc StartRead when sgt0 s end
• proc EndRead if s gt1 s-- end
• proc StartWrite when s1 s-- end
• proc EndWrite if s0 s end
• s1

30
Evolution Requirement

• Solve the same problem with additional constraint
  that further reader requests should be delayed as
  long as there are writers waiting or using the
  resource
• A filter object based solution is provided to
  solve this problem without modifying the existing
  code

31
The Approach

old solution
Old monitor
Old reading and writing clients
evolved solution
Old monitor
Old reading and writing clients
Injected Filter
32
Evolution using Filter Object

• process problemSolver filter resource
• www int
• upfilter
• SW_Ufilter filters StartWrite
• SR_Ufilter filters StartRead
• downfilter
• EW_Dfilter filters EndWrite
• proc SW_Ufilter www pass end
• proc EW_Dfilter www--- end
• proc SR_Ufilter when www0 pass end
• www0

33
Our Prediction

• Transparent Filter Objects will be recognized as
  important architectural components in object
  oriented software systems
• Implementations of some kind of filtering
  capabilities will be widely available as through
  integration into todays commercial object
  oriented software technologies.

34
Conclusions

• Transparent Filter Objects can be integrated into
  the well established model of object oriented
  programming.
• Filter Objects are powerful tools for Software
  Evolution
• Filter object implementations for C and CORBA
  based object oriented systems have been designed
  and implemented (Recently, We have also
  integrated the First Class Filter Object Model
  into JAVA).

35
Conclusions ..

• Some of the Filter Configurations have been
  identified as elementary building blocks for
  filter-based architectures.
• Filter Configurations have interesting
  consequences when applied to software evolution

36
Future/Ongoing Work

• Further explorations on Programming models,
  efficient implementation mechanisms and
  applications of Transparent Interception
• Methodology for software evolution based on
  filter objects
• Understand the capabilities and limitations of
  filter objects

37
Available Results on Filter Objects

• 1 Rushikesh K. Joshi, N. Vivekananda, D Janaki
  Ram, Software Practice and Experience, June 1997,
  pp. 677-699
• 2 Rushikesh K. Joshi, Filter Configurations for
  Structuring Distributed Object Systems, To appear
  in Journal of Object Oriented Programming.
• 3 Rushikesh K. Joshi, On-the-fly Evolution of
  Object Oriented Systems using Filter Objects,
  Technical Report, Feb. 1999, IIT Bombay. (result
  submitted for publication).
• 4 G. Sriram Reddy, Rushikesh K. Joshi, Filter
  Objects for Distributed Object Systems, To Appear
  in Journal of Object Oriented Programming
  (January 2001).
• 5 R. K. Joshi, Modeling with Filter Objects in
  Distributed Systems, To be presented at EDO 2000,
  UC Davis, Nov 2-3, 2000
• 6 Maureen Mascarenhas, R. K. Joshi, Design and
  Implementation of Filter Objects for JAVA,
  Technical Report, IIT Bombay October 2000.
  (result submitted for Publication).