Persistence - the storage and retrieval of application data from secondary storage media - is often used as a classical example of a crosscutting concern. It is widely assumed that an application can be developed without taking persistence requirements into consideration and a persistence aspect plugged in at a later stage. However, there are no real world examples showing whether persistence can in fact be aspectised and, if so, can this be done in a manner that promotes reuse and is oblivious to the application. In this paper, we provide an insight into these issues drawing upon our experience with a classical database application: a bibliography system. We argue that it is possible to aspectise persistence in a highly reusable fashion, which can be developed into a general aspect-based persistence framework. Nevertheless, application developers can only be partially oblivious to the persistent nature of the data. This is because persistence has to be accounted for as an architectural decision during the design of data-consumer components. Furthermore, designers of such components also need to consider the declarative nature of retrieval mechanisms supported by most database systems. Similarly, deletion requires explicit attention during application design as mostly applications trigger such an operation.

Software connectors are increasingly recognized as an important consideration in the design and implementation of object-oriented software systems. Connectors can be used to communicate across a distributed system, coordinate the activities of several objects, or adapt one object's interface to the interface of another. Mainstream object-oriented languages, however, do not provide explicit support for connectors. As a result, connection code is intermingled with application code, making it difficult to understand, evolve, and reuse connection mechanisms.

Abstract. Meta-AspectJ (MAJ) is a language tool for generating AspectJ programs using code templates. MAJ itself is an extension of Java, so users can interleave arbitrary Java code with AspectJ code templates. MAJ is a structured meta-programming tool: a well-typed generator implies a syntactically correct generated program. MAJ promotes a methodology that combines aspect-oriented and generative programming. Potential applications range from implementing domain-specific languages with AspectJ as a back-end to enhancing AspectJ with more powerful general-purpose constructs. In addition to its practical value, MAJ offers valuable insights to meta-programming tool designers. It is a mature meta-programming tool for AspectJ (and, by extension, Java): a lot of emphasis has been placed on context-sensitive parsing and errorreporting. As a result, MAJ minimizes the number of meta-programming (quote/unquote) operators and uses type inference to reduce the need to remember type names for syntactic entities. 1

One of the main promises of aspect-oriented programming (AOP) is to promote improved modularization of crosscutting concerns, thereby enhancing the software stability in the presence of changes. This paper presents a quantitative study that assesses the positive and negative effects of AOP on typical maintenance activities of a Web information system. The study consists of a systematic comparison between the object-oriented and the aspect-oriented versions of the same application in order to assess to what extent each solution provides maintainable software decompositions. Our analysis was driven by fundamental modularity attributes, such as coupling, cohesion, conciseness, and separation of concerns. We have found that the aspect-oriented design has exhibited superior stability and reusability through the changes, as it has resulted in fewer lines of code, improved separation of concerns, weaker coupling, and lower intra-component complexity. 1.

This paper presents a pattern that provides a structure for implementing distribution using AOP -- aspect-oriented programming. The main goal is to achieve better separation of concerns avoiding tangled code (code with different concerns interlacing to each other) and spread code (code regarding one concern scattered in several units of the system). Therefore, system modularity, and hence, maintainability and extensibility are increased. The paper also presents an example of distribution aspects using AspectJ, an aspect-oriented extension to Java.

Abstract. An architectural aspect is a concern that cuts across architecture modularity units and cannot be effectively modularized using the given abstractions of conventional Architecture Description Languages (ADLs). Dealing with crosscutting concerns is not a trivial task since they affect each other and the base architectural decomposition in multiple heterogeneous ways. The lack of ADL support for modularly representing such aspectual heterogeneous influences leads to a number of architectural breakdowns, such as increased maintenance overhead, reduced reuse capability, and architectural erosion over the lifetime of a system. On the other hand, software architects should not be burdened with a plethora of new ADL abstractions directly derived from aspect-oriented implementation techniques. However, most aspect-oriented ADLs rely on a heavyweight approach that mirrors programming languages concepts at the architectural level. In addition, they do not naturally support heterogeneous architectural aspects and proper resolution of aspect interactions. This paper presents AspectualACME, a simple and seamless extension of the ACME ADL to support the modular representation of architectural aspects and their multiple composition forms. AspectualACME promotes a natural blending of aspects and architectural abstractions by employing a special kind of architectural connector, called Aspectual Connector, to encapsulate aspect-component connection details. We have evaluated the applicability and scalability of the AspectualACME features in the context of three case studies from different application domains.

Program generation is among the most promising techniques in the e#ort to increase the automation of programming tasks. In this paper, we discuss the potential impact and research value of program generation, we give examples of our research in the area, and we outline a future work direction that we consider most interesting. Specifically, we first discuss why program generators have significant applied potential. At the same time we argue that, as a research topic, meta-programming tools (i.e., language tools for writing program generators) may be of greater value. We then illustrate our views on generators and meta-programming tools with our latest work on the Meta-AspectJ metaprogramming language and the GOTECH generator. Finally, we examine the problem of statically determining the safety of a generator and present its intricacies. We limit our focus to one particular kind of guarantee for generated code---ensuring that the generated program is free of compile-time errors. We believe that this research direction will see significant attention and will make a di#erence in the mainstream adoption of meta-programming technology.

J2EE is a middleware architecture augmented with supporting tools for developing large scale client/server and multi-tier applications. J2EE uses Enterprise JavaBeans as its component model. The realization of these components by a J2EE application server can be conceptually decomposed into distinct aspects such as persistence, transaction management, security, and load balancing. However, current servers do not employ aspect-oriented programming in their implementation. In this paper, we describe a new aspect language, AspectJ2EE, geared towards the generalized implementation of J2EE application servers, and applications within this framework. AspectJ2EE can be easily employed to extend the fixed set of services that these servers provide with new services such as logging and performance monitoring. Even tier-cutting concerns like encryption, data compression, and memoization can be added while avoiding the drags of cross-cutting and scattered code. AspectJ2EE is less general (and hence less complicated) than AspectJ, yet demonstrably powerful enough for the systematic development of large scale (and distributed) applications. The introduction of parameterized aspects makes aspects in AspectJ2EE more flexible and reusable than aspects in AspectJ. AspectJ2EE also generalizes the process of binding services to user applications in the application server into a novel deploy-time weaving of aspects. Deploytime weaving is superior to traditional weaving mechanisms, in that it preserves the object model, has a better management of aspect scope, and presents a more understandable and maintainable semantic model.

Separation of concerns and modularization are the cornerstones of software engineering. However, when a system is decomposed into units, functionalities often emerge which cannot be assigned to a single element of the decomposition. The implementation of interfaces represents a typical instance of this problem. In fact, the code that defines the interface methods is often scattered across several classes in the system and tangled with the original code. Aspect Oriented Programming provides mechanisms for the dynamic and static composition of transversal functionalities, that can be used to factor out the implementation of interfaces. In this paper we describe a technique for the identification of those interface implementations that are most likely to represent crosscutting concerns. Moreover, the code transformation (refactoring) to migrate such interfaces to aspects is also presented. Experimental results validate the approach.

This paper reports our experience using AspectJ, a general-purpose aspect-oriented extension to Java, to implement distribution and persistence concerns in a web-based information system. This system was originally implemented in Java and restructured with AspectJ. Our main contribution is to show that AspectJ is useful for implementing several persistence and distribution concerns in the considered application, but also in similar applications. We have also identified interferences between the implemented aspects and a few drawbacks in the language, so we suggest some minor language modifications that could significantly improve similar implementations. Despite those problems, we argue that the AspectJ implementation is superior to the pure Java and constitute a simple aspect framework. The other aspects are application specific but we suggest that different implementations might follow the same aspect patterns. The framework and the patterns allow us to propose architecture-specific guidelines that provide practical advice for both restructuring and implementing certain kinds of persistent and distributed applications with AspectJ. Copyright c ○ 2000 John Wiley &