Reliability and availability are very important trends
in the development process of distributed systems. In order
to improve these features, object replication mechanisms
have been introduced. Programming replication policies
for a given application is not an easy task, and this is the
reason why transparency for the programmer has been one
of the most important properties offered by all replication
models. However, this transparency for the programmer is
not always desirable. In this paper we present a replication
model, JReplica, based on Aspect Oriented Programming
(AOP). JReplica allows the separated specification of the
replication code from the functional behaviour of objects,
providing not only a high degree of transparency, as done
by previous models, but also the possibility for
programmers to introduce new behaviour to specify
different fault tolerance requirements. Moreover, the
replication aspect has been introduced at design time, and
in this way, UML has been extended in order to consider
replication issues separately when designing fault tolerance
systems.Comisión Interministerial de Ciencia y Tecnología TIC99-1083-C02-0

Herrero, José Luis

Sánchez, Fernando

Toro Bonilla, Miguel

English

idUS. Depósito de Investigación Universidad de Sevilla

Fault Tolerance as an aspect using JReplicaJosé Luis Herrero1, Fernando Sánchez1, Miguel Toro2 1 Computer Science DepartmentUniversity of Extremadura.Spain{jherrero, fernando}@unex.es2 Computer Science DepartmentUniversity of Sevilla.Spainmtoro@lsi.us.esAbstractReliability and availability are very important trends in the development process of distributed systems. In order to improve these features, object replication mechanisms have been introduced. Programming replication policies for a given application is not an easy task, and this is the reason why transparency for the programmer has been one of the most important properties offered by all replication models. However, this transparency for the programmer is not always desirable. In this paper we present a replication model, JReplica, based on Aspect Oriented Programming (AOP). JReplica allows the separated specification of the replication code from the functional behaviour of objects, providing not only a high degree of transparency, as done by previous models, but also the possibility for programmers to introduce new behaviour to specify different fault tolerance requirements. Moreover, the replication aspect has been introduced at design time, and in this way, UML has been extended in order to consider replication issues separately when designing fault tolerance systems.1: IntroductionThis work tries to introduce replication in object orientation by means of a new aspect. For this purpose, a new language called JReplica has been developed. This language captures the relevant aspects of replication, and This work has been developed with the support of CICYT  under contract TIC99-1083-C02-02encapsulates them into a component or group of relatedcomponents favouring the reusability and dynamicadaptability of replication policies. This language alsofavours the use and reuse of replication policiesindependently from the middleware used to communicateobjects (currently several implementations of CORBA andRMI).The work is not limited to the definition of this newlanguage. AOP ideas have been translated to the designlevel. In this way, the semantic of UML has been extendedin order to represent replication properties. From a givendesign, the same for whatever middleware, a visual tool isable to generate code.The rest of the paper is as follows: section 2 explainsthe different approaches to introduce replication in objectorientation. Our proposal is introduced in section 3. Section4 shows related works. Finally, future works are outlined insection 5.2: Fault tolerance approachesThere are several different approaches to introducefault tolerance in object oriented systems. They can becategorised in the following way:1. Integration approach: In this approach, replication isintegrated inside the model. Replication is coded insidethe ORB so each ORB must be modified in order toprovide fault tolerance. Electra [1], Orbix+Isis [2] aretwo models that are based on this approach (figure 1).Client S S’ReplicationORBCom Figure 1. Integration approach2. Interception approach: In this model, every messageis intercepted and redirected to a replication toolkit.This new tool is in charge of providing fault tolerance.The ORB must be modified introducing theinterception mechanism. Eternal [3] is an example ofthis approach (figure 2).ReplicationInterceptionClient S S’ORBComFigure 2. Interception Approach3. Service approach: A new replication service is addedto the ORB. This service provides mechanisms forobject replication. OGS [4] and the new Corba FaultTolerance specification [5] are based on this approach(figure 3).Client S S’ReplicationORBComFigure 3. Service ApproachAll these models introduce new elements to providefault tolerance through replication. Transparency is themost important property achieved. In this way,programmers do not have to take care about replication, andthey do not need to define any protocol to develop faulttolerance applications because replication is obtainedautomatically by the model. However, all these modelshave two main drawbacks in the following sense:• Close: A totally transparent system doesn’t allowprogrammers to change replication mechanisms.Replication properties can not be established, such asthe replication granularity, or the moment whenreplication protocols must be executed. Theseproperties are defined automatically by the model andthey are the same for every system. In this way,programmers can not take advantage from systemrequirements.• ORB dependent: Replication depends on the ORBimplementation. Any replication policy must be codedinto an individual ORB, and it can not be reused in adifferent ORB. There’s no way to port the samereplication policy to other ORBs.Although transparency is a good property to beachieved, it is not always necessary, moreover, sometimesit is not desirable. Sometimes the nature of the problemmay require establishing the replication properties andbehaviour by the programmer. Even more, if requirementsguide the replication behaviour, the system could takeadvantage of them, and system performance could beincreased. If the replication model is totally transparent,there is no way to define fault tolerance applicationsaccording with system requirements.3: ProposalThe model here proposed is based on the paradigm ofAspect Oriented Programming (AOP). Our research grouphas gained experience with AOP during the last few yearsworking with the synchronization, coordination anddistribution aspects [6, 7]. Here we go one step furtherintroducing the replication aspect as a new non-functionalproperty of the object. With this, separation transparency isgranted because replication policies can be reused amongapplications with no changes. In addition, programmers canget control over the replication policy using the specificreplication language provided: JReplica.3.1: FrameworkThe proposed model keeps aspects separated from thefunctional code of the object. A reflexive architecture isused in order to introduce two different levels of execution:• Functional Level: Object functionality is defined atthis level. Two new entities (in, out) have beenattached to each object in order to communicate objectswith its aspects.• Aspect Level: Aspects are defined at this level. Eachobject can be associated with one or more aspects.The model is show in the figure 4.OutInAspect 1Aspect 2InputMessagesOutputmessagesObjectFigure 4. The aspect modelEach object is composed of three different entities:• In: This entity intercepts all the input messages andredirects them to the aspect level.• Functional Object: This is the place where the basicbehaviour of the object is implemented.• Out: This entity intercepts all the output messages andtransforms them into the right middleware (CORBA orJavaRMI).3.2: Replication AspectAccording to figure 4, this work tries to focus on thereplication aspect (figure 5). Passive replication is thereplication technique that has been considered. Althoughthere are other different replication techniques such asactive replication, passive replication allows replicatingdeterministic and non-deterministic objects, while activecan not.OutInReplicationAspectInputMessagesOutputmessagesObjectFigure 5. The Replication AspectUnder this previous consideration, the replicationaspect must perform the following tasks:• Decide when to activate the replicationmechanisms: It’s very important to define when tosend replication messages because they will affect theperformance of the whole system. If these messagesare sent very often, the system will collapse. While ifnot, copies can be inconsistent for a long time. Thereare two different ways to establish this activation:• Direct: replication is activated just after a methodof the object has been executed.• Indirect: replication is activated depending on thevalue of some conditions that must be checkedperiodically.• State Update: When the replication mechanisms areactivated, the replication aspect captures the state ofthe object and sends it to every copy. In order not tobreak object encapsulation, get and set methods arecalled to obtain and modify the state.• Fault Checking: In order to test faults, a pin protocolis developed. This protocol ensures that if a faulthappens, each copy will be notified.• Recovery: When a fault is found, another protocol willselect one of the replicas to take the control.Figure 6 shows a representation of a fault tolerancesystem using this aspect model.ObjectCopy 1Copy 2StateStateGet StateSet StateSet StateReplicationAspectReplicationAspectReplicationAspectFigure 6. Aspect system exampleThe main advantages of this model are the followings:• Those benefits derived from the use of AOP, mainlymodularity, reusability of code and adaptability ofapplications.• ORB Independence: Replication algorithms areindependent from de ORB. In a previous work [7]different distribution protocols were defined as aseparated aspect providing a dynamic, adaptable andtransparent object distribution. Now, as the replicationmodule is defined outside the ORB, the combination ofdistribution and replication aspects offer the possibilityof reusing the same replication policy in differentORBs.• Open: Thought replication algorithms are hidden andseparated from object behaviour, replication propertiesand behaviour can be defined. Reflective mechanismscan communicate the object level with the replicationlevel. This communication provides the way tointroduce new replication actions.3.3: JReplica: Java Fault Tolerance LanguageJReplica is a language with the only purpose ofdefining replication policies. Its syntax is based on Java. Itintroduces new primitives, which are shown in figure 7.This Java extension introduces two main elements:1. Replication Policy: A new entity called DisguiseReplication defines the replication aspect. This entityis divided into the following parts:• Attributes: the information that defines thereplication policy.• State: the set of replication states.• Operations: methods that can manipulate thereplication state.• Guard: a condition that must be true beforereplication. If this condition is false, replicationwon’t be executed.• Before Replication:  the set of actions that must beexecuted just before replication.• After Replication: the set of actions that must beexecuted just after the replication is executed.• Error: the set of actions that must be executed whena replication error appears.2. Composition: A class can be composed with differentaspects. In our case, this means that every object willextend its functionality with replication mechanisms.3.4: Representing Replication at Design LevelReplication policies now can be defined with theJReplica language. This language helps programmers todefine easily replication properties in object orientedsystems. But we consider that replication must beintroduced at earlier stages of object life cycle, moreconcretely at design level. In this way, UML [8] is used asthe modelling language due to it being a standard. As UMLdoes not provide mechanisms to represent replication, itssemantic has been extended in order to express replicationproperties and behaviour.Class  <name>{ ........}........................x=new C1Compose x with R;y=new Replica of x;........................Diguise Replication <name>{  Attributes: .....  Operations: .....  State:  .....  Guard: .....  Before Replication: ....  After Replication: .....  Error: .....}Figure 7.  JReplica replication primitivesUML semantic can be extended with the introductionof new stereotypes. At this point, we have considered thatreplication policies can be designed separately andindependently, in the same way as has been explained at theimplementation level. As such, the aspect concept isintroduced in UML to express the AOP philosophy. Thereplication aspect is represented with a new stereotype,called <Replication>. This new stereotype is shown infigure 8. The replication stereotype represents a particularreplication policy. Information is represented as follows:• Stereotype Attributes: Represent the information thatdefines the replication policy.• Stereotype Methods: Define the set of methods thatcan manipulate the replication state.< Replication >NameAttributesMethodsClassAttributesMethods<Replicated>Figure 8. UML extensionAs it can be shown, there are other elements that cannot be represented in this stereotype. The dynamicbehaviour of replication can not be represented in a normalclass diagram. Statechart diagrams represent dynamicbehaviour. So the solution goes by attaching a statechartdiagram to this replication stereotype. In this way,replication static properties and dynamic behaviour can bedesigned. The dynamic behaviour of replication policiescan be represented in a statechart diagram as it is shown infigure 9.State 1 Replication[Replication Guard]Entry : Actions before replicationExit : Actions after replicationFigure 9. Statechart RepresentationThe elements that are represented in this statechartdiagram are:• State: Each replication state is represented by an state.There is a special state called Replication thatrepresents the moment when replication is to beexecuted.• Guard: Guards are represented in the transition ofeach state.• Before Replication:  The set of actions that is executedjust before the replication begins is represented in theentry actions of the Replication state.• After Replication: The set of actions that are executedjust after the replication ends are represented in the exitactions of the Replication state.• Error: Replication errors are represented as a newstate.A tool is being developed in order to generate JReplicacode starting from this extension of UML. In this wayReplication aspect has been introduced from design toimplementation level. This tool is based on other one wehave developed for the synchronisation aspect [9].4: Related worksThere are several models that provide replicationmechanism to achieve fault tolerance. In [10], a newinterception mechanism called Aroma is introduced in theJava RMI architecture. Other models are based on theintroduction of separated entities that implement replicationprotocols. The Cadmium Model [11] defines a couple ofnew entities called Stub and Scion, which are attached to aclient and a server respectively and offer replicationmechanisms. In [12] a new replication entity and aconsistency manager are introduced, both separated fromthe object. In AspectIX [13] a single object is divided intofragments, all of which have a different purpose. One ofthese fragments offers replication facilities. The GARF [14]model defines two different entities in order to introducereplication, they are called encapsulator and mailer. A twolevel reflective architecture was defined for Java in [15];object functionality is defined in the first level, whilereplication protocols are established in the second one. Allthese models only take into account the implementationlevel, they are focused on replication protocols and thedefinition of a framework that provides fault tolerance,ignoring the design phase.A new pattern [16] has been defined in order toprovide support for the representation of replicated objects.Moreover, a new language that helps programmers to buildfault tolerance systems has been defined in [17, 18]. Thisproposal is based on the concept of separation of concernsand extends AspecJ language [19] with replicationprimitives. It is possible to define the attributes that needreplication and what to do when a replication error happens.But there is no way to express new replication actions orwhen replication must be executed. Although these modelshelp programmers to implement fault tolerance systems, itis necessary to introduce mechanisms that help softwareengineers to design this kind of requirements.5: Future worksFuture works will consider extensions to JReplica inorder to express more complex replication mechanisms.The current version showed us the suitability of the model.References[1] S.Maffeis. Run-Time support for object-oriented distributedprogramming. Phd Thesis, University of Zurich, 1995.[2] IONA and Isis. An Introduction to Orbix+Isis. IONATechnologies Ltd. and Isis Distributed Systems, Inc., 1994.[3] L.E.Moser, P.M. Meliar-Smith and P. Narasimhan. Consistentobject replication in the Eternal system. Theory and Practice ofObject Systems, 81-92, 1998.[4] Pascal Felber. The CORBA Object Group Sevice. A Serviceapproach to object groups in CORBA. Phd Thesis 1998.University of Lausanne.[5] OMG TC document ptc/2000-03-04. Fault Tolerant CORBA.Draf Adopted Specification. 2000.[6] J.M. Murillo, J. Hernández, F. Sánchez, L.A. Álvarez.Coordinated Roles: Promoting Reusability of Coordinated ActiveObjects Using Events Notification Protocols. In CoordinationLanguages and Models. Springer-Verlag, LNCS 1594, April,1999.[7] F. Sánchez, J.Hernández, J.M.Murillo, J.L.Herrero,R.Rodríguez. Adaptability of Object Distribution Protocols Usingthe Disguises Model Approach. 2nd Intl. Symposium, DistributedObjects & Applications (DOA 2000).[8] Object Management Group. Unified Modeling Language,version 1.3.[9] J.L.Herrero. Introducing separation of concerns at designtime. PhDOOS Workshop, European Conference on Object-Oriented Programming (ECOOP’2000).[10] N. Narasimhan, L.E. Moser and P. M. Melliar-Smith.Transparent Consistent Replication of Java RMI Objects.2nd Intl.Symposium, Distributed Objects & Applications (DOA 2000).[11] Aline Baggio. Adaptable and Mobile-Aware DistributedObjects. PhD Thesis, Université Pierre et Marie Curie and INRIA,Paris, France, June 1999.[12] Georges Brun-Cottan and Mesaac Makpangou.Adaptable Replicated Objects in Distributed Environments.BROADCAST TR No. 100. Appeared in the proceedings of the2nd BROADCAST Open Workshop, Grenoble, July 1995.[13] Martin Geier, Martin Steckermeier, Ulrich Becker,Franz J. Hauck, Erich Meier, Uwe Rastofer. Support for mobilitynd replication in the AspectIX architecture. Object-OrientedTechnology, ECOOP'98 Workshop Reader, LNCS 1543, Springer,1998; pp. 325-326.[14] B. Garbinato, R. Guerraoui, and K. R. Mazouni.Implementation of the GARF replicated object platform.Distributed Systems Engineering Journal, 2:14-27, 1995.[15] Jürgen Kleinöder, Michael Golm. Transparent and AdaptableObject Replication Using a Reflective Java. Tech. Report TR-I4-96-07, Universität Erlangen-Nürnberg: IMMD IV, Sept. 1996.[16] Teresa Gonçalves and António Rito Silva. Passive Replicator:A Design Pattern for Object Replication. Second EuropeanConference on Pattern Languages of Programs. July 1997.[17] Johan Fabry. Replication as an Aspect - The NamingProblem. ECOOP Workshops 1998: 424-425.[18] Johan Fabry. A Framework for replication of objects usingAspect-Oriented Programming. Phd Thesis 1998. University ofBrussel.[19] C.V. Lopes. D: A Language Framework for DistributedProgramming. Phd Thesis 1997. University of Northeastern.

Fault Tolerance as an aspect using JReplica

https://idus.us.es/bitstream/11441/65520/1/Fault%20Tolerance.pdf

Fault Tolerance as an aspect using JReplica

Abstract

Similar works

Full text

Available Versions

idUS. Depósito de Investigación Universidad de Sevilla