1 / 37

Transparent Filter Objects

Transparent Filter Objects. Rushikesh K. Joshi Department of Computer Science & Engineering Indian Institute of Technology, Bombay Mumbai - 400 076. About the Author .

arden-foley
Télécharger la présentation

Transparent Filter Objects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Client Object Filter Object Server

  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 pass Invoke m () 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 <-- 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 <-- self.nextDest(); v<--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-->enroll (student); if (student.status == minor) minorBody-->enroll(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-->attach (filter_obj); … server_obj-->detach ( ); }

  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 s>0 : s++; end proc EndRead if s >1: s--; end proc StartWrite when s==1: s--; end proc EndWrite if s==0: s++; end s=1;

  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 www==0: pass; end www=0;

  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 today’s 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).

More Related