DraK's Klog

jPOS is a Java® platform-based, mission-critical financial transaction library/framework that can be customized and extended in order to implement financial interchanges.

For non eclipse based projects where OSGi is overkill but that still want extension points, this might be the solution.

JPF, an open source, LGPL licensed library intended to provide standard plug-in infrastructure Java projects, has reached version 1.0. It's been influenced by, but not derived from, Eclipse' plugin structure. It's designed to help improve modularity and extensibility of Java systems and decrease their support and maintenance cost.

Cet intercepteur AOP est un très bel exemple d'utilisation de l'AOP pour effectuer des mesures de performance.

Le seul point qui m'ennuyait au sujet de l'approche déclarative de la gestion des transactions qu'offre Spring était la crainte de voir fleurir les définitions de bean.

Spring offre une solution très élégante à ce problème avec les templates de bean. En effet, il est possible de définir un bean comme abstrait, en l'occurence le TransactionProxyFactoryBean en spécifiant par exemple le type de propagation par défaut et d'en faire hériter tous les beans de services métiers.

Cette solution est vraiment très élégante, absolument pas intrusive. Les services métiers n'ont aucune connaissance de la notion même de transactions. Et surtout, elles n'ont pas a prendre les précautions inhérentes à l'ouverture et à la terminaison d'une transaction. Ce n'est pas sorcier, mais multiplié par le nombre de services que peut compter une grosse application entreprise, une étourderie est vite faite.

Il y a deux arbres d'héritage parallèles, celui des services métiers purement objet, et celui des définitions de bean de ces même services.

Un autre point, je me méfiais du fait que c'est implémenté à l'aide de l'AOP, qui est tout de même relativement nouveau et qui est difficile à présenter à un DSI ...

Et bien, finalement, il s'avère que cette technique peut même apporter encore plus de contrôle et de possibilité de tests de qualité. En effet, si la gestion des transactions est faite par les services eux-même, et bien il est très difficile sinon pas envisageable de s'assurer que les transactions sont bien gérées sans se farcir la lecture du code source de tous les services.

Or avec l'approche de Spring, et bien il est tout à fait envisageable d'instancier le contexte dans un test unitaire qui irait étudier la définition de tous les proxy transactionnels pour vérifier que toutes les méthodes des services sont bien couvertes par un intercepteur. C'est définivement une piste à suivre !

ONess est une démonstration technologique.

ONess is a sample webapp application using latest open source technologies.

Unlike Appfuse, from Matt Raible, ONess is not a start point, it's real-world modular designed app that can be used as a sample of technology integration, showing best practises, utilities and real world examples. As disadvantage ONess is not implemented in different technologies, only one in each field, but provides better integration advices, ONess is bigger than Appfuse. Something that ONess uses and Appfuse doesn't is Maven.

ONess also provides a set of reusable business components available to be used in real world apps.

Its development started as a University project in the University of A Coruña (Spain).

C'est une sacré bonne nouvelle qui va grandement accélérer l'adoption de l'AOP ! Le plus gros problème de l'AOP actuellement venant de la multitude des implémentations existantes.


Un merge similaire dans le domaine des containers de composant serait pas mal non plus

The Spring Framework is a very powerful library for J2EE development. It comes with an AOP implementation (based on proxies) that is in many cases sufficient in terms of what you need to do. However, there are many situations where you need a more full-blown AOP framework (such as AspectWerkz) to do the job.

Cet article présente comment mettre en oeuvre une stratégie de mise en cache en utilisant une approche orientée aspect.


La technologie AOP est AspectJ.

La programmation AOP (Aspect Oriented Programming) semble très prometteuse, et IBM propose déjà avec le plugin AJDT pour Eclipse un outils opérationnel de développement AspectJ.


Sur la page du projet AspectJ eclipse:

AspectJ enables the clean modularization of crosscutting concerns such as: error checking and handling, synchronization, context-sensitive behavior, performance optimizations, monitoring and logging, debugging support, multi-object protocols

Sur la page du projet AJDT eclipse:

Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems. Aspect Oriented Software Development enables the clean modularization of these crosscutting concerns. The AspectJ Development Tools (AJDT) project will provide Eclipse platform based tool support for AOSD with AspectJ. Our goal is to deliver a user experience that is consistent with the Java Development Tools (JDT) when working with AspectJ projects and resources. This will be accomplished by developing an integration layer between the AspectJ Development Environment Framework and Eclipse/JDT extension points.

Christoph C. Cemper écrit sur son blog:

Aspect-oriented programming (AOP) is an exciting new paradigm that shall not compete but enhance the OOP.


The OOP weakness in applying common behavior that spans multiple non-related object models is where AOP comes in. AOP allows you to define cross-cutting concerns that can be applied across separate, and very different, object models. It allows you to layer ? rather than embed ? functionality so that code is more readable and easier to maintain.


Where the tools of OOP are inheritance, encapsulation, and polymorphism,
the components of AOP are advices/interceptors, introductions, metadata, and pointcuts. Wow... heard of it the first time today...


* Advices/Interceptors: An advice is logic that is triggered by a certain event. It is behavior that can be inserted between a caller and a callee, a method invoker and the actual method. Advices are really the key to AOP. These constructs allow you to define the layers.

* Introductions: are a way to add methods, fields or even interfaces to an existing class. Sounds like very reflection-heavy and allows runtime-modifications for generators or similar...
* Metadata can be attached even during runtime to existing instances... this shall be added in Java 1.5 via JSR175

* Pointcuts are the glue to hold above features together... the links and apply-rules are set with these.

Le serveur d'application J2EE JBoss supporte l'AOP en standard:

The Aspect-Oritented Programming architecture of JBoss 4.0 enables it to provide a wide range of services, including object persistence, caching, replication, acidity, remoteness, transactions and security. The framework allows developers to write plain Java objects and apply these enterprise-type services later on in the development cycle -- without changing a line of Java code. This new concept of programming provides a clean separation between the system architect and the application developer. The iterative development process becomes more fluid as architectural design decisions can be made later on in the development process without changing any of your Java code. Entirely unique among Java-based application servers today, this architecture combines the simplicity of standard Java with the power of J2EE.