Contextl Soa

7/31/2019 Contextl Soa

1/5

Context-oriented Programming in ContextL

State of the Art

Pascal CostanzaProgramming Technology Lab

Vrije Universiteit BrusselB-1050 Brussels, Belgium

[email protected]

ABSTRACT

There is a wide range of scenarios where software systemshave to be able to behave differently according to theircontext of use. In Context-oriented Programming (COP),programs can be partitioned into behavioral variations thatcan be freely activated and combined at runtime with well-defined scopes, such that the program behavior is affecteddepending on context. About four years ago, we have intro-

duced our vision of Context-oriented Programming and havepresented the programming language ContextL as an exten-sion to the Common Lisp Object System (CLOS), as ourfirst language extension that explicitly realizes this vision.Since then, ContextL has been picked up by various devel-opers world-wide, is now in use in several software systems,and has been continuously improved to meet the demandsof its users. For these reasons, ContextL can currently b eregarded as the most mature realization of COP concepts.In this paper, we give an overview of the major ingredientsof ContextL, describe the developments in ContextL of thelast four years, and sketch some future work.

Categories and Subject Descriptors

D.1 [Software]: Programming TechniquesObject-orientedProgramming; D.3.3 [Programming Languages]: Lan-guage Constructs and Features

Keywords

Context-oriented programming, behavioral variations, layeractivation, dynamic scoping

1. CONTEXT-ORIENTED PROGRAMMINGThere is a wide range of scenarios where software systems

have to be able to behave differently according to their con-text of use [2, 3, 4, 6, 16, 23, 25, 28]. In Context-orientedProgramming (COP), programs can be partitioned into be-havioral variations that can be freely activated and com-

bined at runtime with well-defined scopes. Such behavioral

c ACM, 2008. This is the authors version of the work. It is posted hereby permission of ACM for your personal use. Not for redistribution. The

definitive version is published in Celebrating the 50th

Anniversary of Lisp,http://doi.acm.org/10.1145/1529966.1529970

variations consist of partial definitions for typical programentities, like classes, methods, functions, procedures, and soon. The essential ingredients of Context-oriented Program-ming are as follows:

Context is any information that can be computationallyaccessed in a software system.

Behavioral variations describe the context-dependent be-

havior of a software system as increments on the un-derlying context-independent program definitions.

Layers group such behavioral variations as first-class enti-ties that can be referenced in a program at runtime.

Layer activation is achieved by language constructs thatensure that such layers are added at runtime, such thatthe respective partial program definitions have an in-fluence on the actual behavior of a program.

Scoping of layer activation and deactivation ensures thatthe behavioral variations are only effective for well-defined parts of a program, and for well-defined dura-

tions.

Context-oriented Programming focuses on programmingconstructs to enable grouping, referencing, and activationand deactivation of layers of behavioral variations. It shouldthus be seen as a complement to the (equally important) re-search on context acquisition and reasoning, where the focusis on sensing (low-level) context data and inferring (high-level) context information (for example [25]). Our definitionof context is open and pragmatic, in that it treats any com-putationally accessible information as potential parametersfor influencing the behavior of a program. In contrast, thewidely cited definition for context of Dey at al. [17] statesthat Context is any information that can be used to char-acterize the situation of an entity. An entity is a person,

place, or object that is considered relevant to the interac-tion between a user and an application, including the userand applications themselves. That definition distinguishesbetween relevant and irrelevant information, which is im-portant when modelling systems for context acquisition andcontext reasoning. It differs in this regard from our defi-nition that is targeted at structured ways of how to affectprogram behavior depending on context, which should beaddressed by general-purpose constructs and thus indepen-dent of the kinds of context information they may or maynot depend on.


2/5

About four years ago, we have introduced our vision ofContext-oriented Programming and have presented the pro-gramming language ContextL as an extension to the Com-mon Lisp Object System (CLOS), as our first language ex-tension that explicitly realizes this vision [8]. Since then wehave implemented the underlying ideas as extensions for var-ious other programming languages, like Smalltalk [19], Java[9], Ruby and Python, together with various use cases. Dur-ing the course of these experiments, the essential ingredients

of context, behavioral variations and scoped layer activationhave proved to be stable corner stones.1

On top of that, ContextL has been picked up by variousdevelopers world-wide since its public release as an open-source language extension, is now in use in several softwaresystems in the real world, and has been continuously im-proved to meet the demands of its users. For these reasons,ContextL can currently be regarded as the most mature re-alization of COP concepts.2

2. CONTEXTL: STATE OF THE ART

2.1 Essential FeaturesContextL is an extension to the Common Lisp Object Sys-

tem (CLOS), and thus includes object-oriented features likeclasses with multiple inheritance, slots (fields) and meth-ods with multiple dispatch. Like CLOS, ContextL is notbased on message sending, but on generic functions [5].3

For each of the core defining constructs in CLOS, there is acorresponding defining construct in ContextL: For definin-ing classes, ContextL provides define-layered-class as ananalogue to CLOSs defclass. Likewise, ContextL providesdefine-layered-function and define-layered-method asanalogues to CLOSs defgeneric and defmethod for defin-ing generic functions and methods.

Layers can be introduced in ContextL with deflayer andan associated name, as follows.

(deflayer layer-name )

Such layers can then be further specified with partial classand method definitions, which can be explicitly associatedwith such layers, as follows.

(define-layered-class class-name

[:in-layer layer-name ]({superclass })

({slot-specification})

{class-option})

(defmethod function-name [:in-layer layer-name ]{method-qualifier} parameters method-body)

There is always a root layer present that defines the context-independent behavior of a program, and class and methoddefinitions can be associated with the root layer by either

omitting the :in-layer specification, or by using t as thelayer name.4

1All this work has been performed in close collaborationwith Robert Hirschfeld.2ContextL can be downloaded fromhttp://common-lisp.net/project/closer/contextl.html3Note, however, that our experiments with similar exten-sions for other object-oriented programming languages showthat COP is compatible with message sending as well.4The symbol t is traditionally used in Lisp dialects to denotegeneral concepts, like the boolan truth value, the super-

By default, only the root layer is active at runtime, whichmeans that only definitions associated with the root layereffect the behavior of a program. Other layers can be acti-vated at runtime by way of with-active-layers, as follows.

(with-active-layers ({layer-name })

body)

Such a layer activation ensures that all the named layersaffect the program behavior for the dynamic extent of the

enclosed program code (body). Layer activation is dynami-cally scoped: Both direct and indirect invocations of genericfunctions (methods) and slot accesses in the control flowof the layer activation are affected. Furthermore, layer ac-tivation is restricted to the current thread of execution inmultithreaded Common Lisp implementations, to avoid raceconditions and interferences between different contexts.

Furthermore, layers can be deactivated at runtime by wayof with-inactive-layers, as follows.

(with-inactive-layers ({layer-name })

body)

Such a layer deactivation ensures that none of the namedlayers affect the program behavior for the dynamic extent ofthe enclosed program code anymore. As with with-active-

layers, layer deactivation is dynamically scoped and re-stricted to the current thread of execution.

Layer activations and deactivations can be nested arbi-trarily in the control flow of the program. Both multipleactivations and deactivations of the same layer are ignored,each layer is only active or inactive at most once. Further-more, the order of layer activation determines method speci-ficity when generic functions are invoked: Methods frommore recently activated layers in the control flow of a pro-gram are executed before methods from less recently acti-vated layers and the root layer.

The above constructs allow referencing layers at runtime,but only as second-class citizens. However, for each of theabove constructs, there exist corresponding first-class con-structs: The functions ensure-layered-function, ensure-layered-method and ensure-layer enable defining layeredfunctions, layered methods and layers at runtime. Further-more, funcall-with-layer-contextand apply-with-layer-context enable activating and deactivating computed com-binations of layers, and adjoin-layer and remove-layer en-able computing such combinations of layers from first-classlayer representations.

Finally, there are cases where it is useful that layers areactivated or deactivated globally for all threads without dy-namic scope, for example for interactive testing and de-velopment, or for program deployment (at system startuptime). The functions ensure-active-layer and ensure-inactive-layer enable such global activation and deactiva-tion of layers.

2.2 Efficient Layer ActivationContext-oriented Programming encourages continually

changing program b ehavior. For example, we have illus-trated a use case in [9] where side effects on graphical ob-jects trigger updates of their representations on the screen.Context-oriented Programming can successfully be used insuch a scenario to avoid invalid screen updates in situationswhere graphical objects are in intermediate states during

type of all types, the standard output stream, and so on.


3/5

composite changes. This use case is characterized by re-peated activation and deactivation of a layer that is respon-sible for the necessary screen updates.

Such examples show that it must be possible to implementlayer activation and deactivation efficiently in order to makeContext-oriented Programming a sane option in a program-mers toolbox. It is indeed not obvious that layer activationand deactivation can be efficient. However, we have foundan implementation for ContextL on top of CLOS with com-

petitive performance. The key ingredients are as follows.

Layer activation and deactivation leads to a runtimecomposition of multiple, arbitrary layers. Such layercomposition is realized internally in ContextL by reusingCLOSs support for multiple inheritance. This can beachieved by representing composed layers as dynami-cally created classes that multiply inherit from otherlayers, on top of which they are activated and whichare themselves represented as classes. Dynamic classcreation is supported by way of the CLOS MetaobjectProtocol [20], and although dynamic class creation iscostly in terms of performance, such classes can becached in a way such that each combination of a givensequence of layers needs to be created only once, andcan be looked up very efficiently from then on.

In ContextL, method selection and combination mustdepend on the current sequence of active layers. Sincelayer combinations are already represented as classes,we can internally represent the current sequence of ac-tive layers as a (prototypical) instance of such a com-bined class, and drive method selection and combina-tion by implicitly passing such an instance as an argu-ment to an appropriately specialized parameter thatis added to each layered method internally.5 In thiscase, efficiency also comes from caches that allow forfast lookup of applicable methods, which is alreadyprovided by typical CLOS implementations [21].

Layer activation and deactivation must modify the cur-rent sequence of active layers in such a way that thechange is only visible in the current thread of execu-tion, to ensure that they do not interfere with otherthreads in multithreaded Common Lisp implementa-tions. To achieve this, the representation of the cur-rent sequence of active layers is bound to a dynami-cally scoped, thread-local variable, which are directlysupported by Common Lisp and for which implemen-tation alternatives with well-understood performancecharacteristics exist [1].

In [9], we discuss our overall implementation strategy inmore detail, together with some benchmarks that indeedshow a low overhead for layer activation and deactivation interms of performance.

2.3 Reflective Layer ActivationOrganizing a program into layers may lead to dependen-

cies between layers: Layers may require each others pres-ence, or may be mutually exclusive. For example, a typicaluse case for Context-oriented Programming is to separate

5Due to the fact that CLOS supports multiple dispatch,adding such a specialized parameter to a method does notprevent users from dispatching on other arguments.

the generation of different output formats (html, pdf, json,etc.) from the same document tree into several layers. Acti-vating a layer for one output format should thus deactivatethe layers for other output formats. In [10], we illustratedthis idea with another example, where different tariffs for cellphone usage are separated into different layers, which mustbe mutually exclusive and, at the same time, all require thepresence of another base tariff layer.

In principle, it is possible to make such dependencies ex-

plicit by simply activating and deactivating all the involvedlayers in all the places where layer activation or deactiva-tion occurs. However, this turns out cumbersome. In [10],we introduce a reflective API for ContextL that can be usedto make layer activations and deactivations automaticallytrigger other layer activations and deactivations behind thescenes. The essential idea is that each layer activation com-putes the resulting sequence of active layers by invoking thefunction adjoin-layer-using-class, and each layer deac-tivation computes the resulting sequence of active layers byinvoking remove-layer-using-class. These two functionsare exposed by the ContextL API, are themselves layeredfunctions, and can thus themselves be specialized by user-provided layered methods. Such layered methods can in-

spect the layers to be activated or deactivated, inspect thecurrent sequence of active layers, and ensure that other re-quired layers are implicitly activated as well, other excludedlayers are implicitly deactivated, or invalid layer activationsor deactivations are rejected.

In [10], we discuss the details of ContextLs reflective ar-chitecture, illustrate its use by giving examples, and showthat it can be implemented without affecting the p erfor-mance achieved by the implementation strategy discussedin [9] (see above).

2.4 Description of Layer DependenciesIn spite of the usefulness of reflective layer activation, im-

plementing extensions on top of ContextLs reflective APIproves to be a complex task. In [12], we show a first step

of how feature diagrams, or better the feature descriptionlanguage (FDL, [15]) as their textual counterpart, can beused to provide a high-level description of layer dependen-cies, such as requirement and exclusion dependencies. FDLcan be added as an extension on top of ContextLs reflectiveAPI without changing any of ContextLs internal implemen-tation details, and without affecting its essential efficiencycharacteristics.

We have also gained some first experience with using fea-ture diagrams for the requirements elicitation and designphases of context-oriented systems. Context-Oriented Do-main Analysis (CODA) [14] is a notation and methodologyfor describing both the context-independent behavior andthe context-dependent behaviorial variations of a system.

This notation is based on feature diagrams, but extends it toinclude potentially dynamically changing conditions un-der which layers are required or excluded. We are currentlyworking on mapping CODA diagrams to context-orientedprogramming languages such as ContextL.

2.5 ImpactSince its original release in 2005, ContextL has been picked

up by several developers world-wide, and is now used in anumber of software systems in the real world. ContextLis typically employed in web applications, where layers are


4/5

used to separate generation of different output formats fromthe same document tree, and to provide different views andmodes to different kinds of users depending on their re-spective tasks. For a description of one exemplary case seehttp://p-cos.blogspot.com/2007_11_01_archive.html.

Furthermore, Context-oriented Programming has startedto impact other researchers who have picked up the termand the concepts as starting points for their own work [7,13, 18, 26]. A detailed discussion of such related work is

outside the scope of the overview given here.

3. FUTURE WORK AND CONCLUSIONSThere are several ways in which ContextL can be extended

to broaden its scope of applicability:

ContextLs reflective API can be extended to supportfirst-class dynamic enviroments. The idea is to sup-port capturing the current sequence of active layersas a first-class entity such that it can be reeinstatedlater for a different context. For example, this wouldallow passing context from one thread to another andstoring the current context of a suspended computa-tion to be later resumed, for example in continuation-

based web applications [24]. Since frameworks for suchcontinuation-based web applications are typically basedon partial continuations, we actually need support fordelimited dynamic bindings, as in [22]. Since there aredifferent continuation frameworks available for Com-mon Lisp, we have to design the reflective API forfirst-class dynamic environments in such a way thatthey are compatible with different kinds of partial con-tinuations.

Currently, layers in ContextL contain partial class andmethod definitions, where the method definitions aretypically specialized on classes. Although CLOS sup-ports method specialization on single objects as well,

somewhat similar to what is provided in prototype-based object systems, the actual use of layer activa-tion or deactivation for single objects is not straight-forward, but would sometimes be useful. After someexperimentation with different ideas, we have comeup with a generalization of generic function dispatchcalled filtered dispatch which allows for filtering argu-ments before method selection and combination, whilepassing the original unfiltered arguments to the thusselected methods for execution [11]. This results ina very powerful and expressive dispatch mechanism,which has a potential to serve as a basis for context-dependent behavior of single objects.

Context-dependent behavior is also important in dis-

tributed settings, especially in the case of ad-hoc mo-bile networks between mobile devices. Some first ex-periments in using COP concepts in such a setting arevery promising. Interesting research topics are how todistribute layer activation across several nodes of sucha network, and how to deal with potentially differentcontext parameters from different interacting nodes.We have described first steps in that regard in theContext-Dependent Role Model [27], and are currentlyworking on integrating a full-fledged distributed archi-tecture with ContextL.

Other important areas of research need to address ques-tions such as:

What are good software architectures that can takeadvantage of Context-oriented Programming? There isnow a considerable amount of pratical experience withlanguages like ContextL, and some design principleshave started to emerge, but they have not been codifiedyet, for example in the form of design patterns and

architectural patterns, or in the form of libraries andframeworks that take advantage of Context-orientedProgramming.

What are good methodologies for eliciting requirementsfor, and designing context-oriented software systems?We have made some first steps with CODA [14] (seeabove), and current research in the field of SoftwareProduct Lines and especially Dynamic Software Prod-uct Lines are very promising starting points.

How can context-aware systems be tested and verified?This is an inherently hard issue because of the combi-natorial explosion of possibilities induced by the pres-ence of multiple context parameters, which is reflectedin Context-oriented Programming by the presence of

multiple layers that can be arbitrarily combined witheach other in the general case.

At this stage in time, we can rightfully claim that Context-oriented Programming has reached a certain level of matu-rity, has fostered some interesting research results, and hasstarted to gain traction in industry. ContextL, as based onthe Common Lisp Object System, has proved to be a viabletool both for research and for industrial use, and will there-fore remain one of our main vehicles for exploring the fieldin more depth.

Acknowledgments

The central concepts of Context-oriented Programming havebeen discovered and defined in close collaboration with Robert

Hirschfeld over the years.The following people have generously offered their views

and insights to improve our understanding of Context-orie-nted Programming in general, and the concrete realizationin the form of ContextL, at various stages: Eli Barzilay,Elisa Gonzalez Boix, Nick Bourner, Tim Bradshaw, JohanBrichau, Thomas Burdick, Jeff Caldwell, Thomas Cleenew-erck, Drew Crampsie, Tom van Cutsem, Theo DHondt,Brecht Desmet, Peter Ebraert, Johan Fabry, Paul Foley,Richard Gabriel, Ron Garret, Steven Haflich, Michael Haupt,Charlotte Herzeel, Kaz Kylheku, Ralf Lammel, Attila Lend-vai, Bjoern Lindberg, Barry Margolin, Joe Marshall, Wolf-gang De Meuter, Mario Mommer, Stijn Mostinckx, OscarNierstrasz, Pekka Pirinen, Kent Pitman, Igor Plekhov, An-

dreas Raab, Christophe Rhodes, Alexander Schmolck, Niko-demus Siivola, Eric Tanter, Dave Thomas, Jorge Vallejos,Kristof Vanhaesebrouck, Peter Wasilko, and JonL White.

4. REFERENCES[1] Henry Baker. Shallow Binding Makes Functional

Arrays Fast. ACM Sigplan Notices 26, 8 (Aug. 1991).

[2] Matthias Baldauf, Schahram Dustdar, FlorianRosenberg. A Survey of Context-Aware Systems.International Journal of Ad-Hoc and UbiquitousComputing, Interscience Publishers, January 2006.


5/5

[3] Jakob E. Bardram. Applications of Context-AwareComputing in Hospital Work: Example and DesignPrinciples. Proceedings of the 2004 ACM Symposiumon Applied Computing. ACM Press.

[4] Chatschik Bisdikian, Isaac Boarnah, Paul Castro,Archan Misra, Jim Rubas, Nicolas Villoutreix, DannyYeh, Vladimir Rasin, Henry Huang, and CraigSimonds. Intelligent Pervasive Middleware forContext-Based and Localized Telematics Services.Proceedings of the 2nd International Workshop onMobile Commerce. ACM Press, 2002.

[5] Daniel Bobrow, Linda DeMichiel, Richard Gabriel,Sonya Keene, Gregor Kiczales, David Moon. CommonLisp Object System Specification. Lisp and SymbolicComputation 1, 3-4 (January 1989), 245-394.

[6] Guanling Chen, David Kotz. A Survey ofContext-Aware Mobile Computing Research. TechnicalReport, Department of Computer Science, DartmouthCollege, November 2000.

[7] Andreas Classen, Arnaud Hubaux, Frans Sanen, EddyTruyen, Jorge Vallejos, Pascal Costanza, Wolfgang deMeuter, Patrick Heymans, and Wouter Joosen.Modelling Variability in Self-Adaptive Systems:

Towards a Research Agenda. Workshop onModularization, Composition and GenerativeTechniques for Product Line Engineering(McGPLE08). Workshop of the Seventh InternationalConference on Generative Programming andComponent Engineering (GPCE08).

[8] Pascal Costanza and Robert Hirschfeld. LanguageConstructs for Context-oriented Programming. ACMDynamic Languages Symposium 2005. ACM Press.

[9] Pascal Costanza, Robert Hirschfeld, and Wolfgang DeMeuter. Efficient Layer Activation for SwitchingContext-dependent Behavior. Joint ModularLanguages Conference 2006, Proceedings, SpringerLNCS.

[10] Pascal Costanza and Robert Hirschfeld. ReflectiveLayer Activation in ContextL. ACM Symposium onApplied Computing 2007 (SAC 2007), Technical Trackon Programming for Separation of Concerns (PSC2007), Proceedings, ACM Press.

[11] Pascal Costanza, Charlotte Herzeel, Jorge Vallejos,and Theo DHondt. Filtered Dispatch. DynamicLanguages Symposium 2008) (DLS08), co-located withECOOP 2008. Proceedings, ACM Digital Library.

[12] Pascal Costanza and Theo DHondt. FeatureDescriptions for Context-oriented Programming, 2ndInternational Workshop on Dynamic Software ProductLines (DSPL08), co-located with Software ProductLine Conference 2008 (SPLC2008). Proceedings.

[13] Marcus Denker, Mathieu Suen, and Stephane Ducasse.The Meta in Meta-object Architectures. TOOLSEurope 2008, Proceedings. Springer, 2008.

[14] Brecht Desmet, Jorge Vallejos, Pascal Costanza,Wolfgang De Meuter, Theo DHondt.Context-Oriented Domain Analysis. Modeling andUsing Context, Sixth International andInterdisciplinary Conference on Modeling and UsingContext. Proceedings. Springer LNCS, 2007.

[15] Arie van Deursen and Paul Klint. Domain-SpecificLanguage Design Requires Feature Descriptions.Journal of Computing and Information Technology,10(1):1-17, 2002.

[16] Anind Dey, Gregory Abowd. CybreMinder: AContext-Aware System for Supporting Reminders.Second International Symposium on Handheld andUbiquitous Computing 2000, Proceedings, SpringerLNCS.

[17] Anind Dey, Gregory Abowd. Towards a betterunderstanding of context and context awareness.Proceedings of Workshop on the What, Who, Where,When and How of Context Awareness, April 2000.

[18] Sebastian Gonzalez, Kim Mens, and Alfredo Cadiz.Context-Oriented Programming with the AmbientObject System. 1st European Lisp Symposium(ELS08). Proceedings, Journal of UniversalComputer Science, 2009 (to appear).

[19] Robert Hirschfeld, Pascal Costanza, Oscar Nierstrasz.Context-oriented Programming. Journal of ObjectTechnology, ETH Zurich, 3/4 2008.

[20] Gregor Kiczales, Jim Des Rivieres, Daniel Bobrow.The Art of the Metaobject Protocol. MIT Press, 1991.

[21] Gregor Kiczales and Luis Rodriguez. Efficient methoddispatch in PCL. Proceedings of the 1990 ACMconference on LISP and Functional Programming.ACM Press.

[22] Oleg Kiselyov, Chung-chieh Shan, and Amr Sabry.Delimited Dynamic Binding. Proceedings of the 11thACM SIGPLAN International Conference onFunctional Programming (ICFP06). ACM Press.

[23] Zakaria Maamar, Djamal Benslimane, Nanjangud C.Narendra. What Can Context Do For Web Services?Communications of the ACM, 49, 12, December 2006.

[24] Christian Queinnec. The Influence of Broswers onEvaluators or, Continuations to Program Web Servers.Proceedings of the Fifth ACM SIGPLAN International

Conference on Functional Programming (ICFP00).ACM Press.

[25] Daniel Salber, Anind Dey, Gregory Abowd. TheContext Toolkit: Aiding the Development ofContext-Enabled Applications. Proceedings of CHI99,ACM Press.

[26] Eric Tanter. Contextual Values. Dynamic LanguagesSymposium 2008) (DLS08), co-located with ECOOP2008. Proceedings, ACM Digital Library.

[27] Jorge Vallejos, Peter Ebraert, Brecht Desmet, Tomvan Cutsem, Stijn Mostinckx, Pascal Costanza. TheContext-Dependent Role Model. Proceedings of the 7thIFIP International Conference on DistributedApplications and Interoperable Systems (DAIS 2007).

Springer LNCS.[28] Volker Wulf, Bjorn Golombek. ExplorationEnvironments: Concept and Empirical Evaluation.Proceedings of GROUP 2001, ACM 2001 InternationalConference on Supporting Group Work. Boulder,Colorado, USA, 2001. ACM Press.

Contextl Soa

Documents

Transcript of Contextl Soa