Esper als EDA-Plattform

Ist Event-driven Architecture (EDA) gefangen im Gartner Hypecycle oder gelingt mit Esper der Durchbruch für echte Businessintegration mit EDA jenseits des Gipfels der inflationären Erwartungen?

PDF: Esper als EDA-Plattform Christian Dedek Papick [...]]]> I just received the PDF version of our EDA and Esper Article for the german magazine Java Magazin 5.2008.

Esper als EDA-Plattform

Ist Event-driven Architecture (EDA) gefangen im Gartner Hypecycle oder gelingt mit Esper der Durchbruch für echte Businessintegration mit EDA jenseits des Gipfels der inflationären Erwartungen?

PDF:
Esper als EDA-Plattform
Christian Dedek
Papick Garcia Taboada

Event Driven Architecture

Ist EDA gefangen im Gartner Hypecycle oder gelingt mit Esper der Durchbruch für echte Businessintegration mit EDA jenseits des Gipfels der inflationären Erwartungen?

EDA ist das Akronym für: Event Driven Architecture. Sehr oft werden [...]]]> In der nächsten Ausgabe vom Javamagazin ist unser (Christian Dedek und ich) Artikel zu Esper mit EDA:

Event Driven Architecture

Ist EDA gefangen im Gartner Hypecycle oder gelingt mit Esper der Durchbruch für echte Businessintegration mit EDA jenseits des Gipfels der inflationären Erwartungen?

EDA ist das Akronym für: Event Driven Architecture. Sehr oft werden EDA Architekturen auf Systeme reduziert, die lediglich asynchron Nachrichten austauschen (z.Bsp. JMS einsetzen). Unter EDA versteht man allerdings auch die Verarbeitung von Ereignisströmen und die Mustererkennung komplexer Zusammenhänge zwischen Ereignissen. Die Verarbeitung von Ereignisströmen ist unter dem Akronym ESP (Event Stream Processing) bekannt, während CEP (Complex Event Processing) für die Mustererkennung komplexer Zusammenhänge steht.

Mit dem Google Web Toolkit (GWT) soll ein Java- Entwickler schnell in die Lage versetzt werden, JavaScript/Ajax-Anwendungen zu schreiben. Die Nachfrage ist groß, und immer mehr Projekte sollen mit JavaScript im Browser dem Trend des Web 2.0 folgen: von intelligenter Validierung über Drag-and-Drop bis hin zu Mashups mit Google Maps. Der Browser hat [...]]]>

Mit dem Google Web Toolkit (GWT) soll ein Java- Entwickler schnell in die Lage versetzt werden, JavaScript/Ajax-Anwendungen zu schreiben. Die Nachfrage ist groß, und immer mehr Projekte sollen mit JavaScript im Browser dem Trend des Web 2.0 folgen: von intelligenter Validierung über Drag-and-Drop bis hin zu Mashups mit Google Maps. Der Browser hat sich zur beliebtesten Anwendungsplattform entwickelt, die User Experience ist hier das Schlüsselwort.

Seitdem das Google Web Toolkit [1] auf der JavaOne 2006 vorgestellt wurde, erfreut sich das Projekt immer größerer Beliebtheit. Was aber ist GWT? Kurz: eine Technologie bzw. ein Framework, mit dem JavaScript-Webanwendungen erstellt werden können. Das Besondere am GWT-Entwicklungsprozess ist nicht das Ergebnis, sondern die Vorgehensweise: Der Entwickler schreibt die gesamte Webanwendung in Java (kein HTML, kein JavaScript). Der Trick besteht darin, den Java-Quelltext nach JavaScript zu übersetzen, sodass die Vorgehensweise das Nutzen aller Fähigkeiten der IDE wie das Refactoring und Debuggen im clientseitigen Code ermöglicht. Das GWT Framework bietet ein grafisches UI-Komponentenmodell, ein Modularisierungskonzept, eine fragmentarische Java-Runtime-Emulation, ein API zur Manipulation der Browser-History, eine eigene RPC Implementierung, Internationalisierung und noch einiges mehr. Hier Googles Leitspruch für GWT:

„GWT‘s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser” [2].

Frei übersetzt bedeutet das eine radikale Verbesserung bei der Verwendung von Webanwendungen (für den Endanwender). Bestehende Java-Werkzeuge sollen eingesetzt werden, um ohne Einschränkungen AJAX-Anwendungen auf beliebigen Browsern zu entwickeln.

Es ist schon beeindruckend, was sich hinter dieser neuen Technologie verbirgt. Aber es ist von Google … Schon seit einiger Zeit hat Google das Image des sauberen kleinen Start-ups verloren. Google ist groß, Ziele und Mittel teilweise umstritten. An dieser Stelle erst einmal eine Entwarnung – auch wenn Google drauf steht, ist kein Google drin. Durch die Verwendung von GWT werden keinerlei Dienste von Google (außer GWT selbst) verwendet. Google hat natürlich nichts dagegen, wenn sich immer mehr Produkte bei anderen Google-Technologien bedienen – zum Beispiel Google Search oder Google Maps. Wenn die Hemmschwelle hier bislang bei den nötigen JavaScript-Kenntnissen lag, so ist diese mit GWT letztendlich behoben worden. Auch für JSF gibt es bereits Komponenten, die das Verwenden von Google JavaScript APIs erleichtern:

„Naturally, GWT is also a great way to easily take advantage of the latest and greatest Google APIs and browser enhancements, such as Google Gears” [3].

GWT ist heute einsatzbereit: Es ist seit Version 1.3 unter der Apache License 2.0 veröffentlicht und seit Version 1.4 trägt GWT nicht mehr den Zusatz „Beta“ im Namen. Die aktuelle Versionsnummer lautet 1.4.61 und kann von der
GWT-Homepage in Google-Code heruntergeladen werden. Das GWT-Team
arbeitet gerade an der neuen Version 1.5. Wichtigste Neuerung, an der aktuell gearbeitet wird, ist die Unterstützung der bei Java 5.0 neu eingeführten Sprachelemente wie Annotations und Generics, denn aktuell wird lediglich der Sprachumfang von Java 1.4.2 unterstützt. Die unterstützten Browserplattformen des Projekts sind im Augenblick die aktuellen Versionen des Microsoft Internet Explorers, Firefox, Opera und Safari.

Artikel weiterlesen:
PDF: Make the Web a better place

In meinem Artikel habe ich GWT als [...]]]> In der Ausgabe Vol. 14 2.08 wurde als Titelthema “Rich Internet Applications” gesetzt. Ich habe den Artikel zu GWT beigesteuert: “Make the Web a Better Place” – gestern habe ich meinen Belegexemplar bekommen. Als Brasilianer habe ich mich besonders über das Bild auf der ersten Seite gefreut!

In meinem Artikel habe ich GWT als Technologie und als Framework kurz vorgestellt. Einfache Beispiele sollen den Einstieg erleichtern:

Google Web Toolkit: Webanwendungen mit GWT entwickeln

Mit dem Google Web Toolkit (GWT) soll ein Java- Entwickler schnell in die Lage versetzt werden, JavaScript/Ajax-Anwendungen zu schreiben. Die Nachfrage ist groß und immer mehr Projekte sollen mit JavaScript im Browser dem Trend des Web 2.0 folgen: von intelligenter Validierung über Drag-and-Drop bis hin zu Mashups mit Google Maps. Der Browser hat sich zur beliebtesten Anwendungsplattform entwickelt, die User Experience ist hier das Schlüsselwort.

Leider wurde Zoltan Horvath in meinem Artikel nicht erwähnt: er hat für mich die Box zu MyGWT geschrieben.

Wir haben beide diese Bibliothek kürzlich in einem Projekt bei OIO eingesetzt. An dieser Stelle nochmal ein “Danke” für die Box und fürs Korrekturlesen.

While splitting a project in smaller pieces is not really a new concept – and with maven it is even easy to accomplish – it still is a major problem [...]]]> Antidoto – the beginning

Interesting ways…

In the last months I participated in projects using spring and maven2 to build coarse grained software modules.

While splitting a project in smaller pieces is not really a new concept – and with maven it is even easy to accomplish – it still is a major problem to integrate those parts together again.

In my session at the W-JAX 2006 conference I spoke about the lack of architectural guidance when building software based on coarse grained pieces. With the upcoming session at the Spring Day in Germany, I decided to opensource the actual codebase.

• Why “antidoto”?

Antídoto is the portuguese word for antidote. An antidote is a substance which can counteract a form of poisoning. Antidoto is a java technology mashup providing building blocks for modular architectures. Modern java technologies are component based, but lack modularization capabilities. Here is where the poisoning is happening and where Antidoto jumps in.

• Why “interesting ways”?

Because thats what people say when they see it. “Thats interesting”. Thought it would be fair to call them this way… ;-)

• Why “the beginning”?

Because it was the beginning of Antidoto. The feedback from colleagues, customers and listeners at the W-JAX conference encouraged me to go ahead and create my first open source project

Form over substance

The earth is populated with shallow and ignorant people. That’s why form will always be more important than substance. You can waste your time complaining about how that should not be the case in a perfect world, or you can snap out of it an follow my advice.

Documents

If a document is over two pages long, few people will ever read it. And those who do read it won’t remember it in twenty-four hours. That’s why all your documents should be over two pages long. You don’t want your readers to be influenced by a bunch of facts. You want them to look at your creative use of fonts, your brilliant application of white space, and you inspired graphics. Good formatting leaves the reader with the clear impression that you are a genius and therefore whatever you’re writing about must be a good idea.

The Dilbert Principle,
Machiavelllian Methods

Scott Adams

Goals and background

The goal of this series of articles is to provide an overall architectural guideline for Java (TM) based enterprise software development. Each software project has its own special requirements which must be analyzed by themselves, but many software projects have common requirements:

Reusability of Software Components

The modern development today imposes that software products should not be a monolithic piece of software. Therefore the system should be divided and developed in subsystems. In an assembly process, the deployment artifacts will be generated out of dependent subsystems.

Increased Software Quality

Software quality factors are non functional requirements, among them

• Testability
• Security
• Reliability
• Maintainability
• Understandability
• Performance and Scalability

The new architecture should allow to scale the deployed system to achieve the needed performance, without having to rewrite code, transparently to both the developer and the users.

Multiple teams and offshoring

Many projects have a very short development time, so work is accomplished by many teams, on site, off site and off shore. Teams must be able to work together on the same project with minimal impact on efficiency.

Architectural principles applied

This architectural guideline is based on common architectural principles.

Layering

Presentation Layer

The front end consists of one or more web applications, rich clients, integration layer consumers. This layer should only provide view logic (presentation, internationalization, navigation) and no business specific logic.

Any client specific state will be stored in components in this layer.

Business Layer

The business layer provides the business logic used by the presentation layer.

Integration Layer

The integration layer provides access to the required resources, among them legacy Corba applications and different relational database resources.

Service Orientation

In short, Service-Oriented Architecture describes a perspective of software architecture that defines the use of services to support the requirements. In this special case, some of the subsystems to be defined may expose such remote services to the overall system.

As the system becomes implemented and the number of point to point connection increases, the usage of a enterprise service bus might be evaluated.

Modularization

One of the major goals of modularization is to divide complex monolithic systems in less complex smaller modules.
A modular design is characterized by

• Functional partitioning into discrete scalable, reusable modules consisting of isolated, self-contained functional elements
• Rigorous use of well defined modular interfaces, including object-oriented descriptions of module functionality
• Ease of change to achieve technology transparency and, to the extent possible, make use of industry standards for key interfaces.

Decomposed modules were renamed to subsystems in this architectural guideline.

A subsystem must have a system wide unique identifying name. Addressing subsystems is explained in detail later.

Subsystem encapsulation

Each subsystem should hide its internal implementation from external components in the system. The architecture can enforce encapsulation by name conventions (using standard Java packages) and AOP techniques (declaring compilation errors).

Each subsystem “owns�? one package name, preferably similar to the groupdId and artifacId names – subsystem these identifiers are explained later. The architectural prototype uses exactly the groupId and artifactId to define the package names.

Unfortunately the Java package encapsulation does not know hierarchical encapsulation. The usage of more than one package name for one subsystem leads to public internal interfaces. In this case the developer should know that public interfaces in hierarchical sub-packages must not used from external subsystems, they are for internal use only.

This is the main reason why a naming convention for subsystem package names should be defined and known by every developer in the development teams.

Naming the pieces

Very important in an architecture guideline is to define and document the constituting pieces of the software.

It is of central importance for everybody in the development teams to know how to name the composing parts, and to understand the boundaries and size of modules, subsystems, systems and components – if these are the names used in the architectural definitions.

For this series of articles I have given the software product and the composing parts the following names:

• System
• Subsystem
• Module
• Components

Putting pieces together

Decomposing a software in smaller pieces is not new to the software industry.

Divide and conquer has been the slogan for years. The problem is, once you got the pieces, you have to put them together to work as one again. This is where the technologies, as we know them today, fail.

Composing a system out of decomposed subsystems means you have to know subsystem dependencies:

• compile time dependencies
• runtime dependencies

The compile time dependencies arise as long as we have subsystems interacting with other subsystems. Since this is a very common situation, we will have many compile time depencies.

The runtime dependencies arise as we develop against interfaces. Our software components will not instantiate the needed classes by themselves (see dependency injection, inversion of control). There will be a factory responsible for wiring up component beans and their dependencies. The dependencies described here are runtime dependencies.

Solving the jigsaw puzzle

Jigsaw puzzle: puzzle consisting of differently shaped pieces which fit together to form a picture

Here comes a small example, just to emphasize how complicated things can get when you start developing subsystems and managing their dependencies. We will develop two systems (A & B):

• WebApp A

• JSF/ Facelets UI
• Business logik bl1 and bl2
• Persistence db1 and db2

• Rich client B

• RCP client
• Business logic bl2 and bl3
• Persistence db2 and db3

The next picture is showing the dependencies between the subsystems and the spring libraries, but the dependencies to all other libraries are still missing.

The point here is: it is almost impossible to manage all the dependencies here by hand. Imagine if each subsystem in the picture becomes replaced by at least two modules, one for the interfaces and another for the implementation.

There are different approaches to manage dependencies, among them are the OSGi frameworks providing plugin architectures.

The prototype developed along with this architecture guideline does not use an OSGi framework.

• To manage the compile time dependencies, it uses maven2.
• To manage the runtime dependencies, it uses the bean factories from the spring framework.

To get along with this jigsaw we need an integration server and automatic builds and testing. This is not new to modern and agile Java development. This is called continuous integration.

Grouping subsystems

There are different categories of subsystems. In a very simple approach, we will at least find subsystems containing…

• the technical infrastructure
• the business logic
• the persistence logic
• the presentation clients

Thank you for reading!

pdf: Eclipse Magazin [...]]]> Mit der IDE for Laszlo haben IBM und Laszlo Systems eine Entwicklungsumgebung für die Entwicklungvon OpenLaszlo-Anwendungen bereitgestellt. Diese basiert auf Eclipse und der Web Tools Platformund ist sogar seit neuestem als Eclipse Technology Project angenommen worden. Die IDE for Laszlo stelltalle notwendigen Werkzeuge zur Verfügung, um bequem eine OpenLaszlo-Anwendung zu entwickeln.

pdf: Eclipse Magazin Artikel – Reiche Ernte

Dies Einführung in die AOP findet in den ersten vier Kapiteln statt:

[...]]]> In diesem Artikel wird die aspektorientierte Programmierung, kurz AOP genannt, einführend erläutert. Als Grundlage dient das Buch „AspectJ in Action“ von Ramivas Laddad, das sowohl eine theoretische Einführung in die AOP enthält als auch einige praktische Beispiele vorstellt.

Dies Einführung in die AOP findet in den ersten vier Kapiteln statt:

• In dem ersten Kapitel wird die Geschichte der AOP und das Umfeld, aus dem AOP entstanden ist umrissen.

• Das zweite Kapitel beschäftigt sich mit der theoretischen Einführung in die AOP.

• Im dritten Kapitel wird eine Implementierung der AOP an dem Beispiel von AspectJ vorgestellt.

• Abschließend wird im vierten Kapitel die praktische Anwendung von AspektJ gezeigt (noch nicht online)

Ziel dieser Ausarbeitung ist es, das Grundverständnis für AOP und einen praktischen Einblick in die Arbeit mit AOP zu vermitteln.

Die Entstehung der aspektorientierten Programmierung

Diese Seminararbeit entsteht zu einem Zeitpunkt, an dem die AOP kein theoretischer Ansatz mehr ist. Sie wird heute bereits produktiv eingesetzt. Das Umfeld reicht von Literatur sowohl zur Methodologie als auch zu Implementierungen bis hin zu Referenzprojekten.

Historische Entwicklung

Der Begriff AOP wurde erstmals 1996 in Veröffentlichungen von Gregor Kiczales im Palo Alto Research Center, von Xerox Corporation erwähnt. Das Team hinter Gregor Kiczales und Cristina Lopes waren die ursprüngliche Entwickler von AspectJ.

Die Grundidee hinter AOP hat sich aus der frühen Erkenntnis heraus kristallisiert, dass wartbare Systeme erst durch die strikte Trennung ihrer Dienste zu implementieren sind. Diese Erkenntnis wurde Separation of Concerns, kurz SOC, getauft. Bereits 1972 wurde in einem Artikel¹ von David Parnas [L6] festgehalten, dass Modularisierung und Kapselung der beste Weg für das Erreichen von SOC sei. Beschrieben wurde die Modularisierung als ein Prozess, in dem Dienste in Modulen implementiert werden. Diese Module haben Ihre Implementierung voreinander gekapselt.

Die Evolution der Softwareentwicklung hat viele Techniken und Frameworks zum Erreichen von SOC hervorgebracht. Allen gemeinsam ist das Ziel, komplexe Systeme wartbarer zu machen.

Das Umfeld

Die Entwicklung komplexer Systeme stellt besondere Herausforderungen an die Entwickler. Neben der eigentlichen Geschäftslogik (engl. „core concerns“), auch fachliche Anforderungen genannt, müssen systemtechnische Crosscutting Concerns wie Authentifizierung, Persistenz, verteilte Kommunikation, transaktionales Verhalten und Protokollierung implementiert werden.Das Modell der Geschäftslogik wird in vielen Projekten heute in dem objektorientierten Ansatz entwickelt, da es der menschlichen Denkweise am nächsten liegt: in der objektorientierten Softwareentwicklung werden, vereinfacht dargestellt, Systeme als Ansammlung zusammenarbeitender Objekte modelliert. Objekte besitzen einen Zustand und ein Verhalten, das ihrer Klasse definiert und implementiert wird.Durch diese Vorgehensweise, den Einsatz von Entwurfsmustern [L2] und sogenannten Refactoring-Techniken [L3] sollte ein besonders hohes Maß an Wiederverwendbarkeit einzelner Komponenten erreicht werden. Das Versprechen der Wiederverwendbarkeit lässt sich häufig nicht einlösen, da speziell auf der Ebene der Programmierung oftmals nichtfachliche beziehungsweise technische Anforderungen nicht vollständig in separaten Klassen kapseln lassen. Statt dessen durchziehen solche Aspekte eines Softwaresystems in nicht unerheblichem Ausmaß den rein fachbezogenen Teil der Implementierung. Dies führt dazu, dass Klassen zu konkret an einen Einsatzkontext gebunden und nicht mehr beliebig wiederverwendbar sind.

Die nichtfachlichen, beziehungsweise technischen Anforderungen werden in der Literatur zu aspektorientierter Programmierung als Crosscutting Concerns bezeichnet.

Technische Anforderungen sind integraler Bestandteil komplexer Software­systeme und nicht wegzudenken. Aus diesem Grund werden Design­entscheidungen oftmals von fachfremden Anforderungen beeinflusst.

Oft ist es nicht absehbar, welche Dienste in welcher Form in einem System benötigt werden. Da Crosscutting Concerns naturbedingt nicht nur in einem Modul, sondern zusätzlich in den Fachklassen zumindest aufgerufen werden, haben Veränderungen in diesem Bereich kritische Auswirkungen auf das gesamte System.

Speziell für den Entwurf transaktionaler, verteilter, sicherer, unternehmens­kritischer Anwendungen wurde das Framework Enterprise JavaBeans, kurz EJB, von Sun entwickelt. In einem Applikationsserver werden Crosscutting Concerns wie Sicherheit, Persistenz, transaktionales Verhalten, Clustering und Ausfallsicherheit für die so genannten enterprise beans von einer EJB-Laufzeitumgebung (EJB container) bereitgestellt. In welchem Umfang und Konfiguration diese Dienste verwendet werden, wird über eine XML-Konfigurationsdatei (engl. „deployment descriptor�?) definiert. Die EJB-Laufzeit­umgebung, die alle Komponenten und deren XML-Konfigurationen kennt, stellt diese Crosscutting Concerns bereit. Damit das funktionieren kann, verliert der Entwickler die Kontrolle über den Lebenszyklus der eigenen Komponenten und darf lediglich Dienste, bzw. Schnittstellen bereitstellen. Alle Aufrufe auf die Komponenten werden von der Laufzeitumgebung abgefangen. Die Anzahl der Restriktionen ist hoch; das Framework ist speziell für den Entwurf von Client-Server-Anwendungen in einem sehr engem Rahmen erstellt worden.

Das EJB-Framework zeigt,

• dass es nicht trivial ist, das Design der eigenen Fachlogik mit den Anforderungen des technischen Rahmenwerkes zu vereinen bzw. getrennt zu entwickeln, und

• dass ein solches Framework sehr umfangreich werden kann

Projekte, die heute nicht in das Raster von Enterprise JavaBeans passen, oder vielleicht nicht in Java entwickelt werden sollen, werden sofort wieder mit der Problematik der Crosscutting Concerns und der Entwicklung eines passenden Frameworks konfrontiert.

public class MeineGeschäftslogik {
… geschäftlogik Attribute
… protokollierungs-API Attribute
… cache update Status

public void loeseAufgabe( Aufgabe-Parameter, Authentifikationsdaten)
{
… Authentifizierung sicherstellen
… Objektsperre setzen
… start protokollieren
… geschäftslogik
… persistenz ausführen
… ende protokollieren
… Sperre aufheben
}
}

Beispiel 1″Code Tangling”

An dem oberen Beispiel wird anschaulich dargestellt, wie die Crosscutting Concerns, obwohl in externen Modulen implementiert, in der Geschäftlogik wieder auftauchen. Diese Crosscutting Concerns sind ohne das Erstellen eines entsprechenden Frameworks nicht aus dem Programmcode wegzudenken.

Die Folgen sind Verminderung der Softwarequalitätsmerkmale Lesbarkeit, Wiederverwendbarkeit, Wartbarkeit und Änderbarkeit. In dem Buch von Ramnivas Laddad [L1] werden in diesem Kontext zwei Phänomene erwähnt: Code Tangling und Code Scattering. Die folgende Grafik skizziert in abstrakter Form ein System, das solche Phänomene aufweisst. Komponenten werden durch die einzelne Puzzlesteine repräsentiert:

Abbildung 1

Der Begriff Code Tangling beschreibt die in Beispiel 1 dargestellte Vermengung von Core Concerns und Crosscutting Concerns. In der Abbildung 1 wird dieses Phänomen in den Komponenten der fachlichen Anforderungen gezeigt.

Unter Code Scattering versteht man die Streuung der Implementierung eines Dienstes in mehreren Modulen. In der Abbildung 1 wird deutlich gezeigt, dass die Aspekte Logging und Authentifizierung sowohl in eigene Komponenten als auch in aspektfremde Komponenten implementiert werden.

Während Code Tangling negative Auswirkung auf die Software-qualitäts­merkmale Lesbarkeit und Wiederverwendbarkeit hat, führt Code Scattering zu Verschlechterung in der Wartbarkeit und Änderbarkeit des Systems.

Mythos AOP

Die aspektorientierte Programmierung wird heute nach der Einführung der objektorientierten Programmierung, kurz OOP, als weiterer Paradigmen­wechsel behandelt. Man muss jedoch beachten, das AOP kein neues Paradigma in der Modellierung darstellt. Lediglich in der Implementierung stellt sich aspektorientierte Programmierung als Erneuerung dar.

Diese Erneuerung ist nicht unwesentlich: dadurch entstand fälschlicherweise der Eindruck, dass durch den Einsatz von aspektorientierter Programmierung die objektorientierte Programmierung ersetzt werde. Dieser Mythos entstand aus dem Unwissen, welche Vorteile und Neuerungen die AOP tatsächlich für die Softwareentwicklung mit sich bringt.

Vor einiger Zeit hat das „Unit Testing“, insbesondere durch den breiten Einsatz von jUnit, in der Java-Gemeinde für Aufsehen gesorgt. Es wurde schnell akzeptiert, dass das automatisierte und atomare Testen sehr positive Auswirkungen auf den Entwicklungsprozess haben kann. In diesem Umfeld entstand der Begriff der „Continuous Integration“ in einem Dokument von Martin Fowler.

Bestehende Projekte haben festgestellt, dass schlecht entwickelte Komponenten schwierig zu testen sind. Die Testbarkeit von Komponenten hat sich sogar als Indiz für die Designqualität des Codes entwickelt. Mittel- und kurzfristig wurden als Folge zur Einführung des Unit-Testings Komponenten entwickelt, die kleinste kohärente und sinnvolle Funktionalität abgebildet haben, und somit einfacher zu testen waren. Testbarkeit, Wiederver­wendbarkeit und Änderbarkeit sind erkärte Ziele eines jeden Software­projektes, das erfolgreich sein will. Die grösste Problematik stellen die Crosscutting Concerns dar.

Sicherlich kann man die aspektorientierte Programmierung als nächsten Schritt in der Evolution der Softwareentwicklung betrachten. Schliesslich kommen wir mit dieser Technik dem Ziel deutlich näher, Dienste – egal welcher Natur – in eigene Module zu kapseln. Allerdings ist AOP kein Wundermittel gegen schlechtes Design, eher ein Vitamin, das die Software­entwicklung effizienter machen kann.

Einführung in die aspektorientierte Programmierung

Die Idee hinter der aspektorientierten Programmierung besteht darin, die so genannten Crosscutting Concerns komplett in eigene Komponenten auszulagern. Diese werden schliesslich Aspekte genannt. Dadurch wird die ursprüngliche Fachlogik nicht mehr um die orthogonale Funktionalität aufgebläht.

Aspektspezifische Anweisungen

Eine echte Trennung von Diensten auf der Ebene der Programmierung läßt sich durch Auslagern aspektspezifischer Anweisungen in eigenständige Entitäten erreichen.

Ein solchermaßen aspektorientiert entwickeltes Softwaresystem besteht aus herkömmlichen Klassen, die die fachlichen Anforderungen implementieren, und – als neues Modularisierungskonzept – aus Aspekten, die jeweils eine bestimmte technische Anforderung realisieren.

Aspekte wirken dabei auf Klassen ein, indem sie deren Methoden um zusätzliche Anforderugen erweitern. Sie ergänzen somit das Verhalten von Objekten um aspektspezifische Anteile, ohne dabei das fachliche Verhalten zu beeinflussen.

Wie in jeder neuen Methodologie oder Technik gibt es auch für die AOP ein „Hello World“: hier verwendet man in der AOP-Literatur die technische Anforderung des Protokollierens (Logging, Tracing) um ein entsprechend anschauliches Beispiel aufzusetzen.

Die Protokollierung bildet ein Aspekt des Systems, und die Fachklassen werden frei vom Protokollierungscode entwickelt.

Allgemeine Vorgehensweise

Die Entwicklung einer AOP Software verläuft im wesentlichen nicht anders als bei der OOP: zunächst werden die Anforderungen ermittelt und implementiert. Die Integration aller entwickelten Komponenten bildet schließlich das Gesamtsystem.

Analog werden in der aspektorientierten Programmierung drei Entwicklungsphasen beschrieben:

• Aspect Decomposition

• Concern Implementation

• Aspectual Recomposition

In der folgenden Abbildungen werden die einzelnen Phasen gezeigt. Die Zerlegung der Anforderungen in Aspekte und das Weben (engl. „weaving�?) der Aspekte zu einem Endsystem wird metaphorisch dargestellt.

Abbildung 2

Erste Phase: Aspectual Decomposition

In dieser Phase findet die Zerlegung der Anforderungen in die einzelnen Aspekte des Systems statt. Ausgangspunkt sind die an das System gestellten Anforderungen, sowohl die fachlichen als auch die technischen. Die Modellierungsmethodik wird von der aspektorientierten Programmierung nicht vorgeschrieben. Das Zerlegen in einzelne Aspekte wird in der Abbildung 2 durch den concern identifier dargestellt.

Zweite Phase: Concern Implementation

Sobald die Anforderungen in eine Menge von Aspekten zerlegt worden sind, werden diese unabhängig voneinander implementiert. Mit unabhängig ist gemeint, dass die jeweilige Implementierung eines Aspektes kein Wissen über und keinen Zugriff auf andere Aspekte besitzt. So lassen sich die fachlichen Anforderungen definitiv ohne Einwirkung von technischen Aspekten entwickeln. Selbstverständlich sind auch die technischen Anforderungen ohne Einfluss der Fachlogik implementiert. Diese Tatsache führt dazu, dass diese Komponenten wiederverwendbar entwickelt werden können.

Dritte Phase: Aspectual Recomposition

In der letzten Phase werden die Regeln für die Verwebung der einzelnen Aspekte erstellt. Diese Regeln legen die Zusammenarbeit bestimmter Komponenten fest. Der Entwickler definiert nur die Regeln, das zusammengesetzte System wird von der Entwicklungsumgebung erstellt. Diese Tätigkeit wird in der Abbildung 2 durch den Weaver dargestellt.

Anatomie der AOP

Es ist zu beachten, dass AOP keine Implementierung sondern lediglich eine Methodologie darstellt. Analog ist die objektorientierte Programmierung eine Methodologie und Java und Smalltalk sind bekannte Realisierungen.

Eine Realisierung umfasst die Definition der Sprachelemente, der Syntax und das Bereitstellen der benötigten Tools, wie zum Beispiel einen Compiler.

Somit wird von einer AOP Implementierung eine Sprachdefinition und die entsprechende Implementierung erwartet.

Die AOP Sprachdefinition

Eine für die AOP geeignete Sprachdefinition muss folgende zwei Kern­bereiche festlegen. Diese werden in der Literatur „Implementation of concerns“ und „Weaving rules specification“ genannt.

• Implementation of concerns:
  
  Die Sprache, mit der die Komponenten entwickelt werden, da die Hauptaufgabe schließlich nach wie vor die Implementierung der einzelnen Komponenten ist.

  Üblicherweise verwenden AOP Realisierungen an dieser Stelle bestehende Programmiersprachen, wie Java, C++, und Python.

• Weaving rules specification:
  
  An dieser Stelle werden die Sprachelemente für das Integrieren der Aspekte definiert. Die Stärke einer AOP Realisierung zeigt sich darin, wie ökonomisch diese Integration beschrieben werden kann.

Ziele

Die Realisierung einer AOP Sprache muss folgende Arbeit leisten: zuerst müssen die einzelnen Aspekte mittels der definierten Integrationsregeln (engl. „weaving rules“) vermengt werden, und schließlich daraus ausführbarer Code, das Endsystem, generiert werden.

Abbildung 3

Die Abbildung 3 zeigt eine Skizze einer allgemeinen AOP Realisierung. Im Vergleich zu Abbildung 1 sind die einzelnen Komponenten absichtlich einfarbig dargestellt. Die Komponenten werden erst im Endsystem miteinander verwoben.

Üblicherweise werden die Integrationsregeln in eigenen Entitäten abgelegt, wie in Abbildung 3 dargestellt. Der AOP-Compiler, auch weaver genannt, nutzt diese Regeln um das Verhalten des Endsystems zu realisieren, in dem die einzelnen Aspekte entsprechend verwoben werden.

Die Auslagerung der Integrationsregeln in eigene Entitäten ist wichtig. So ist es möglich, zusätzliche Integrationsregeln in das Endsystem einzuflechten, ohne bestehenden Code zu verändern.

Technische und fachliche Aspekte greifen ineinander über: Das Ergebnis ist wieder verwoben. Dieses Problem wird von der AOP nicht gelöst. Es wird lediglich ein besserer Weg zum gleichen Ziel eingeschlagen. Besser in dem Sinn, dass die AOP versuchen will, endlich das Versprechen der objekt­orientierten Methodologie einzulösen: die einzelnen Bausteine eines Systems sollen wartbar und wiederverwendbar sein.

Implementierungen

Die aspektorientierte Programmierung stellt eine Methodologie , aber keine Implementierung dar. Je nach Programmiersprache und Umgebung sind unterschiedliche Implementierungen entstanden.

Die in dieser Seminararbeit verwendete AOP-Implementierung nennt sich AspectJ. Diese wurde von einem Team aus dem Palo Alto Research Center, von Xerox Corporation, dem Eclipse Konsortium gespendet. Die aktuelle Version trägt die Bezeichung AspectJ Version 1.2.

Der Vollständigkeit halber sollen hier noch weitere Implementierungen aufgezählt werden:

AspectC++

http://www.aspectc.org

ist eine Implementierung für die Programmiersprache C++.

AspectWerkz

http://aspectwerkz.codehaus.org

Eine weitere AOP Implementierung für Java. Interessant an dieser Lösung ist, dass das Verweben zur Laufzeit stattfindet.

AspectXML

http://www.aspectxml.org

Dieses Projekt realisiert die AOP Ansätze auf XML Dokumente.

AspectPerl

http://search.cpan.org/~marcel/Aspect-0.08/lib/Aspect/README.pod

Ein Perl- Modul, das AOP für die Perl- Skriptsprache implementiert.

Aspects

http://www.logilab.org/projects/aspects/

Eine AOP Implementierung für Python.

Quelle: http://www.aosd.net

AspectJ: Eine Implementierung von AOP für Java

Die AOP Implementierung AspectJ bietet Java-Entwicklern eine Erweiterung der Java-Programmiersprache. AspectJ ist OpenSource und unter der Mozilla Public License Version 1.1 erhältlich. Plugins für Entwicklungsumgebungen wie Eclipse, Netbeans und JBuilder sind erhältlich.

Mit AspectJ bekommt man eine Dokumentation und Tools wie einen Compiler, einen Aspekte Browser und eine erweiterte Version des Tools Javadoc, dass mit Aspekten umgehen kann. In der mitgeliefertern Doku­mentation befinden sich unter anderem Installationsanleitungen, Referenzen für die Sprach- Erweiterungen und einige Beispiele.Die Plugins für Ent­wicklungsumgebungen müssen separat bezogen werden.

Die Beigabe der Aspektorientierung erfolgt über die Erweiterung des Java-Sprachumfangs um AOP-Elemente, unter anderem das einer Klasse nicht unähnliche Konstrukt aspect. Neben den bekannten Methoden und Attributen definiert ein Aspekt pointcuts und advices.

Grundsätzlich unterscheidet AspectJ zwischen Dynamic Crosscutting und Static Crosscutting.

Bei Dynamic Crosscutting geht es darum, dass die definierten aspekt­spezifischen Methoden das Laufzeitverhalten (dynamisches Verhalten) modifiziert. Im Gegensatz dazu verändert Static Crosscutting die statische Struktur des Programmcodes.

Join Points und Pointcuts

Join Points sind addressierbare Punkte im Quelltext. Beispiele für Join Points sind Methodenaufrufe oder Zugriffe auf Attribute.

public class Dose {
private boolean istOffen = false;
public void oeffnen()
{
istOffen = true;
}
}

Beispiel 2 Beispiel für Pointcuts und Join Points

In obigen Beispiel sind u.a. folgende Join Points zu finden:

• die Ausführung der Methode „oeffnen()“

• der schreibende Zugriff auf das Attribut „istOffen“

Unter Pointcut versteht man schließlich die Addressierung eines oder mehrerer Join Points.

Die zwei oben genannten Join Points könnten durch folgende Pointcuts addressiert werden:

• execution( void Dose.oeffnen() )

• set( private boolean Dose.istOffen )

Join Points sind lediglich Bezeichnungen für addressierbare Punkte im Quelltext, während Pointcuts die tatsächlichen addressierten Punkte darstellen.

Bei der Definition von Pointcuts werden Sprachelemente verwendet, die nicht zum Sprachumfang der Java-Programmiersprache gehören.In der Definition von Pointcuts können auch folgende Platzhalter eingesetzt werden:

„ .. “ für beliebig viele Zeichen

„ * “ für beliebig viele Zeichen ausser einem Punkt

„ + “ für beliebige Spezialisierungen einer Klasse oder eines Interfaces

AspectJ bietet ein umfangreiches dynamisches Join Point Modell. Die folgenden Beispiele sollen im Groben einen Eindruck über den Umfang vermitteln.

Das Ausführen einer Methode:

execution( void Dose.oeffnen() )
execution( int *() )

Das Aufrufen einer Methode:

call( void Dose.oeffnen() )
call( * *( long ) )

Das Catchen bzw. Behandeln einer Exception:

handler( RemoteException )
handler( RuntimeException+ )

Der Ausführende eines bestimmten Typs ist:

this( Dose )

Der Aufgerufene eines bestimmten Typs ist:

target( Dose )

Der ausgefürte Code eines bestimmten Typs ist:

within( meine.servlets.* )

Der ausgeführte Code, der von einer bestimmten Methode
aufgerufen wurde (engl. „call flow“) – inklusive oder
exclusive der aufrufende Methode:

cflow( Dose.oeffnen() )
cflowbelow( Dose.oeffnen() )

Initialisierung eines Objekts:

initialization( Dose.new(..) )

Aufruf der Konstruktors „super“ eines Objektes:

preinitialization( Dose.new(..) )

Wenn der Klassenkonstruktor aufgerufen wird:

staticinitialization( Dose )

Das Lesen oder Schreiben von Instanzattribute:

get( Dose.istOffen )
set( Dose.istOffen )

Advices

Advices definieren die aspektspezifischen Code-Erweiterungen. Advices beziehen sich auf Pointcuts und werden an den entsprechenden Stellen durch den AOP Compiler hinzugefügt.

Die Syntax eines Advices ähnelt sehr der Syntax eines Methodenaufrufs. Der Unterschied besteht lediglich darin, dass ein Advice noch definieren muss, wann dieser Code ausgeführt werden soll:

• before: vor dem definiertem Pointcut,

• after: nach dem definiertem Pointcut oder

• around: um den Pointcut herum.

Somit kann der Entwickler vor dem Aufruf der Methode „void oeffnen()“ ein zusätzliches Verhalten implementieren:

Innerhalb eines Advices werden die impliziten Variablen

• thisJoinPoint

• thisJoinPointStaticPart

• thisEnclosingJoinPointStaticPart

dem Entwickler zur Verfügung gestellt. Somit bekommt der Entwickler dynamisch Zugriff auf dem Kontext der aus dem entsprechendem Pointcut entstanden ist. Die Kontextinformationen basieren auf der Java-Reflection API, so dass der Entwickler sich nicht in ein neues Objekmodell einarbeiten muss.

Aspects

Aspects sehen auf dem ersten Blick wie Java-Klassen aus. Sie können Attribute und Methoden wie eine übliche Java-Klasse definieren. Zusätzlich können aspects noch Pointcuts und Advices defnieren.

public aspect LoggingAspect
{
public pointcut logPoints() :

execution( void Dose.oeffnen() );

before() : logPoints()
{
System.out.println(„Dose wird geöffnet“);
}
}
Beispiel 4 LoggingAspect für die Dose

Im Gegensatz zu Klassen können Aspects nicht instanziiert werden. Aspects bilden die Entitäten, in denen die Integrationsregeln schließlich festgehalten werden.

Weitere Möglichkeiten im Überblick

Mit Pointcuts und Advices sind die Sprachelemente für dynamisches Crosscutting definiert worden. AspectJ bietet zusätzlich noch die Möglichkeit, die statische Struktur einer Klasse zu beeinflussen. So kann man Klassen, neue Attribute und Methoden vergeben. Das ist besonders dann wichtig, wenn die neuen Aspekte eigene Zustände in den Instanzen verwalten müssen.

Im Beispiel 5 wird ein Attribut und eine Methode der Klasse Dose hinzugefügt. In dem Advice wird schließlich auf die eingefügte Methode zugegriffen. In der Pointcut Definition werden auch die Parameter definiert, die später dem Advice zur Verfügung gestellt werden sollen. Eingefangen wird die Doseninstanz in dem Pointcut durch das Sprachelement „this( )“.

public aspect LoggingAspect {
private Date Dose.oeffnungsDatum = null;
public Date Dose.getOeffnungsDatum() {
if (oeffnungsDatum == null)
oeffnungsDatum = new Date();
return oeffnungsDatum;
}

public pointcut logPoints(Dose dose) :
execution( void Dose.oeffnen() )
&&
this(dose);

before(Dose dose) : logPoints()
{
System.out.println(„Oeffnungsdatum: “+dose.getOeffnungsDatum();
}
}

Beispiel 5 LoggingAspect für die Dose

AspectJ bietet auch die Möglichkeit, Compiler-Fehler und -Warnungen zu definieren. Diese Fehler und Warnungen werden auch an Pointcuts gebunden. So kann man wie im Beispiel 6 gezeigt wird, eine Warnung defnieren, dass der Entwickler nicht in die Konsole schreiben soll, sondern die Logging-API verwenden soll.

declare warning : get(* System.out) : „Bitte die Logging API verwenden“
Beispiel 6 Compilerwarnungen definieren

Über diesen Mechanismus kann die Einhaltung einiger Programmierstandards innerhalb eines Projektes erzwungen werden.