Publication

Nowadays, we rely on computers to transfer money, control air traffic and even process emergency calls. Systems in charge of such important tasks are expected to be be flawless and failsafe. However, they are neither. Runtime evolution has emerged as a solution to correct software immediately. Existing frameworks address this issues only partially, provide limited functionality or modify the underlying software layers (e.g. the virtual machine). In contrast, we approach runtime evolution at language level (in Java) to guarantee platform independence. We use components as entities to evolve. Our goal is to provide maximum genericness and flexibility. To realize this, we use the Jadabs container. It allows to dynamically load any JAR file as a component. Need for runtime evolution may arise unanticipated for the evolving component itself and its clients. Thus, it should be transparent to the latter and not impose any requirements on the former. We create proxy objects based on the java class loading mechanism. They hide objects from being accessed outside the component they belong to. On method invocations, return values (and arguments, too) are wrapped and unwrapped on the fly if they (arguments: do not) belong to the same component as the callee. Mission critical system that cannot afford any downtime benefit most of runtime evolution. Safe-points are designed to support evolution of active components. They crosscut control flow at points that are suitable to migrate state. Implemented as dynamic aspects, safe-points may be defined and woven in at runtime. To remain available during migration, strategies to handle service requests may be defined and deployed (e.g. buffering or executing old version code). As implementation of a future component release is unknown to its clients, adaptation from the proxy to the upcoming component version must be done at runtime. We support for any kind of code evolution including interface modifications to let components evolve independently. Adapters specify how to map invocations to the new implementation. In addition, they customize when and how to perform an upgrade, and which state to migrate. To separate migration concerns from business logic, proxy as well as adapter components are introduced. While proxies are generated and remain stable, adapters are provided along with the new component version. Due to double indirection, method invocations are subject to a slow down in comparison to ordinary execution. This applies for invocations across component boundaries only. Thus, usage is most advantageous for complex operations as provided by mission critical components mentioned above. They may be transparently supplanted by their successors at runtime. Neither state nor availability is lost. No anticipation from the developer is needed do enable runtime evolution of its component. As type safety is maintained and our framework runs on any Java virtual machine, usage is not restricted to special infrastructure either.

@mastersthesis{abc,
	abstract = {Nowadays, we rely on computers to transfer money, control air traffic and even
process emergency calls. Systems in charge of such important tasks are expected
to be be flawless and failsafe. However, they are neither. Runtime evolution
has emerged as a solution to correct software immediately.
Existing frameworks address this issues only partially, provide limited functionality
or modify the underlying software layers (e.g. the virtual machine). In
contrast, we approach runtime evolution at language level (in Java) to guarantee
platform independence. We use components as entities to evolve. Our goal
is to provide maximum genericness and flexibility. To realize this, we use the
Jadabs container. It allows to dynamically load any JAR file as a component.
Need for runtime evolution may arise unanticipated for the evolving component
itself and its clients. Thus, it should be transparent to the latter and
not impose any requirements on the former. We create proxy objects based on
the java class loading mechanism. They hide objects from being accessed outside
the component they belong to. On method invocations, return values (and
arguments, too) are wrapped and unwrapped on the fly if they (arguments: do
not) belong to the same component as the callee.
Mission critical system that cannot afford any downtime benefit most of
runtime evolution. Safe-points are designed to support evolution of active components.
They crosscut control flow at points that are suitable to migrate state.
Implemented as dynamic aspects, safe-points may be defined and woven in at
runtime. To remain available during migration, strategies to handle service
requests may be defined and deployed (e.g. buffering or executing old version
code). As implementation of a future component release is unknown to its clients,
adaptation from the proxy to the upcoming component version must be
done at runtime. We support for any kind of code evolution including interface
modifications to let components evolve independently. Adapters specify how
to map invocations to the new implementation. In addition, they customize
when and how to perform an upgrade, and which state to migrate. To separate
migration concerns from business logic, proxy as well as adapter components
are introduced. While proxies are generated and remain stable, adapters are
provided along with the new component version.
Due to double indirection, method invocations are subject to a slow down
in comparison to ordinary execution. This applies for invocations across component
boundaries only. Thus, usage is most advantageous for complex operations
as provided by mission critical components mentioned above. They
may be transparently supplanted by their successors at runtime. Neither state
nor availability is lost. No anticipation from the developer is needed do enable
runtime evolution of its component. As type safety is maintained and our
framework runs on any Java virtual machine, usage is not restricted to special
infrastructure either.},
	author = {Micha Trautweiler},
	school = {ETH Z{\"u}rich},
	title = {Transparent Runtime Evolution of Components},
	year = {2004}
}