AOP: Does it Make Sense ? The Case of Concurrency and Failures

Concurrency and failures are fundamental problems in distributed computing. One likes to think that the mechanisms needed to address these problems can be separated from the rest of the distributed application: in modern words, these mechanisms could be aspectized. Does this however make sense? This paper relates an experience that conveys our initial and indeed biased intuition that the answer is in general no. Except for simple academic examples, it is hard and even potentially dangerous to separate concurrency control and failure management from the actual application. We point out the very facts that (1) an aspect-oriented language can, pretty much like a macro language, be beneficial for code factorization (but should be reserved to experienced programmers), and (2) concurrency and failures are particularly hard to aspectize because they are usually part of the phenomenon that objects should simulate. They are in this sense different than other concerns, like for instance tracing, which might be easier to aspectize

Exception handling in the development of fault-tolerant component-based systems

Orientador: Cecilia Mary Fischer RubiraTese (doutorado) - Universidade Estadual de Campinas, Instituto de ComputaçãoResumo: Mecanismos de tratamento de exceções foram concebidos com o intuito de facilitar o gerenciamento da complexidade de sistemas de software tolerantes a falhas. Eles promovem uma separação textual explícita entre o código normal e o código que lida com situações anormais, afim de dar suporte a construção de programas que são mais concisos fáceis de evoluir e confáveis. Diversas linguagens de programação modernas e a maioria dos modelos de componentes implementam mecanismos de tratamento de exceções. Apesar de seus muitos benefícios, tratamento de exceções pode ser a fonte de diversas falhas de projeto se usado de maneira indisciplinada. Estudos recentes mostram que desenvolvedores de sistemas de grande escala baseados em infra-estruturas de componentes têm hábitos, no tocante ao uso de tratamento de exceções, que tornam suas aplicações vulneráveis a falhas e difíceis de se manter. Componentes de software criam novos desafios com os quais mecanismos de tratamento de exceções tradicionais não lidam, o que aumenta a probabilidade de que problemas ocorram. Alguns exemplos são indisponibilidade de código fonte e incompatibilidades arquiteturais. Neste trabalho propomos duas técnicas complementares centradas em tratamento de exceções para a construção de sistemas tolerantes a falhas baseados em componentes. Ambas têm ênfase na estrutura do sistema como um meio para se reduzir o impacto de mecanismos de tolerância a falhas em sua complexidade total e o número de falhas de projeto decorrentes dessa complexidade. A primeira é uma abordagem para o projeto arquitetural dos mecanismos de recuperação de erros de um sistema. Ela trata do problema de verificar se uma arquitetura de software satisfaz certas propriedades relativas ao fluxo de exceções entre componentes arquiteturais, por exemplo, se todas as exceções lançadas no nível arquitetural são tratadas. A abordagem proposta lança de diversas ferramentas existentes para automatizar ao máximo esse processo. A segunda consiste em aplicar programação orientada a aspectos (AOP) afim de melhorar a modularização de código de tratamento de exceções. Conduzimos um estudo aprofundado com o objetivo de melhorar o entendimento geral sobre o efeitos de AOP no código de tratamento de exceções e identificar as situações onde seu uso é vantajoso e onde não éAbstract: Exception handling mechanisms were conceived as a means to help managing the complexity of fault-tolerant software. They promote an explicit textual separation between normal code and the code that deals with abnormal situations, in order to support the construction of programs that are more concise, evolvable, and reliable. Several mainstream programming languages and most of the existing component models implement exception handling mechanisms. In spite of its many bene?ts, exception handling can be a source of many design faults if used in an ad hoc fashion. Recent studies show that developers of large-scale software systems based on component infrastructures have habits concerning the use of exception handling that make applications vulnerable to faults and hard to maintain. Software components introduce new challenges which are not addressed by traditional exception handling mechanisms and increase the chances of problems occurring. Examples include unavailability of source code and architectural mismatches. In this work, we propose two complementary techniques centered on exception handling for the construction of fault-tolerant component-based systems. Both of them emphasize system structure as a means to reduce the impactof fault tolerance mechanisms on the overall complexity of a software system and the number of design faults that stem from complexity. The ?rst one is an approach for the architectural design of a system?s error handling capabilities. It addresses the problem of verifying whether a software architecture satis?es certain properties of interest pertaining the ?ow of exceptions between architectural components, e.g., if all the exceptions signaled at the architectural level are eventually handled. The proposed approach is based on a set of existing tools that automate this process as much as possible. The second one consists in applying aspect-oriented programming (AOP) to better modularize exception handling code. We have conducted a through study aimed at improving our understanding of the efects of AOP on exception handling code and identifying the situations where its use is advantageous and the ones where it is notDoutoradoDoutor em Ciência da Computaçã

An aspect-oriented framework for orthogonal persistence

The life cycle of software applications in general is very short and with extreme volatile requirements. Within these conditions programmers need development tools and techniques with an extreme level of productivity. We consider the code reuse as the most prominent approach to solve that problem. Our proposal uses the advantages provided by the Aspect-Oriented Programming in order to build a reusable framework capable to turn both programmer and application oblivious as far as data persistence is concerned, thus avoiding the need to write any line of code about that concern. Besides the benefits to productivity, the software quality increases. This paper describes the actual state of the art, identifying the main challenge to build a complete and reusable framework for Orthogonal Persistence in concurrent environments with support for transactions. The present work also includes a successfully developed prototype of that framework, capable of freeing the programmer of implementing any read or write data operations. This prototype is supported by an object oriented database and, in the future, will also use a relational database and have support for transactions

Aspect oriented pluggable support for parallel computing

In this paper, we present an approach to develop parallel applications based on aspect oriented programming. We propose a collection of aspects to implement group communication mechanisms on parallel applications. In our approach, parallelisation code is developed by composing the collection into the application core functionality. The approach requires fewer changes to sequential applications to parallelise the core functionality than current alternatives and yields more modular code. The paper presents the collection and shows how the aspects can be used to develop efficient parallel applicationsFundação para a Ciência e a Tecnologia (FCT) - PPC-VM (Portable Parallel Computing based on Virtual Machines) Project POSI/CHS/47158/2002; SOFTAS (POSI/EIA/60189/2004).Fundo Europeu de Desenvolvimento Regional (FEDER)

A domain-specific language for parallel and grid computing

This paper overviews a Domain-Specific Language (DSL) for parallel and grid computing, layered on top of AspectJ. This DSL aims to bridge the gap between sequential code and parallel/grid applications, by avoiding invasive source code changes in scientific applications. Moreover, it aims to promote the localization of parallelization and gridification issues into well defined modules that can be (un)plugged (from)to existing scientific applications. This paper builds on previous work based on AspectJ and presents the main motivations for implementing a DSL in preference to a pure-AspectJ solution. The paper presents the DSL's design rationale, overviews current implementation and open research issues.(undefined)info:eu-repo/semantics/publishedVersio

Whitepaper: The Value of Improving the Separation of Concerns

Microsoft's enterprise customers are demanding better ways to modularize their software systems. They look to the Java community, where these needs are being met with language enhancements, improved developer tools and middleware, and better runtime support. We present a business case for why Microsoft should give priority to supporting better modularization techniques, also known as advanced separation of concerns (ASOC), for the .NET platform, and we provide a roadmap for how to do so

Abstraction over non-local object information in aspect-oriented programming using path expression pointcuts

Aspect-oriented software development (AOSD) consists of a number of technologies that promise a better level of modularization of concerns that cannot be separated in individual modules by using conventional techniques. Aspect-oriented programming (AOP) is one of these technologies. It allows the modularization at the level of software application code. It provides programmers with means to quantify over specific points in the base application code, called join points, at which the crosscutting concern code must be triggered. The quantification is achieved by special selection constructs called pointcuts, while the triggered code that is responsible for adapting the selected join point is provided by special construct called advice. The selection and adaptation mechanisms in aspect-oriented programming depend heavily on the distinguishing properties of the join points. These properties can either be derived from the local execution context at the join point or they are considered to be non-local to the join point. Aspect-oriented systems provide a plenty of pointcut constructs that support accessing the local join point properties, while they rarely support the non-local properties. A large research effort has been achieved to extend current aspectoriented systems in order to solve the problem of non-locality. However, none of these proposals support the non-local object relationships. There are many situations where a good abstraction over nonlocal object information is needed, otherwise, the developers will be obliged to provide complex and error-prone workarounds inside advice body that conceptually do not reflect the semantics of join point selection and mix it with the semantics of join point daptation. Such recurrent situations occur when trying to modularize the object persistence concern. Object persistence, the process of storing and retrieving objects to and from the datastore, is a classical example of crosscutting concern. Orthogonal object persistence meets the obliviousness property of AOP: The base code should not be prepared upfront for persistence. This thesis addresses the shortcomings in current aspect-oriented persistence systems. It shows that the reason for such shortcomings is due to the lack of supporting non-local object information by the used aspect-oriented languages. To overcome this problem, this thesis proposes a new extension to the current pointcut languages called path expression pointcuts that operate on object graphs and make relevant object information available to the aspects. As an explicit and complete construct, a formal semantics and type system have provided. Moreover, an implementation of path expression pointcuts is discussed in the thesis along with its usage to show how the aforementioned problems are resolved

Understanding Design Patterns Density with Aspects: A Case Study in JHotDraw using AspectJ

International audienceDesign patterns offer solutions to common engineering prob- lems in programs [1]. In particular, they shape the evolution of program elements. However, their implementations tend to vanish in the code: thus it is hard to spot them and to understand their impact. The prob- lem becomes even more difficult with a "high density of pattern": then the program becomes easy to evolve in the direction allowed by patterns but hard to change [2]. Aspect languages offer new means to modular- ize elements. Implementations of object-oriented design patterns with AspectJ have been proposed [3]. We aim at testing the scalability of such solutions in the JHotDraw framework. We first explore the impact of density on pattern implementation. We show how AspectJ helps to reduce this impact. This unveils the principles of aspects and AspectJ to control pattern density

A comparative analysis of adaptive middleware architectures based on computational reflection and aspect oriented programming to support mobile computing applications

Mobile computing applications are required to operate in environments in which the availability for resources and services may change significantly during system operation. As a result, mobile computing applications need to be capable of adapting to these changes to offer the best possible level of service to their users. However, traditional middleware is limited in its capability of adapting to environment changes and different users requirements. Computational Reflection and Aspect Oriented Programming paradigms have been used in the design and implementation of adaptive middleware architectures. In this paper, we propose two adaptive middleware architectures, one based on reflection and other based on aspects, which can be used to develop adaptive mobile applications. The reflection based architecture is compared to an aspect oriented based architecture from a quantitative perspective. The results suggest that middleware based on Aspect Oriented Programming can be used to build mobile adaptive applications that require less processor running time and more memory space than Computational Reflection while producing code that is easier to comprehend and modify.8th IFIP/IEEE International conference on Mobile and Wireless CommunicationRed de Universidades con Carreras en Informática (RedUNCI

An Aspect Pointcut for Parallelizable Loops

This study investigated the need for a pointcut for parallelizable loops in an aspect-oriented programming environment. Several prototype solutions exist for loop pointcuts, but the solutions are not very granular. In particular, they are not able to differentiate between loops that are parallelizable and those that are not. Being able to identify parallelizable loops automatically, as part of an aspect-oriented compiler\u27s weaving process, is particularly important because (1) manually identifying parallelizable loops is known to be a difficult problem and (2) aspectizing parallelized loops can lead to a reduction in code tangling and an increase in separation of concerns. This paper describes the concepts behind the loop-pointcut problem. It then describes the approach used in this study for implementing a solution in the form of an aspect-oriented Java compiler with a parallelizable loop pointcut. Identifying parallelizable loops is known to be a difficult problem, and as such, this study\u27s parallelizable loop pointcut implements a heuristic solution. The pointcut identifies many parallelizable loops as being parallelizable, but in erring on the side of conservatism, there are some parallelizable loops that the pointcut is unable to identify as parallelizable. To test the parallelizable-loop pointcut, the pointcut was applied to a benchmark set of parallelizable programs. There were two versions of each benchmark program - (1) an aspect-oriented version, where the aspect-oriented compiler\u27s weaver added the multi-threading functionality, and (2) a non-aspect-oriented version, where the benchmark program\u27s source code directly implemented the multi-threading functionality. For each benchmark program, the output from the aspect-oriented version was compared to the output from the non-aspect-oriented version. The study found that each loop that was deemed parallelizable by the aspect-oriented benchmark program was executed in parallel (with multiple threads) by both versions of the program - the aspect-oriented version and the non-aspect-oriented version. There were some loops in the non-aspect-oriented benchmark programs that were deemed parallelizable and executed in parallel, but those same loops were deemed non-parallelizable by their associated aspect-oriented benchmark program. This discrepancy is explained by the study\u27s conservative approach to identifying loops as parallelizable