SCALABLE EVOLUTION OF HIGHLY AVAILABLE SYSTEMS

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: • 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.