Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
research:dsal:ridl [2009/02/12 17:17] – created jfabryresearch:dsal:ridl [2009/02/13 12:15] (current) – jfabry
Line 1: Line 1:
 +===== RIDL =====
  
 +(Internal classification: historical)
 +
 +Reference paper: **"Aspect-Oriented Programming"** Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, John Irwin, In //ECOOP'97 -- Object-Oriented Programming//, Springer LNCS Volume 1241, P220 -- 242 , 1997. The ECOOP paper does not discuss RIDL in much detail, but instead refers to a Xerox PARC techreport ((**D: A Language Framework for Distributed Programming** Cristina  Videira Lopes, Gregor Kiczales, Xerox PARC technical Report SPL97-010, 1997)) for more information.
 +
 +Another source of detailed information is Lopes' PhD Thesis, which was was published later: **"D: A Language Framework for Distributed Programming"** Cristina Isabel Videira Lopes, //PhD Thesis of the College of Computer Science of Northeastern University//, 1997. We use the PhD thesis here as reference material as it is the most recent complete discussion of both [[COOL]] and RIDL. Quotes in this text are therefore taken from this thesis.
 +
 +
 +===== Domain of the language =====
 +
 +Both [[COOL]] and RIDL are designed as part of the **D** framework. "D is a language framework that supports new 
 +kinds of modules for addressing some of the distribution issues that are hard to capture in classes. [...]. The language framework proposed here focuses only on a subset of [distributed system] applications [...]: applications over the Internet, the Web, corporate-wide applications such as calendar managers, network managers, document management systems [...], hospital management systems, front-end applications for database access, interactive multi-user environments, and many others like these." The base language of D is Java, without the ''synchronized'' keyword.
 +
 +"[D] really consists of two languages: (1) COOL, for controlling thread synchronization over the execution of the components; and (2) RIDL, for programming interactions between remote components."
 +
 +===== Intent of the language =====
 +
 +"RIDL provides means for dealing with data transfers between different execution spaces. A RIDL program consists of a set of portal modules [...] Portals are helpers with respect to the implementation of the 
 +classes: they take care of data transfers across space boundaries. Portal declarations [...] identify classes whose instances may be referenced from remote spaces. Such instances are called remote objects. The portal declaration identifies which methods of the class are exported over the network. In the portal, such methods are called remote operations. For each of those operations, the portal declaration describes what data the remote objects 
 +are expecting and what data they send back to the callers."
 +
 +
 +===== Join Point Model and Advice Model =====
 +  * JPM: General-Purpose : Portals act on method invocations to the target object.
 +  * AM: Domain-Specific : A Portal declares which methods are remote and specifies parameter passing modes. 
 +
 +===== Anatomy of the language =====
 +
 +A portal declaration consists of a class name and a portal body. "Portals don’t have proper names. They simply refer to the [...] class. It is an error to declare two portals for the same class. [...] The portal body declares which methods of the class can be invoked remotely. Optionally, it may declare default parameter passing modes for the arguments and return values of the operations declared" 
 +
 +To declare that a method can be invoked remotely, the signature of the method is given, with an optional body. The body specified parameter passing modes for the parameters and return values. These can be by reference or by copy. "When objects are to be passed by copy, an optional copying directive may be given in their transfer specifications". This directive specifies what fields of an object are copied, using the field names or field types.
 +
 +Additionally, the body of the portal may declare default parameter passing modes for specific types.
 +
 +It is important to remark here that RIDL (and [[COOL]]) does not have a strong separation of pointcut and advice, as is now usual. The pointcut is not only defined by the signature part, as this only identifies classes. Additionally, identification of methods is performed in various parts of the body.
 +
 +The grammar of COOL and RIDL is fully described in appendix A of the thesis.
 +
 +===== Typical Example =====
 +
 +The following code is taken from Lopes' PhD thesis. It solves one of the motivating problems of the thesis, a part of a BookLocator / ProjectManager application. For more details, we refer to the thesis.
 +
 +  portal BookLocator { 
 +    void register(Book b, Location l); 
 +    void unregister(Book b); 
 +    Location locate(Book b); 
 +    default: 
 +      Book : copy { Book only all.String, all.int; }; 
 +  } 
 +  portal ProjectManager { 
 +    boolean newBook(Book b, Price p) { 
 +      Book : copy { Book only owner, all.String, all.int; }; 
 +    }  
 +  }
 +
 +===== Enforced Restrictions =====
 +
 +RIDL is an extremely restrictive language, due to its purely declarative nature which only allow remoteness properties of objects to be set. There is no way in which behavior outside of this domain can be triggered, nor it is clear how to 'break' the language. We consider it as a very nice example of what restrictions can be achieved using a DSAL.
 +
 +===== Implementation description =====
 +
 +The aspect weaver for both [[COOL]] and RIDL is discussed in detail in Appendix C of the dissertation: "The translation of DJ programs into Java is done by a pre-processor, of which the Aspect Weaver is the most important module. [...] The Parser takes DJ programs and constructs representations of them (parse trees); the Semantic Analyzer checks the semantic validity of the tree, and, at the same stage, there may be some local transformations on the trees that facilitate the implementation of the Weaver (e.g. transforming COOL condition variable declarations into ordinary Java variable declarations, transforming RIDL traversal specifications into simpler structures, etc.); the Weaver takes those transformed parse trees and outputs new trees that represent woven Java programs; finally, the un-Parser takes those internal representations of Java programs and outputs Java."