1. SCALABLE EVOLUTION OF HIGHLY AVAILABLE SYSTEMS BY ABHISHEK ASOKAN 8/6/2004

2. INTRODUCTION Global economy – software systems for business-critical applications. Expecting a 99.99% uptime. Improved implementations are developed. Is not feasible to consume time for maintenance. Demand for systems that provide support for dynamic adaptation, enabling systems to accommodate evolving system requirements, environmental conditions and fault scenarios without disrupting the services. Options: Statically deployed vs Dynamically deployed.

3. Statically deployed – portions of the design that are likely to change are encapsulated behind modules that abstract over the possible variations. Downside:Accurate prediction is not possible. Programming for changes is not easy Dynamically deployed- enables dynamic deployment of software modifications without the software having been designed to support them. Desiderata=> *Should adapt to cross cutting concerns. * Scalability * Support for compositional reuse * Accessibility to practitioners

4. SOFTWARE MEDIATION Def: Transparent interposition of code between the interface of a functional unit and the functional unit’s implementation. Two Techniques: 1.Wrapper-Based Mediation: *Development of a new implementation of the interface. *The new implementation is a wrapper and maintains a reference to the original implementation. *The wrapper provides functionality by delegating calls on its interface to the referenced implementation. *Code interposition occurs within the wrapper.

5. 2. Interceptor-Based Mediation: * Interceptor – A functional unit that encapsulates the code interposed between an interface and an implementation. * Unlike wrappers, every interface implements an identical interface. * It captures invocation requests and responses. * Details about the client calls to a target are marshaled and passed to the appropriate interceptor(s). Similarly details about the completion of the call is passed to the appropriate interceptor(s). * Interceptors can be viewed as a meta level functional units that modify the behavior of the functional units to which they are applied.

6. DRSS – Dynamic Reconfiguration Subsystem. It is an open container architecture that enables runtime adaptation to unanticipated design concerns through interceptor based mediation. The DRSS design can be realized in any language that provide proper support for reflection, dynamic class loading and remote loading. Used a component container: A runtime environment designed to manage the execution of component instances and provides a set of common services to the instances it hosts. Depending on the services offered, components are imbued with roll back recovery, persistence, distributed transaction support etc.

7. DRSS – Platform Provides dynamic reconfiguration services to its hosted instances which includes the ability to add, replace and remove component implementations as well as to dynamically deploy cross-cutting modifications. Hosted instances are accessible to remote processes and become dynamically reconfigurable without additional programming effort. In the initialization process the DRSS platform has to register itself as one of the instances to be hosted. => Exposes interface of the DRSS platform to remote processes. => Extends the reconfiguration services offered by the platform to the platform.

8. DRSS CALL MODEL Indirection and marshaling are achieved by dynamically generated components called proxies and skeletons.

9. Skeleton: * Generated at the point of target registration and maintains a reference to the newly generated target. * Upon receiving a invocation request, the request is unmarshaled and performs the corresponding target invocation, a marshaled invocation response is then transmitted back to a proxy. Proxy: *Generated at the point a client requests a reference to a registered target, DRSS platform returns a reference to a newly generated proxy. Requests and responses are actually transmitted by means of the DRSS interception subsystem which serves as a conduit between proxies and skeletons. Module substitution: * Achieved by temporarily blocking invocation requests to an existing target’s skeleton, and setting the existing target’s reference to a new target instance. * If the component being replaced is stateful then the abstract state of the old target may need to be transferred to the new target.

10. Interception: Envelope interceptors provide a method that accepts an envelope as argument and provides additional behavior in the path of one or more component collaborations. Interceptors associated with a particular skeleton modify the behavior of the target methods, regardless of which client performs the invocations. Interceptors associated with a proxy modify the behavior of the target methods only when the methods are invoked through that particular proxy. Envelope interceptors are differentiated as being either send-type or receive-type. Send-type interceptors are invoked immediately after an envelope is passed from a proxy or a skeleton to the interception subsystem for delivery. Receive-type interceptors are invoked immediately before an envelope is delivered by the interception subsystem to a proxy or a skeleton.

11. Interceptor chain: It is an ordered sequence of interceptors that implements the standard interceptor interface.

12. Interceptor Communication: Collaboration of send type and receive type interceptors. Eg: In a distributed environment send type might need to transmit a public key for authentication. DRSS provides a stack of content within each envelope to accommodate this. Also provides basic protection against unexpected content mismatches due to incompatible send-type and receive-type chains. Content Signature – Concatenation of content declarations of its constituent interceptors. An envelope processed by the send-type is marked with the corresponding content signature. In the event of a mismatch the interception subsystem places the envelope in a mismatch queue and checks whenever that chain is reconfigured.

13. Applications: Mediation can be used to extend the functionality of existing software systems. Used to transparently provide the benefits of distribution at the operating system and file system levels as well as to provide transparent file versioning control. In software assurance, used in container architectures to provide invariant-based state monitoring Used to provide fault tolerance in middleware through component replication. Aladdin project: aims at providing dependable and extensible support to heterogeneous, unreliable devices in unreliable home networks.