J2EE ohne EJB?! -...

J2EE ohne EJB?!

Leichtgewichtige Komponentenframeworks in der J2EE

Karsten Queißer Christian Schröder

J2ee ohne EJB?! 2 / 26 www.unilog-avinci.de

Agenda

J2EE

Komponenten

Grundlagen

Leichtgewichtige Komponentenframeworks

Bewertung

Ausblick


J2EE


Was sind Komponenten?

grundlegende EigenschaftenTeil einer ZusammenstellungBesitzt festgelegte SchnittstellenBesitzt definierte Abhängigkeiten/definierte UmgebungIst unabhängig einsetzbarBenötigt eine externe Umgebung um zu arbeiten

Verwendet eigenes Wissen um ihre Aufgabe zu erledigen

„A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. A software componente can be deployed independently and is subject to composition by third parties.“ – Clemens Szyperski


Vorteile von Komponenten

Partitionierung des ProblemsLose Kopplung Design-by-Contract

VerbesserteWartbarkeit

Wiederverwend-barkeit


Marktplatz

Komponenten-bibliothek

Entwickler wählt die passenden KomponentenEntwickler ergänzt evt. fehlende KomponentenEntwickler verbindet die Komponenten miteinanderEntwickler initialisiert die Komponenten für das Problem

Komponentenorientierte Entwicklung

AuswählenVerbindenEinrichten

Konfiguration

Anwendung


Aufgaben eines Komponentenframeworks

Initialisierte Komponenten erzeugenWirkung als „Abstrakte Fabrik“

Komponenten verknüpfenLebenszyklus überwachen

Erzeugung und Zerstörung

„It is far too simplistic to assume that components are simply selectedfrom catalogs, thrown together, and magic happens. In reality, dhedisciplined interplay of components is one of the hardest problems of software engineering today.“ – Clemens Szyperski


Entwicklung mit einem Komponentenframework

Entwickler beschreibt Komposition der KomponentenEntwickler beschreibt Initialisierung der KomponentenFramework übernimmt programmatische Verbindung

Marktplatz

Komponenten-bibliothek

AnwendungKomponentenframework

DeklarativeKonfiguration


Hohe Integration in den Container

Hohe AbhängigkeitSchwer testbar (Unit Test)

Nicht vorgesehen in Spezifikation

Striktes Programmiermodell

An EJB-API gebundenDesigneinschränkungen

Vererbung nötig eingeschränktes Domänenmodell

Aktuelle EJB Spezifikation

EJB-Container

EJB-API

J2EE Application Server

J 2 E E

S e r v i c e s

Deskriptoren

EJB

EJBEJB


Sinnvolle Erweiterungen von EJBs?

einfache Komposition der KomponentenExtern und zentral konfigurierbar

einfache InitialisierungTestbarkeit der Komponenten bewahren

Komponenten unabhängig von kompletter Laufzeitumgebung verwendbarAbhängigkeiten von der Komponente fernhalten

zurückhaltende APIKeine VererbungKeine oder nur einfache InterfacesKeine komplexen Nebenbedingungen

POJO

Dependency

Injection


Komponenten

Komponentenframework

EJB Schwächen

Verbesserungen


Was ist ein POJO?

Plain Old Java Object = POJO„Einfaches“ Java-Objekt

Keine fachfremden SchnittstellenKeine fachfremden ProgrammiermetaphernKein Teil eines Frameworks

ZielKonzentration/Fokussierung auf fachliche ProblemstellungVermeidung unnötiger Einschränkungen und Abhängigkeiten in der fachlichen Ebene

Begriff geht auf Martin Fowler zurück


Was ist Dependency Injection (DI)?

Form der Inversion of Controlbezogen auf die Umweltkomposition einer Komponente

Abhängigkeiten werden von außen erfüllt„Hollywood Principle“

Don‘t call us, we call you.

ZielEntkopplung der Komponente von ihrer UmgebungReduktion des notwendigen Wissens über die Umgebung

Ohne Dependency

Injection

Mit Dependency

Injection


Was zeichnet ein leichtgewichtiges Komponentenframework aus?

Nicht-invasive (zurückhaltende) APIKeine weiteren Interfaces oder Vererbungsstrukturen

Komponenten als POJOFrameworklose Nutzung möglich

Verwendung von Dependency InjectionIsolierung voneinanderKlare Trennung der Belange

Verantwortlichkeit für Umgebungserfüllung übernimmt das FrameworkVerantwortung für Umgebungsnutzung liegt innerhalb der Komponente

Konfigurierbare KompositionAuflösung zirkulärer AbhängigkeitenUnterstützung für Komponentenlebenszyklen


Picocontainer

Ziel / AnspruchEinfaches Komponentenframework mit einer nicht-invasiven API

MittelPOJODependency Injection

GrundkonzeptContainer der über die Implementierungen informiert wirdKonfiguration im JavaCodeSelbständiges Auflösen von Abhängigkeiten

Nanocontainer ist eine Erweiterung des PicocontainersExterne Konfiguration (XML, Groovy, Jython)AOP UnterstützungAdapter für Hibernate als OR-Mapper


Spring

Ziel / AnspruchFlexibles Anwendungsframework mit einem Komponentenframework als Basis

MittelPOJODependency InjectionAdapterkomponenten für vorhandene TechnologienUnterstützung für Aspektorientierung

GrundkonzeptXML-Konfigurationsdatei als Basis mit benannten KomponentenKomposition wird festgelegtAdapterklassen für viele Drittanbietertechnologien (Hibernate, iBatis, Quartz, Velocity, …) die als Komponente konfiguriert werden


Spring Überblick


EJB 3.0

ZielKomponentenframework der J2EE„Vereinfachung aus Sicht des Entwicklers“

MittelDependency Injection über JNDI Lookups

eher Workaround als Lösungkeine Deskriptoren, dafür Java 5 Annotations

KonzeptPOJO Komponenten

wird nicht eingehalten (Annotations Abhängigkeit von EJB-API)


Bewertung Pico

Zielgerichtete ImplementierungSehr kleine Bibliotheken im Vergleich mit Mitbewerbern

Einfache und unkomplizierte NutzungLeicht integrierbar in bestehende Softwarelandschaften und –systeme

Konfiguration in JavaKein Kontextwechsel zu XML

Picocontainer ist klein und schnell einsetzbarAuch wenn die Größe kein ausschlaggebendes Kriterium ist, so ist Picocontainer für Prototyping sehr gut geeignet


Bewertung Spring

Basis Funktionalität: Management der Business ObjekteUmfassend und trotzdem modular

auch in Teilaspekten (z.B. zunächst nur als Vereinfachung von JDBC) einsetzbarstep-by-step integrierbar

Gute TestbarkeitHohe Akzeptanz im Markt, zunehmend auch Herstellerunterstützung

Umfangreiches Anwendungsframework, welches keinen großen fachfremden Einfluss auf die Anwendung ausübt


Bewertung EJB 3.0

Standard noch nicht verabschiedetEarly draft review 2

Noch nicht verfügbar, 2007 ist angestrebt für zertifizierteImplementierungen


J2EE ohne EJB


Marktüberblick

Apache AvalonEingestellt, aufgegangen in Excalibur und Loom

CarbonKomponentenframework und Serviceplattform

HiveMindKomponentenframework als MikroKernel aufgefasst

KeelApplikationsframework mit grundlegenden nicht-fachlichen Diensten

PicoContainer / NanoContainerKleine zielgerichtete Implementierung eines Komponentenframeworks

SpringApplikationsframework mit Adaptern für verschiedene Drittanbietertechnologien


Warum eigentlich nicht?

Auswirkung auf Entwicklung und Architektur geringMehraufwand geringDirekte Einsparung in der Entwicklung des GlueCodesEine sehr freie Designmethode für die Komponenten wird vorgegeben (POJO)

Komponenten ohne großen MehraufwandWiederverwendbarkeitFlexibilitätDesign-by-contract


Ende

Vielen Dank für Ihre Aufmerksamkeit.

Fragen?Diskussionen!


Finale Grande


Dependency Injection I(Constructor Injection)

Konstruktor mit den Parametern für alle AbhängigkeitenVorteile

Klar erkennbare AbhängigkeitenKonsistenter Zustand ist garantiert

NachteileProblematisch in VererbungshierarchienZirkuläre Abhängigkeiten verursachen Mehraufwand zur Auflösung

public interface Service { /*Serviceschnittstelle*/ }

public interface Komponente { /*Komponentenschnittstelle*/ }

public class KomponentenImpl {

Service service;

public KomponentenImpl(Service serviceInjected) {

this.service = serviceInjected;

}

}


Dependency Injection II(Setter Injection)

Setter Methoden für alle AbhängigkeitenVorteile

Sehr flexibelbenannte Abhängigkeiten erhöhen die Verständlichkeit

NachteileInkonsistente Zustände möglich




Service service;

public void setService(Service serviceInjected) {


}

}


Setter Injection vs Constructor Injection




Service service;

public void setService(Service serviceInjected) {


}

}




Service service;

public KomponentenImpl(Service serviceInjected) {


}

}


zirkuläre Abhängigkeiten

Problem: Constructor Injection kann zirkuläre Abhängigkeiten nicht auflösen

Zur Erstellung von Komponenten A ist eine Komponente B nötig, um diese zu erstellen benötigt man jedoch Komponente A

InjectionDelegation


Java 5 Annotations

Metadaten, Informationen über den QuellcodeÄndern nicht die Semantik des Programms

Sind als Anweisungen für den Compiler, für andere Werkzeuge oderLaufzeitumgebungen zu verstehen

Dadurch nehmen sie indirekt Einfluss auf die Semantik des ProgrammsKönnen im Sourcecode, im Binärcode und zur Laufzeit ausgelesen werdenMüssen importiert werden wie normale Java-Klassen

Typprüfung durch Compiler möglich, Quellcodeabhängigkeit

@deprecated Javadoc gibt es schon seit Java 2Erzeugt eine Compilerwarnung obwohl es in einem Kommentar stehtEinfluss von Nicht-Sourcecode auf die ProgrammerzeugungVorläufer der neuen Java 5 Annotations

J2EE ohne EJB?! -...

Documents

Transcript of J2EE ohne EJB?! -...