| .NET: THE PROGRAMER'S PERSPECTIVE: ECOOP
WORKSHOP 2003 |
|
|
Support for Metadata-driven Selection of
Run-time Services in .NET is Promising but Immature
Frank Piessens, Bart
Jacobs, Eddy Truyen, and
Wouter Joosen, Department of Computer Science,
K.U.Leuven, Belgium
|
 |
PDF Version
|
Abstract
The .NET Framework allows developers to add run-time services to their
classes by specifying them in metadata. This metadata-driven service
selection is a very powerful and promising mechanism, closely related
to ideas developed in the Aspect-Oriented Programming community. Interestingly,
the .NET framework supports both services implemented by weaving and
services implemented by interception. However, the weaving-based and
the interception-based mechanisms seem to have been introduced in the
framework independently, and show some unnecessary differences in flexibility,
extensibility and configurability. Also both mechanisms still contain
some anomalies in their design. In this paper, we describe the mechanisms,
and discuss these shortcomings.
1 INTRODUCTION
The Microsoft .NET Framework improves on existing component systems,
such as Java and J2EE, COM and COM+, and CORBA, in a number of ways.
It combines many good features of each of these predecessors, while
also including some innovations, such as:
- Components are named using precise yet friendly names.
Names include version and culture, which provides bind-time flexibility.
Namespace ownership is cryptographically enforced.
- Arbitrary metadata can be added to components and elements
within components, for use at compile-time (both source compile-time
and JIT compile-time),
at link-time, or at run-time. At source compile-time, metadata
labeling methods with the exceptions they can throw can be used by
the compiler
to perform similar checks as a Java compiler does for checked exceptions.
Some types of metadata trigger the execution of services directly
by the framework and the service code (call) is inserted at JIT compile-time.
Other types of metadata trigger link-time checks, for instance
a security
check whether a component is permitted to link to a given method.
Most types of metadata can be retrieved at run time by user code
or by the
framework for various purposes, such as determining the serializability
of a class.
- Better support for independent extensibility: when a developer
introduces a late-bound method in a class, they need to explicitly
state whether
they intend to override a base class method or not. If a method
is later added to the base class, it cannot inadvertently be overridden
by an existing method in the derived class.
- From a security perspective, making highly privileged components
globally available on a machine does not automatically imply an increased
attack
surface, since partially trusted clients only have access to those
components that have explicitly been marked as safe for such access
by the developer.
All these features together provide for much improved support for
component-based development [Szyperski 2002].
In this paper, we focus
on how the .NET framework uses metadata to support the activation
of various run-time services, such as access
control, synchronization, transactions and so forth. The .NET framework
is the first commercial product to provide an extensible system for
defining metadata-driven run-time services. The authors feel that
this approach is very promising, but the current implementation in
.NET
still has some conceptual and technical shortcomings.
2 METADATA-DRIVEN
SELECTION OF RUN-TIME SERVICES
Developers add metadata to types, members
and other elements by annotating them with so-called attribute specifications.
An attribute specification
consists of a type name which names an attribute class, plus
an argument list consisting of literal expressions. The type name and
the literal
values are stored in the assembly by the programming language
compiler.
At run-time, this information is used by the CLR to create
an instance of the named attribute class. The CLR and the application
itself
can retrieve the instances associated with an element, look
for specific types of instances, and act upon them.
A fairly large number
of attribute classes are predefined in the .NET class library. These
predefined attributes are used
in a variety
of
ways in the CLR, e.g. to indicate if classes are serializable,
or to drive optimizations. One particular use of attributes
that concerns
us in this paper is the triggering of run-time services in
the CLR. Developers can decorate their components with such
attributes
to
indicate
to the runtime that certain cross-cutting services (such
as access control or synchronization) should be activated at run-time.
We
discuss two examples of attributes that request run-time services:
security attributes and context attributes.
Security attributes
Security attributes derive from SecurityAttribute;
they instruct the CLR to perform named security actions when the
element is accessed [LaMacchia 2002]. For example: 
For security attributes, the CLR provides the required service by
adding extra code when a method is compiled to native code, i.e. essentially
by a simple form of run-time code weaving. The added code performs
the requested security actions. Code weaving can be applied to static
methods as well as instance methods and is a fairly efficient mechanism.
Context
attributes
Context attributes [Lowy 2003] are attribute classes that
derive from ContextAttribute. They should
be applied to a class which derives
from
ContextBoundObject. Context-bound objects
live in a so-called context, that is determined by a number of
context properties. These properties
essentially say what run-time services the context provides. On
instantiation of a context-bound object, the runtime inspects the metadata,
and
decides in which context the object should be instantiated. If
no suitable
context is available, a new context providing exactly the required
services is created.
Messages to context-bound objects sent from
outside the object's context are intercepted and reified, and
can then be manipulated
by a number
of message sinks. These sinks can do pre-processing, post-processing,
collect state, manipulate the message and so forth, to provide
a certain run-time service.
The mechanism of contexts is extensible
by developers: new context attributes can be defined. Such a newly
defined attribute can
contribute new properties to a context, and can add a new message
sink to
the context-bound object's interception chain.
The .NET Framework
currently includes a single predefined context attribute class, called
SynchronizationAttribute. However,
it is expected that
some or all of the run-time services that are now provided
through COM+ will be made available in the form of context
attributes
in a future version of the framework.
An example of the use
of a context attribute, SynchronizationAttribute, is as follows:
Essentially, the mechanism of context-bound objects is a generalization
of the idea of container-provided cross-cutting services, as was present
already (in a non-extensible way) in COM+, J2EE and CORBA.
This interception-based
approach of adding run-time services is more expressive, but less efficient
compared to the weaving-based approach.
3 DISCUSSION
The idea of using metadata to drive activation of run-time
services is very promising (and in fact has been suggested in the research
community
before the release of .NET). Metadata-driven selection of services
can be considered to be a kind of aspect-oriented programming [Kiczales
1997, Shukla 2003]: the pointcut is determined by the metadata on the
static program elements (components, classes and methods), whereas
the advice is either the code that is woven in, or the code that is
executed by the message sinks.
The current implementation in the CLR
however, has some drawbacks. In this section, we will discuss these
drawbacks and suggest some improvements.
Ad-hoc and separated definitions
of the two mechanisms
It is clear that certain run-time services could
be supported both by weaving and by interception. In the current CLR
for example, the
PrincipalPermissionAttribute can be used to do role-based access control
implemented by weaving, and the SecurityRoleAttribute can be used to
do role-based access control implemented by interception.
However, it
seems as if both mechanisms have found their way into the CLR independently:
the weaving-resolved attributes seem to have been
introduced to deal with mobile code security and the context attributes
are a generalization of contextual composition in COM+. As a consequence,
the conceptual similarities between the two approaches are not brought
out clearly at the level of, for instance, the attribute classes. This
is unfortunate. We see two opportunities for improvement:
- Conceptually similar design for both mechanisms.
Since weaving-based
and interception-based implementations each have their own advantages
and disadvantages, it is clear that both techniques
should remain present in the CLR. However, by more clearly showing
the conceptual similarity, one could make it easier to switch between
the two types of implementation for a given run-time service.
Since the choice between weaving and interception is often a trade-off
between flexibility and efficiency, such switching could be used in
optimizations.
- Flexible weaving mechanism.
The interception-based mechanism has been designed to be developer-extensible.
Developers can define new context attributes that specify new message
sinks to be incorporated in the interception chain.
The weaving-based mechanism is not extensible at all: the CLR recognizes
a fixed number of predefined attributes, and there is no way for
developers to define new such attributes and specify what code
should be woven.
It would be interesting, certainly from a research point of view,
to have a runtime where both mechanisms are extensible.
Limited expressive
power
The CLR only supports the addition of attributes to the declaration
of static program structures (assemblies, classes, methods, ...), and
not to dynamic structures (e.g. interactions, objects). As a consequence,
what services are provided for a specific object is fixed at instantiation
time of the object, and no client-specific customizations are supported.
The
CLR does contain the necessary low-level concepts to support such client-specific
customizations: the LogicalCallContext class is a collection
object that carries information about the current logical thread of
execution, even across remoting calls. It could be used to carry metadata
about the current interaction.
The Lasagne customization model [Truyen
2001] takes this idea to its extreme. Instead of allowing attribute
specifications scattered across
the program code, Lasagne proposes to externalize all such specifications
in a separate first class entity, called a composition policy object,
that automatically propagates with the logical control flow of subsequent
interactions. As such, service selection logic travels as metadata
with the locus of execution, rather then being locked up and scattered
across the code of the program. In this approach programmer-driven
selection of services can still be supported since the composition
policy object can be inspected and manipulated at any execution point.
Example
The delivery of non-repudiation evidence of the result of a
method call can be programmed as a server-side message sink (that signs
incoming
parameters, result, and any other information as required, for example).
A client-side message sink can then verify this and save it for later
use.
For this example, it is definitely useful that the client chooses
whether this service is activated for a specific method call.
Unclear composition
model for run-time services
While the CLR supports extensible interception
chains providing an arbitrary number of services, it is not clear how
to deal with services
that are not completely orthogonal. For such services, developers should
be able to specify at least the ordering of the interceptors, and possibly
also interfaces between dependent services. There is no support for
this available in the framework.
Adding support to specify dependencies
between services to determine the ordering of message sinks, and enabling
some form of communication
between dependent sinks is relatively straightforward in the current
model. Also, some limited support to detect conflicting services is
built in: after a new context has been created, each service is queried
whether the resulting context is ok or not. If one of the installed
services answers negatively, an exception is thrown.
However, since
general composition of aspects is itself still an active research topic,
there are no simple general solutions to be expected.
The issues surrounding
composition of services are discussed by Szyperski in [Szyperski 2002].
He gives the example of composing a logging service
and an encryption service; he notes that the effect of the composition
depends on the order in which these services are composed, and that
for some applications a cooperation between these services is required
that is more specialized than a simple execution of one service after
the other.
Limited support for configuration of run-time services by
administrators
Selecting run-time services by decorating static program
structures with attributes provides developers with a powerful mechanism
to choose
appropriate services. However, for some services (for instance, access
control), the deployer and administrator of an application should also
have their say, for instance by means of a configuration mechanism.
For COM+ services, both metadata-driven and configuration data-driven
selection of services is possible already. For context-bound objects
in the CLR, support for configuration of services is possible by means
of dynamic context properties (but the current CLR does not yet seem
to provide tool support for this).
For the weaving-resolved attributes
however, only development-time metadata is taken into account. As a
consequence, if the developer
did not add any security attributes to the code, there is currently
no easy way for a deployer/administrator to add them. Of course, enabling
administrators to add arbitrary run-time services through configuration
also carries some risks: in an extensible system, services can add
arbitrary code and hence the semantics of a component could change
radically through reconfiguration. This is clearly undesirable.
A possible
solution could force developers of run-time services (e.g. developers
of context attributes) to indicate if the service could
be selected through metadata, through configuration or both.
Low-level
programming model
Programming services as message sinks is not the most
developer-friendly programming model. Moreover, there is little type-checking
on composition
of sinks. Programming a service as a decorator of a class solves these
two problems, and such a decorator could be compiled to a message sink.
However, in such a model, services are less polymorphic in the sense
that they cannot easily be applied to many classes. The challenge here
is to design a programming model that combines the ease-of-use and
type-safety of decorators, with the polymorhphy of message sinks.
For
example, the CAESAR [Mezini 2003] programming model is a step towards
resolving this challenge. It proposes the notion of collaboration interface
[Mezini 2002] as a higher-level module concept on top of aspect-oriented
join point interception. A collaboration interface allows to separate
the implementation of an aspect - specified in an aspect implementation,
from how to connect that implementation with a particular application,
which is specified in an aspect binding. Aspect implementation and
aspect binding are indirectly connected to each other since they implement
two loosely coupled facets of the collaboration interface. This loose
coupling is the key to polymorphic reuse of implementations and bindings.
Since collaboration interfaces are typed, the type-safety of decorators
is provided while the loose coupling between implementation and binding
provides the polymorphy of message sinks. An interesting application
of this programming model in the context of metadata-driven selection
of services is to split message sinks as well in an implementation
part and a binding part and have the binding part automatically be
generated from the programmer-specified metadata.
4 CONCLUSION
The support for metadata-driven service selection is
powerful and promising. In the research community, it has long been
recognized that weaving
and interception are two powerful techniques to compose cross-cutting
services with an application. The .NET framework supports both techniques,
but in a very asymmetric way: the weaving-based approach is tuned to
support only a small number of built-in services, whereas the interception-based
approach is designed to be easily extensible. Also, both approaches
still allow for improvements in configurability, usability, and composability
of provided services.
REFERENCES
[Kiczales97] G. Kiczales, J. Irwin, J. Lamping, J.-M. Loingtier,
C. V. Lopes, C. Maeda, and A. Menhdhekar. “Aspect-oriented programming”.
In M. Aksit and S. Matsuoka, editors, ECOOP ’97 — Object-Oriented
Programming 11th European Conference, Jyväskylä, Finland,
volume 1241, pages 220–242. Springer-Verlag, New York, NY, 1997.
[LaMacchia02]
B. LaMacchia, S. Lange, M. Lyons, R. Martin, and K. Price. .NET
Framework Security. Addison Wesley, 2002.
[Lowy03] J. Lowy. “Contexts in
.NET: Decouple components by injecting custom services into your object’s
interception chain”.
MSDN Magazine, March, 2003.
[Mezini02] M. Mezini and K. Ostermann. “Integrating
independent components with on-demand remodularization”. In Proceedings
of the 17th ACM conference on Object-oriented programming, systems,
languages,
and applications (OOPSLA-02), volume 37(11) of ACM SIGPLAN Notices,
pages 52–67. ACM Press, Nov. 4–8 2002.
[Mezini03] M. Mezini
and K. Ostermann. “Conquering aspects with
CAESAR”. In Proceedings of the 2nd International Conference
on Aspect-Oriented Software Development (AOSD), pages 90–100. ACM
Press, March 17-21 2003.
[Shukla03] D. Shukla, S. Fell, and C. Sells. “Aspect-oriented
programming enables better code encapsulation and reuse”. MSDN
Magazine, March, 2003.
[Szyperski02] C. Szyperski, D. Gruntz, and S.
Murer. Component Software: Beyond Object-Oriented Programming, 2nd
Ed. Pearson Education, 2002.
[Truyen01] E. Truyen, B. Vanhaute, W. Joosen,
P. Verbaeten, and B. N. Jørgensen. “Dynamic and selective
combination of extensions in component-based applications”. In
Proceedings of the 23rd International Conference on Software Engineering
(ICSE’01), pages
233–242. IEEE Computer Society, May 12–19 2001.
About the
authors
Frank Piessens is a professor at the Department of Computer
Science of the Katholieke Universiteit Leuven in Belgium. His research
interests
are in security aspects of software, including security in middleware
and operating systems, security architectures, formal methods for
security, Java and .NET security, and software interfaces to security
technology.
He can be reached at frank.piessens@cs.kuleuven.ac.be.
Bart Jacobs is a PhD student at the same Department. His research
interests are in formal methods for security, including type systems,
calculi, automated and semi-automated reasoning, programming language
semantics, and secure platforms. He can be reached at bart.jacobs@cs.kuleuven.ac.be.
Eddy Truyen is a PhD student at the same Department. His research
interests are in language technology and middleware, with a focus on
client-specific and dynamic customization of distributed systems. He
can be reached at eddy.truyen@cs.kuleuven.ac.be.
Wouter Joosen is a professor at the same Department. He is a co-founder
and director of Ubizen N.V. and Luciad N.V., two spin-offs of the Department.
Wouter's research interests are distributed systems and network applications,
with a focus on software security, agent-based systems, real-time systems
and development environments. Wouter Joosen is also an Adjunct Professor
for Software Engineering at the University of Odense, Denmark. He can
be reached at wouter.joosen@cs.kuleuven.ac.be.
Cite this article as follows: Frank Piessens et al.: “Support
for Metadata-driven Selection of Run-time Services in .NET is Promising
but Immature”, in Journal of Object Technology, vol.
3, no. 2, Special issue: .NET: The Programmer’s Perspective:
ECOOP Workshop 2003, pp. 27-35. http://ww.jot.fm/issues/issue_2004_02/article3
|
