Begrüßung

In der Begrüßung vermittelte Margret Mergen (Bürgermeisterin der Stadt Karlsruhe) viele interessante Fakten zu Karlsruhe. Sie bezeichnete die Stadt als das “Silicon Valley Deutschlands” und nahm damit Bezug auf die räumliche Nähe der über 3.000 IT Firmen mit über 25.000 ITlern. Ebenfalls interessant war die Tatsache, dass jede vierte Informatiker aus Karlsruhe kommt.

Freundliche Eindringlinge – Moderne Web-Applikationen mit CDI

Wie den Teilnehmern des Entwicklertages versprochen, möchte ich an dieser Stelle die Tonspur und die Beispielapplikation zur Verfügung stellen. Da ich bereits darüber gebloggt habe, veröffentliche ich hier nur den Link zu meinem Beitrag Freundliche Eindringlinge – Moderne Web-Applikationen mit CDI.

Zum Vortrag kann ich nur sagen, dass es Spaß gemacht hat, ihn in den schönen Räumen der IHK Karlsruhe halten zu dürfen und dass ich auch das Glück einer aktiven Zuhörerschaft mit spannenden Fragen hatte.

Freundliche Eindringinge @ Entwicklertag 2012

Rechtliche Aspekte zu Cloud Computing

Prof. Dr. Rupert Vogel, Tobias Haar und Dr. Oliver Meyer-van Raay beleuchteten die rechtlichen Aspekte zum Thema Cloud. Nach der Definition des Cloud-Begriffs, den Ausprägungen (IaaS, PaaS, SaaS) und der Erkenntnis, dass es sich beim Thema Cloud Computing nicht um einen Rechtsbegriff handelt, wurden alle relevanten Rechtsbereiche erörtert.

IT-Recht

Sofern es sich um eine B2B-Beziehung handelt, kann die Rechtswahl selbst übernommen werden, d.h., ich kann mir ein Land aussuchen, gemäß dessen Rechtsprechung ich agieren möchte. Als Tipp wurde genannt, dass immer der Kunde auf Rechtswahl drängen sollte.

Handelt es sich jedoch um eine B2C-Beziehung, muss nach Recht des Verbrauchers verfahren werden, also nach dem Recht, das am günstigsten für den Verbraucher ist. Hier spielt in der Regel das Land, in dem der Verbraucher firmiert, eine Rolle. Ebenfalls interessant dazu ist, dass im Zweifelsfall das Recht des Landes, in dem der Schaden eintritt, gilt.
Zum Thema Vertragsgestaltung wurde erwähnt, dass es sich um Mietverträge nach deutschem Recht handelt, sodass der Vermieter für die Leistung verantwortlich ist. Um auf der sicheren Seite zu sein, müssen Service Level Agreements vereinbart werden. Spannend ist auch das Thema “Exit Management”. Wir wird mit Daten verfahren?

Zur Vertragsgestaltung wurde der Tipp gegeben, den Vetrag immer so zu gestalten, dass ein 60jähriger Richter diesen auch verstehen kann. Also nicht “Leistung 98% verfügbar”, sondern lieber alles detailliert beschreiben. Was ist denn beispielsweise “die Leistung”? Und was heißt “verfügbar”?

Ein Blick in das Amazon Web Services Customer Agreement zeigte, dass Amazon den Service einfach mal abschalten kann…

Urheberrecht

Beim Urheberrecht sind in der Regel drei Parteien betroffen. Der Kunde, der Cloud-Anbieter und das Software-Haus. Aufgepasst werden muss vor allem im Bereich des Software-Hauses. Wurde eine Lizenz für die Cloud erworben? Wie sieht es mit der Handhabung von Vervielfältigungen aus? Ist es nicht eine Vermietung, wenn ich die Software in der Cloud zur Verfügung stelle? All dies muss zwischen den Parteien vereinbart werden.

Wie steht es um Software, die ein Angestellter oder ein Freelancer für ein Unternehmen entwickelt hat? Kann diese einfach in die Cloud gehen? Beim Angestellten ist das recht einfach, hier hat der Arbeitgeber Verwertungsrechte. Bei Freelancern ist das ein wenig schwieriger, weil hier unter Umständen eine neue Nutzungsart hinzukommt.

Datenschutz/-sicherheit

Hier gilt das Territorialitätsprinzip, also die Rechtsprechung des Landes in dem die Daten verarbeitet werden. Problematisch wird das Ganze natürlich nur bei personenbezogenen Daten. Hier muss eine Anonymisierung stattfinden und optimalerweise auch noch eine Verschlüsselung, damit die Cloud-Anbieter diese Daten nicht im Zugriff haben. Spannend wird es auch beim Thema der Auftragsdatenverarbeitung: hier sollte man sich einen geeigneten Anbieter á la Microsoft oder Salesforce, die den Richtlinien der EU entsprechen, suchen.

Mehr dazu kann in den Vortragsfolien auf der Webseite des Entwicklertages 2012 nachgelesen werden.

In der Fragerunde zum Vortrag wurde noch erwähnt, dass man im rechtlichen Sinne nicht vom Besitz von Daten sprechen kann, sondern nur vom Zugriff.

Rechtliche Aspekte zu Cloud Computing @ Entwicklertag 2012

Software Engineering von Mobile Apps

Stefan Hellfeld zeigte sehr schön die Entwicklung der mobilen Endgeräte an seiner eigenen Handy-Historie auf. Danach machte er darauf aufmerksam, wer eigentlich aktuell die Software für mobile Endgeräte verkauft: Betriebssystem- und Gerätehersteller. Auch erfunden hat das Ganze nicht Apple mit dem App Store, sondern Nokia mit Symbian schon einige Jahre zuvor.

Was?

Was ist das größte Problem, wenn man eine Software in den App Store bringt? Die Konkurrenz! Wie kann man sich, abgesehen vom Preis, von seinen Konkurrenten absetzen? Durch Innovation! Wie diese Innovation vorangeschritten ist, zeigt die Gegenüberstellung einiger Features des Smartphones (GSM, GPRS, Kamera, Bewegungssender) gegenüber verschiedenen Features von Software (Virtuelle Realität, Wecker, Aufzeichnung, MP3-Player). Hier steht es 9:26 für die Software. Herr Hellfeld legte nahe, sich als Entwickler von Mobilen Apps als Integrator zu sehen und so mehrere Hardwarekomponenten für die Lösung eines Problems zu verknüpfen.

Wie?

Da wir jetzt wussten, was wir zu programmieren hatten, stellte sich natürlich die Frage nach dem Wie. Hier verglich Herr Hellfeld die mobile Entwicklung für iOS mit der klassischen Software-Entwicklung. Bei letzterer wurden in der Regel Lizenzen für IDEs gekauft und fertig war man, was die Ausgaben im Entwicklungsprozess anging. In der mobilen Entwicklung ist die IDE zwar kostenlos (sofern man einen Mac hat), aber man braucht Lizenzen für die Entwickler, muss auf externen Geräten testen und die Software dann auch noch im App Store zur Abnahme einreichen.

Zukunft iOS, Android, Windows Phone & JavaME

Es gibt schon jetzt mehr Smartphones als Handys. Android Apps sind im Schnitt teurer als iOS Apps, und JavaME liegt hinsichtlich des Marktanteils noch 15% hinter iOS und Android. Herr Hellfeld ist der Meinung, dass iOS weiter wachsen wird, Android auch – und zwar stärker – und Microsoft wird es zukünftig mit den beiden aufnehmen, da es noch keine richtige Office-Integration auf iOS oder Android gibt und es Windows Phone noch an Tablets fehlt.

Organisation

Was wird alles benötigt, um starten zu können? Eine Entwicklungsumgebung und ein SDK, ein Team, wobei sich die optimale Anzahl Mitarbeiter seiner Ansicht nach aus der Wurzel der Projektdauer in Personentagen ermittelt. Ferner benötigt man ein gutes Management, bei dem Enwickler 16 LOC (lines of code) pro Tag schaffen, die direkt in der Software verwendet werden, ein Vorgehensmodell und jede Menge Testgeräte. Es gibt zwar Simulatoren, aber diese ersetzen nicht die Tests auf Endgeräten.

Sicherlich neu in der mobilen Entwicklung ist die Rolle des Kunden, da man hier jetzt mit “Experten” redet, die genau wissen, wie eine mobile App auszusehen und wie sie sich anzufühlen hat.

Nativ, WebApp oder Hybrid?

Die Abgrenzung der unterschiedlichen App-Typen ist ja mittlerweile in aller Munde. Interessant ist jedoch Herr Hellfelds Abgrenzung im Detail. Native Apps sind bei ihm Apps, die nativ programmiert wurden, bei denen sich jedoch auch alle Daten auf dem Smartphone befinden. Hybrid sind bei ihm einerseits die Lösungen, die via Titanium oder PhoneGap auf beliebig viele Plattformen gebracht werden können, als auch Apps, die nativ implementiert wurden, aber ihre Daten aus dem Internet beziehen.

Als Best-Practice-Beispiele nannte er die Apps von Facebook und N-tv, die beide auf eine hybride Lösung setzen. Die UI-Elemente sind nativ implementiert, da sie flüssig sein müssen; die Informationsdarstellung erfolgt in Webviews.

Als gutes Feature von iOS wurde erwähnt, dass man es geschafft habe, auch Apps elegant abstürzen zu lassen, so dass sich der Nutzer selbst hinterfragt, bevor er davon ausgeht, dass die App fehlerhaft ist.

Spannend war auch ein Vergleich der Effizienz der Entwicklung zwischen iOS (Xcode) und Windows Phone (Visual Studio mit Expression Blend). So bräuchte man in Xcode für die Entwicklung einer Taschenlampen-App 80 Sekunden und in Visual Studio nur 32 Sekunden.

Zukunft der Apps

Apps sind in der Zukunft agil, sie passen sich an Anwender, Kontext, Gerät und Informationskanal an, sie sind intelligent, denken mit und treffen banale Entscheidungen, und darüber hinaus bilden sie Menschen auf Informationssystemen ab.
Software Engineering von Mobile Apps @ Entwicklertag 2012

Entspannte Nebenläufigkeit – Aktoren in Scala und Java

Andi Scharfstein und Ben Romberg motivierten Aktoren mit dem “Northeast blackout of 2003″. Als Ursache wurde eine Race Condition identifiziert. Um Race Conditions zu vermeiden, sollen Aktoren eingesetzt werden. Es muss also, getreu dem Aktoren-Paradigma, Datenfluss nur in gekapselten Systemen agiert werden.

Aktoren haben dabei einen eindeutigen Namen (Adresse), ein Verhalten (Code), einen Zustand (Daten) sowie eine Mailbox. Aktoren können Nachrichten verschicken, den eigenen Zustand bzw. ihr Verhalten ändern und neue Aktoren erstellen. In der Theorie laufen Aktoren parallel zueinander; es gibt keine Aussage zum Nachrichtenverhalten, und somit können Nachrichten theoretisch verloren gehen oder auch ihre Reihenfolge verändern.

In einem Bespiel, in dessen Rahmen Spielstände von Mannschaften verändert wurden (ja, es ist ja bald EM), wurde das Akka-Framework vorgestellt.

Für den Einsatz wurde vorgeschlagen, dass über Nachrichten kommuniziert werden soll und Nachrichten nur als immutable Objekte verwendet werden sollen, um Race Conditions zu vermeiden.

Als Fazit machten die Vortragenden Werbung für den Einsatz von Aktoren, da der Einarbeitungsaufwand gering sei, man nur seine Herangehensweise ändern müsse und so sehr performante nebenläufige Applikationen ohne Race Conditions bauen könne.

Mich haben die Jungs überzeugt und ich werde den nächsten passenden Anwendungsfall mal mit Aktoren umsetzen.

Entspannte Nebenläufigkeit – Aktoren in Scala und Java @ Entwicklertag 2012

Subjektorientorierung

Albert Fleischmann hat ein neues Modell für den Softwareentwicklungsprozess entwickelt. Eingangs rief er den Zuhörern den deutschen Satzbau im Aktiv mit Subjekt, Prädikat und Objekt ins Gedächtnis (Wer macht was womit?) Im Vergleich dazu skizzierte er unterschiedliche Modelle der Softwareentwicklung (Flussdiagramm, ER-Diagramm, UML etc.), die im nicht ausreichenden Maße Subjekt, Prädikat und Objekt beschreiben. Sein Anliegen war es, Anwender für die Subjektorientierung zu motivieren. Als Fallbeispiel stellte er die Steuerung eines ferngesteuerten Vogels vor, die er später in ein Bespiel zu einem Transportunternehmen verwandelte. Spätestens hier hatte er mich leider komplett abgehängt. Als nach 40 Minuten Motivation innerhalb von fünf Minuten das Modell vorgestellt werden sollte, konnte ich leider nicht mehr das Konzept und den Nutzen der Subjektorientierung verstehen. Falls die Folien online gestellt werden, werde ich auf jeden Fall noch mal hineinschauen.

Subjektorientierung @ Entwicklertag 2012

Fazit

Für mich eine sehr gelungene Veranstaltung – von der Organisation über die Referenten bis hin zum Veranstaltungsort. Dafür möchte ich mich bei den Veranstaltern und Referenten herzlich bedanken, und vielleicht bin ich ja nächstes Jahr auch wieder dabei.

Vortragsfolien

Tonspur

Mit der JSR 299 hat CDI Einzug in den Java EE-Standard gehalten. Doch was ist dieses CDI eigentlich, was bezweckt es, welche Neuerungen bringt es und wie kann ich diese in meiner Java Enterprise-Applikation (EJB-Applikation) nutzen?

Motivation – JSR 299

Dependency Injection (DI) hat schon vor langer Zeit Einzug in Java-Applikationen gefunden. Dabei mussten sich Architekten und Entwickler immer Frameworks wie Spring oder Seam bedienen. Um diesen Umstand aus der Welt zu schaffen, war es Ziel des JSR 299, ein umfassendes DI Framework im Java EE-Standard zu etablieren. Außerdem sollte eine Standardisierung und Vereinfachung des Zusammenspiels zwischen EJB und JSF erreicht werden, d.h., die Geschäftslogik sollte einfacher in die Präsentationsschicht integriert werden können.

Ich nehme an dieser Stelle mal eines vorweg: Beide Ziele hat die JSR 299 Expert Group mit der Spezifikation “Contexts and Dependency Injection for the Java EE platform” (CDI) erreicht.

Neuerungen – Was bietet CDI?

Dank CDI wird der Java EE-Standard um folgende Funktionalitäten erweitert:

• Dependecy Injection-Mechanismus
• Deklarative Verknüpfung von Beans
• Scope zwischen Request und Session
• Entkopplung von Interzeptoren
• Dekoratoren
• Beanverwaltung zur Laufzeit

Bean-Verständnis – Beans

Von einer Bean wird bereits bei JSF, EJB und Spring gesprochen, ohne jedes Mal dasselbe zu bezeichnen. Auch CDI spricht von Beans, und auch in dieser Spezifikation herrscht ein eigenes Verständnis davon, was unter einer Bean verstanden wird.

CDI meint: “Eine Bean ist ein Objekt, dessen Lebenszyklus vom Container verwaltet wird.”

Folglich ist jedes dem CDI-Container “bekannt gemachte” Objekt eine Bean im Sinne von CDI. Dabei werden zwei Typen von Beans unterschieden:

• Managed Beans
• Session Beans

Managed Beans

Damit der Lebenszyklus eines Objekts von CDI verwaltet werden kann, muss dieses Objekt einen parameterlosen Konstruktor besitzen oder einen, der mit der Annotation @Inject versehen ist. Erfüllt ein Objekt eines dieser Kriterien, wird sein Lebenszyklus und die mit dem Scope verbundene Abhängigkeit der Bean vom CDI Container verwaltet.

Session Beans

Session Beans sind streng genommen auch Managed Beans, so dass für sie auch die gleichen Kriterien gelten. Bei Session Beans kommt jedoch hinzu, dass ihr Lebenszyklus vom EJB Container verwaltet wird und sie ein eigenes Statusmanagement- und Nebenläufigkeitsmodell besitzen. Stateless und Singleton Session Beans sind scopeless, es braucht ihnen also kein CDI-spezifischer Scope zugewiesen werden. Stateful Session Beans hingegen muss ein Scope explizit zugewiesen werden.

CDI kann somit sofort mit den scopeless EJBs arbeiten, ohne dass diese angepasst werden müssen.

Nicht Beans

Nicht Beans im Sinne von CDI sind Message-Driven Beans, Interzeptoren, Servlets, JAX WS Services, JSP Tag Handler und Tag Library Event Listener. Diese müssen aber nicht ganz auf die Funktionalitäten von CDI verzichten und können zumindest Beans injiziert bekommen.

Konzepte

Container, Kontext & Scope

Container, Kontext und Scope sollten für Entwickler keine vollkommen neuen Begriffe sein, da diese jedoch für das Verständnis von CDI von Bedeutung sind, hier eine kurze Erläuterung.

Bei CDI ist der Container für die Verwaltung des Lebenszyklus der an einen Kontext gebundenen Objekte zuständig. Dieser Kontext beschreibt die Beziehungen der verwalteten Objekte zueinander. Der Scope definiert die Sichtbarkeit bzw. Lebenszeit der von CDI im Container verwalteten Objekte.

DI

Dependency Injection ist an sich nichts Neues, aber sie wird mit CDI in den Standard von Java-EE-Applikationen und auch Java-SE-Appliakationen gehoben. Die Annotation @Inject ist für die DI zuständig.

Typsichere Auflösung

In CDI findet ein Typesave-Resolution-Algorithmus Anwendung. Wird also eine Bean injiziert, dann wird immer der passende Typ an diese gebunden. Erfolgt keine genauere Spezifizierung durch Qualifier oder Alternativen, wird immer die Default-Implementierung genommen – folglich eine Bean vom passenden Typ.

Lose Kopplung

Eine lose Kopplung wird erreicht, wie üblich bei Web-Applikationen, durch eine Trennung von Client und Server, die neuen unterschiedlichen Scopes (Lebenszyklen) und die Realisierung von Produzenten und Konsumenten, auf die im Praxisteil noch detaillierter eingegangen wird.

Interceptor-Binding und Dekoratoren

CDI bietet ein neues Konzept, um Interzeptoren an Beans zu binden und erreicht auch damit eine Entkopplung. Dekoratoren sind eine Umsetzung des Decorator-Patterns und ermöglichen es, Methoden um Geschäftslogik zu erweitern.

SPI

SPI stellt für Entwickler eine Schnittstelle zur Verfügung, um leichter eigene Dienste in CDI-Applikationen zu integrieren.

In der Praxis

Es gibt mittlerweile mehrere Implementierungen von CDI. In dieser Blogserie wird die Referenzimplementierung Weld von JBoss eingesetzt. Sie stellt Werkzeuge wie DI, Scopes, EL-Namen, Interceptor-Bindings, Dekoratoren und Produzenten zur Verfügung.

Um mit CDI starten zu können, muss in einer Applikation lediglich der CDI Deployment-Deskriptor angelegt werden, die beans.xml. Möchte man seine Applikation als .war-Datei deployen, so muss diese im Verzeichnis WEB-INF liegen. Bei als .jar-Datei zu deployenden Applikationen gehört die beans.xml in das Verzeichnis META-INF. Die unter einem der beiden Verzeichnisse abgelegte beans.xml kann dabei leer sein.

Gut zu wissen ist an dieser Stelle auch, dass sich CDI nicht auf den Einsatz in Java EE-Applikationen beschränkt, sondern auch unter Java SE angewendet werden kann.

Dependency Injection

Wie bereits unter dem Punkt Session Beans erwähnt, können scopeless EJBs sofort von CDI genutzt werden. Genau das wird im folgenden Code getan.

Wir haben folgende EJB gegeben:

@Stateless
public class BlogServiceBean implements BlogService {
 ...
}

Diese kann jetzt direkt mit der Annotation @Inject in eine Bean injiziert werden.

public class InvasionController {
 @Inject
 private BlogService blogService;
 ...
}

Qualifier

Qualifier sind dazu da, bei mehreren Implementierungen eines Typs genau zu definieren, welche konkrete Implementierung von CDI injiziert werden soll. Dazu muss zunächst ein entsprechender Qualifier definiert werden bzw. eine mit @Qualifier annotierte Annotation.

@Qualifier
@Target({TYPE, METHOD, PARAMETER, FIELD})
@Retention(RUNTIME)
public @interface Holisticon {}

Die für Annotationen typischen Meta-Annotationen @Target und @Retention legen fest, was mit der definierten Annotation annotiert werden darf und wann die Auflösung der Annotation erfolgt.

Eine Stateless Session Bean wird mit diesem Qualifier annotiert.

@Holisticon
@Stateless
public class HolisticonBlogServiceBean
    implements BlogService {
  ...
}

Und um auch die gewünschte Bean zu injizieren, wird der genutzte BlogService ebenfalls mit dem Qualifier annotiert.

public class InvasionController {
  @Inject @Holisticon
  private BlogService blogService;
  ...
}

Würde bei mehreren Implementierungen des BlogServices auf einen Qualifier verzichtet werden, so würde Weld den Start des Containers verweigern und folgende Exception werfen:

WELD-001409 Ambiguous dependencies for type [BlogService]
with qualifiers [@Default] at injection point ...

Der in der Exception erwähnte Qualifier @Default wird implizit gesetzt, wenn die Bean nicht explizit einen Qualifier bekommen hat.

Alternativen

Mittels Alternativen kann zur Deployment-Zeit festgelegt werden, dass anstatt der eigentlichen Implementierung eines Typs eine alternative Implementierung genutzt wird. Diese Alternative hat den Qualifier @Alternative und muss im CDI Deployment-Deskriptor, der beans.xml, aktiviert werden.

Die alternative Implementierung von BlogService soll ein Mock sein.

@Alternative
public class BlogServiceMock implements BlogService{
  ...
}

In der beans.xml wird die Alternative wie folgt aktiviert.

    de.holisticon.blog.friendlyInvaders.service.mock.BlogServiceMock

Wie das Codebeispiel suggerieren soll, sind diese Alternativen besonders nützlich, wenn es um das Testen einer Applikation geht.

EL-Namen

Die einfachste Variante, eine Bean dem CDI-Kontext hinzuzufügen, ist, sie mit @Named zu annotieren. Diese Annotation ermöglicht, dass eine Bean direkt in der Präsentationsschicht, wie z.B. einer JSF-Seite, angesprochen werden kann.

Zunächst wird ein Controller mit @Named annotiert.

@Named
public class InvasionController{
  @Inject @Holisticon
  private BlogService blogService;
  ...
}

Ist eine Bean mit @Named annotiert, so ist sie mit ihrem Namen in der EL ansprechbar. Zu beachten ist, dass der Name hierbei immer mit einem kleinen Buchstaben beginnt. Der EL-Name der annotierten Bean ist hier invasionController, wie im folgenden Auszug einer JSF-Seite.

  #{blogArticle.title}

Gefällt der automatische EL-Name der Beans nicht, so hat man die Möglichkeit, ihnen auch Namen via Annotation zuzuweisen (z.B. @Named (“MeinName”)).

Scopes

Auch bei CDI gibt es Scopes, die die Lebenszeit von Objekten und das Verhalten von Objekten zueinander beschreiben. Beans können in CDI mit einem der folgenden Scopes annotiert werden:

• @RequestScoped
• @ConversationScoped
• @SessionScoped
• @ApplicationScoped

Wird eine Bean mit einem Scope annotiert, so wird sie dem entsprechenden Kontext im CDI-Container zugewiesen.

@Named
@SessionScoped
public class InvasionController implements Serializable {
  private static final long serialVersionUID = 1L;
  @Inject @Holisticon
  private BlogService blogService;
  ...
}

Dieser Controller wird an den SessionContext gebunden und bleibt für die Lebenszeit der Session erhalten.

An dieser Stelle ist gut zu wissen, dass Beans mit dem Session oder Conversation Scope serialisierbar sein müssen. Implementieren diese Beans nicht die Klasse Serializable, so verweigert CDI den Start und wirft die folgende Exception:

WELD-000072 Managed bean declaring a passivating scope must be
passivation capable.

Conversation Scope

Der einzig wirklich neue Scope, den CDI bietet, ist der Conversation Scope. Er schließt die Lücke zwischen dem Scope eines Requests und dem Scope einer Session, den Entwickler schon lange vermissten und teilweise durch eigene Implementierungen realisieren mussten. Die Vorteile der Conversation liegen auf der Hand, nutzerspezifische Daten können über mehrere Requests hinweg “gemerkt” werden und es bleiben keine alten beziehungsweise nicht mehr benötigten Daten z.B. in der Session, da der Beginn und das Ende einer Conversation explizit gesetzt werden können. Ein weiteres schönes Feature ist, dass in jedem Browser Tab eine eigene Conversation gehalten wird.

In der Praxis ist der Conversation Scope unter anderem für einen Checkout-Prozess sehr nützlich, so auch im Codebeispiel. Dazu wird eine Stateful CheckoutServiceBean mit der Annotation @ConversationScoped annotiert.

@Stateful
@ConversationScoped
public class CheckOutServiceBean {
  @Inject
  private Conversation conversation;
  private KudosCart kudosCart;

  public KudosCart createKudosCart() {
    kudosCart = new KudosCart();
    // if no conversation is "open“
    if (conversation.isTransient())
      conversation.begin();
    return kudosCart;
  }
  public void checkout() {
    kudosCart.getCart().clear();
    conversation.end();
  }
}

Um die Conversation über mehrere Requests hinweg leben zu lassen – in der Spec wird von einer lange laufenden Conversation gesprochen – injizieren wir uns die Conversation in unsere Bean. Mit diesem Conversation-Objekt kann explizit festgelegt werden, wann eine Conversation beginnt (conversation.begin()) und wann sie endet (conversation.end()). Ob für einen Nutzer bereits eine Conversation “geöffnet” wurde, kann mit conversation.isTransient() geprüft werden.

Zu beachten ist, dass die Conversation automatisch nur bei JSF Requests zur Verfügung steht. Agiert man nicht mit JSF Requests (Links, JavaScript etc.), muss eine Conversation ID (cid) als Parameter mitgegeben werden.

<a href="/add.jsp?cid=#{ javax.enterprise.context.conversation.id }">
 hinzufügen
</a>

Stereotypen

Sterotypen können als Annotationen verstanden werden, die mehrere Annotationen bündeln können.

Es kann z.B. ein Stereotyp angelegt werden, der die Annotationen @SessionScoped und @Named bündelt (die Annotationen werden im Folgenden noch erklärt). Ein Stereotyp wird mit der Annotation @Stereotype annotiert.

@Stereotype
@Named
@SessionScoped
@Target(TYPE)
public @interface NSS {}

Die mit @NSS annotierte Klasse bekommt also implizit @Named und @SessionScoped annotiert.

@NSS
public class InvasionController implements Serializable {...}

Events

Wie auch die Dependency Injection sind Events kein vollkommen neues Konzept für den Java EE Stack. CDI liefert jedoch ein neues Werkzeug, getreu dem Observer Pattern, um Events zu realisieren.

Im Kontext von Events spricht CDI von Producern und Observern. Producer erzeugen Events und Observer “lauschen”, ob Events eingetreten sind. Um Producer und Observer zusammenzubringen bzw. für die Observer festzulegen, welche Events für sie von Interesse sind, werden Qualifier genutzt.

Ergo muss im ersten Schritt ein Qualifier angelegt werden.

@Qualifier
@Target({FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface Invaded {}

Im zweiten Schritt wird der Producer in der Bean angelegt, aus welcher heraus wir Events werfen wollen.

@NSS
public class InvasionController implements Serializable{
  ...
  @Inject @Invaded
  private Event blogArticleEvent;
  ...
  public String giveKudos(BlogArticle blogArticle, int amount){
    blogArticleEvent.fire(blogArticle);
    ...
  }
}

Im Codebeispiel tritt ein Event ein, wenn durch die Methode giveKudos(blogArticle, amount) dem Autor eines Blogartikels Anerkennung gezeigt wird. Das Event-Objekt wird mit @Invaded annotiert und kann somit mit entspechenden Observern in Beziehung gesetzt werden.

Fehlen also nur noch Observer, die reagieren, wenn ein Event eingetreten ist.
Zum Beispiel könnte beim Eintreten des Events getwittert werden, wer gerade für welchen Blogartikel Anerkennung bekommen hat.

@RequestScoped
public class InvasionTweeter{
  public void afterBlogIntrude( @Observes @Invaded BlogArticle blogArticle) {
    ...
  }
}

Da nicht jeder Mensch bei Twitter ist und die Autoren sicher gern Bescheid wüssten, sobald sie Anerkennung bekommen, könnte zusätzlich ein Observer Mails an die Autoren versenden.

@RequestScoped
public class InvasionMailer{
  public void afterBlogIntrude( @Observes @Invaded BlogArticle blogArticle) {
    ...
  }
}

Observer Pattern

Die Frage, ob CDI nun getreu dem Observer Pattern agiert, muss mit “Jein” beantwortet werden. Nicht nur Producer sind von Observern entkoppelt, sondern auch Observer von Producern. Hinzu kommt, dass Observer Events mit Qualifiern filtern und verzögert aufgerufen werden können, z.B. erst, nachdem eine Transaktion abgeschlossen wurde.

Interceptor-Bindings

Ja, auch Interzeptoren sind nichts Neues, aber mit den Interceptor-Bindings wird ein mächtiges Werkzeug für des Binden von Interzeptoren an Methoden zur Verfügung gestellt. Auch hier dienen Annotationen als Bindeglied.

Im ersten Schritt wird eine mit @InterceptorBinding annotierte Annotation angelegt, das Interceptor-Binding LoggerBinding.

@InterceptorBinding
@Retention (RUNTIME)
@Target ({METHOD, TYPE})
public @interface LoggerBinding {}

Im zweiten Schritt wird ein mit dem Interceptor-Binding annotierter Interzeptor erstellt.

@LoggerBinding
@Interceptor
public class LoggingInterceptor implements Serializable {
  private static final long serialVersionUID = 1L;
  @Inject
  private Logger log;

  @AroundInvoke
  public Object onMethodCall(InvocationContext context)
      throwsException {
    ...
  }
}

Die anderen zwei Annotationen @Interceptor und @AroundInvoke sollten, wenn schon mal Interzeptoren eingesetzt wurden, bekannt sein. @Interceptor markiert die Klasse als Interzeptor, und mit @AroundInvoke wird die Methode gekennzeichnet, die beim Aufruf einer mit dem Interzeptor verbundenen Methode ausgeführt wird.

Im dritten Schritt müssen wir unseren Interzeptor jetzt an eine Bean heften. Dazu wird das Interceptor-Binding @LoggerBinding an die Methode checkout() der CheckoutServiceBean annotiert.

@Stateful @ConversationScoped public class CheckOutServiceBean {
  ...
  @LoggerBinding public void checkout() {
    conversation.end();
  }
}

Interzeptoren müssen konfiguriert werden, damit sie in der Applikation dann auch Anwendung finden. Standardmäßig sind sie deaktiviert. Also muss im letzten Schritt der Interzeptor im CDI Deployment-Deskriptor definiert werden.

Dazu wird die beans.xml um folgende Zeilen erweitert.

    de.holisticon.blog.friendlyInvaders.interceptor.LoggingInterceptor

Jetzt ist der Interzeptor aktiviert und jeder Checkout wird geloggt.

Die mit CDI eingeführten Annotationen ermöglichen es, Interzeptoren an Beans zu binden, ohne dass eine Abhängigkeit zwischen der konkreten Bean und einem konkreten Interzeptor entsteht.

Dekoratoren

Mit Dekoratoren bietet CDI eine saubere Umsetzung des Decorator Patterns.

Der Dekorator und die zu dekorierende Klasse müssen dabei das gleiche Interface implementieren. Der Dekorator wird mit @Decorator annotiert.

@Decorator
public abstract class CheckoutServiceDecorator
    implements CheckoutService, Serializable {
   ...
  @Inject @Delegate
  private CheckoutService checkoutService;

    public void giveKudos( BlogArticle blogArticle, float amount) {
      if (blogArticle.getAuthor().getName().endsWith(" Erck")){
        logger.info("No Kudos in the form of money.");
    }else{
        checkoutService.giveKudos(blogArticle, amount);
    }
  }
}

Jeder Dekorator muss ein mit @Delegate annotiertes Objekt besitzen: das Objekt, das dekoriert werden soll. Alle Methoden, die dekoriert, bzw. um Geschäftslogik erweitert werden sollen, werden vom Dekorator implementiert. Im Codebeispiel soll folglich die Methode giveKudos(blogArticle, amount) des CheckoutServiceController dekoriert werden.

Auch Dekoratoren sind Deployment-spezifisch und müssen in der beans.xml aktiviert werden.

    de.holisticon.blog.friendlyInvaders.decorator.CheckoutServiceDecorator

Dank des Dekorators bekommt jetzt keiner, der meinen Nachnamen trägt, mehr Anerkennung in Form von Centbeträgen.

Interzeptoren vs. Dekoratoren

Da im Artikel ja schon vorgestellt wurde, wie einfach sich Interzeptoren mit den Interceptor-Bindings an Klassen binden lassen, bleibt die Frage offen, wann Interzeptoren und wann Dekoratoren die richtige Wahl sind.

Ein konkreter Interzeptor lässt sich an beliebige Klassen jedes Java-Typs binden und sollte eingesetzt werden, um technische Aspekte wie z.B. Logging zu realisieren.

Ein konkreter Dekorator lässt sich nur an eine Klasse eines konkreten Java-Typs binden, kennt somit die Semantik und sollte eingesetzt werden, um eine Klasse mit Aspekten der Geschäftslogik zu dekorieren.

Produzenten

Als letztes Werkzeug sollen die Produzenten vorgestellt werden. Sie sind mit @Produces annotierte Methoden, die immer genau dann aufgerufen werden, wenn eine Instanz eines zu produzierenden Objektes verlangt wird und noch keine entsprechende Instanz erzeugt wurde.

Im Beispielcode wird ein Produzent für den Logger erzeugt. Um diesen Logger von ggf. anderen Loggern zu unterscheiden, wurde zuvor der Qualifier @HcoLogger definiert.

public class HcoLoggerFactory {

  @Produces @HcoLogger
  public Logger produceLogger(InjectionPoint injectionPoint){
    return LoggerFactory.getLogger(injectionPoint.getMember()
      .getDeclaringClass().getName());
  }
}

Soll im Kontext einer Klasse ein Logger via Dependency Injection injiziert werden und wurde für diesen Kontext noch kein Logger erzeugt, so wird er über die Methode produceLogger(injectionPoint) erzeugt.

Im Codebeispiel ist zu sehen, dass der Logger in Abhängigkeit des Typs der aufrufenden Klasse erzeugt wird. Wird eine Instanz über den Produzenten erzeugt, so hat sie den Scope @Dependent, d.h., die Instanz nimmt den Scope und somit auch den Kontext der Klasse an, in die sie injiziert wurde.

Dass im Hintergrund ein Producer greift, ist im CheckoutServiceDecorator nicht zu sehen.

@Decoratorpublic abstract class CheckoutServiceDecorator
    implements CheckoutService, Serializable {
   ...
  @Inject @HcoLogger
  private Logger logger;
  ...
}

Einsatzgebiete

Produzenten sind genau dann sinnvoll, wenn der Typ der zu produzierenden Klasse zur Laufzeit variiert bzw., wenn die Initialisierung individuell erfolgt.

Beispielapplikation

Friendly Invaders (deutsch: Freundliche Eindringlinge)

Um natürlich nicht einfach nur staubigen Quellcode zu lesen, sondern das Ganze auch in der Praxis zum Fliegen zu bringen, dient die Beispielapplikation “Friendly Invaders“.

Sinn und Unsinn

Die Beispielapplikation ermöglicht es Lesern, den Autoren von Blogbeiträgen in einem via RSS angebundenen Blog Anerkennung (Kudos) zu zeigen. Dazu befindet sich unter jedem Blogartikel ein “Give Kudos” Button.

"Give Kudos" Button

Wurde dieser Button geklickt, wird das Kudos in einen Warenkorb gepackt. Wird auf den Warenkorb, der durch eine Bean im Conversation Scope implementiert wurde, geklickt, so wird ein einstufiger Checkout vollzogen und schließt den Prozess der Anerkennung ab.

cid des Conversation Scope als Parameter

Observer, Dekorator, Logger und Interzeptor erzeugen Text auf der Console, der ihre Aktivität zweifelsfrei belegen soll.

[STDOUT] Observer: Tweet: Rolf Dräther: Aus dem Leben einer User Story
[STDOUT] Observer: Mail: Rolf Dräther: Aus dem Leben einer User Story
[de.holisticon.blog.friendlyInvaders.decorator.CheckoutServiceDecorator]
Kudos and Money
[de.holisticon.blog.friendlyInvaders.interceptor.LoggingInterceptor]
checkout: Fri Dec 16 17:27:21 CET 2011

Lebensraum

Um die Applikation auszuführen, empfehle ich den JBoss 6 Application Server. Soll die Anwendung in Eclipse, mit Serveradapter für den JBoss 6 Application Server und API zum Editieren der beans.xml, zum Laufen gebracht werden, so müssen in Eclipse die JBoss Tools 3.2 installiert werden.

• “Friendly Invaders” Download
• JBoss 6 Application Server
• Eclipse (Helios 3.6.1)
• JBoss Tools for Eclipse (3.2)

Zusammenfassung

Innerhalb des Vortrages wurde die Werkzeugkiste von CDI vorgestellt. Alle Werkzeuge erleichtern den Entwicklern von Applikationen die Arbeit erheblich und helfen, die Basics wie Entkopplung und Separation of Concerns umzusetzen.

Das Ziel, ein umfassendes DI Framework im Java EE Standard zu etablieren und eine bessere Verbindung zwischen JSF und EJB bzw. der Präsentationsschicht und Geschäftslogik herzustellen, wurde definitiv erreicht.

Ob CDI mit der Referenzimplementierung Weld in der Praxis in der Lage ist, Frameworks wie Spring oder Seam aus der Welt zu schaffen, wird sich zeigen.

Was ist eure Meinung dazu? Hat CDI das Zeug, Spring oder Seam als DI Frameworks zu verdrängen? Über Kommentare würde ich mich freuen.

Dabei steht die pragmatische Herangehensweise im Vordergrund: Welche Hürden gab es im Projekt, wie wurden diese gemeistert? Welche Fragestellungen tauchen auf, die die klassischen Lehrbücher zur agilen Softwareentwicklung nicht beantworten? Welche Anpassungen waren wann erforderlich?

In meinem Beitrag “Ein agiles Projekt ist kein Ponyhof” bekommen die IT-Abteilung und ein Fachbereich eines großen mittelständischen Unternehmens die Chance, auf der grünen Wiese ein neues Anwendungssystem zu errichten. Die externen Architekturberater empfehlen Scrum als agilen Ansatz für das Projektmanagement, und das Unternehmen lässt sich darauf ein. Mit zunehmender Scrum-Erfahrung stellt auch dieses Unternehmen fest, dass ein agiles Projekt kein Selbstgänger ist, sondern harte Arbeit – die sich aber lohnt, wie das Projektergebnis und die Motivation der Mitarbeiter belegen.

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Worum geht es?

Was bis jetzt nur mit der Unterstützung von Frameworks wie Spring möglich war, möchte EJB 3.1 nun auch allein können: typsichere Dependency Injection von Managed Beans aller Art, innerhalb von Java-Kontexten, die über einen eigenen Lebenszyklus verfügen. Möglich macht es die “Contexts and Dependency Injection for Java EE” (CDI).
Dieser Vortrag stellt die neuen Konzepte und Sprachmittel, die dem Entwickler mit CDI zur Verfügung stehen, an einer durchgängigen Beispielanwendung vor, darunter Dependency Injection, Qualifier, Scores und Contexts, Interzeptoren sowie Dekoratoren, Events und Produzenten.

Wann und wo?

Mittwoch 07.12.2011, 19.00 Uhr
Holisticon AG
Friedensallee 120
22763 Hamburg

Unser Firmensitz befindet sich im Hinterhof.
Ich freue mich auf Euer Kommen und eine spannende Veranstaltung.

BPM meets Java EE:
Automatisierte Leistungsabrechnung bei der HanseMerkur Versicherung

Ende 2008 startete die HanseMerkur Versicherung eine BPM/SOA-Initiative mit der Vision, die vormals monolithische und systemorientierte Sichtweise der hausinternen Informationstechnik gezielt der Prozess- und Serviceorientierung weichen zu lassen. Im Einzelnen bedeutete dies die Bereitstellung einer entsprechenden Infrastruktur, die Entwicklung einer Basisarchitektur und darauf aufsetzend Schritt für Schritt eine weitgehende Ablösung der bestehenden Leistungsabrechnungssysteme durch ablauffähige Prozessbeschreibungen, wiederverwendbare Komponenten und Services auf Basis der Java Enterprise Edition.

In ihrem Artikel beleuchten Jo Ehm und Olaf Fricke (HanseMerkur) die technischen Details der Umsetzung von BPM/SOA bei der HanseMerkur Versicherung: das Design und die Entwicklung einer Komponenten- und Servicearchitektur auf der Basis von EJB3 unter JBoss, das dazu entwickelte Framework mit einer ComponentRegistry, die den parallelen Betrieb verschiedener Versionen der gleichen Services, den versionierten Zugriff sowie den Austausch dieser Services zur Laufzeit ermöglicht, die Modellierung, Orchestrierung und Automatisierung der Geschäftsprozesse mit Hilfe der inubit BPM-Suite und die Best Practices im Bereich des Testens – von UnitTests bis hin zu FIT-Tests für den Fachbereich.

Der komplette Artikel ist online zugänglich im Archiv des JavaSPEKTRUMs.

Die Mischung aus klassischen Vorträgen und alternativen Formaten wie Open Space, Fishbowl oder Pecha Kucha rund um aktuelle Themen der Softwareentwicklung hat sich bewährt. Auch der in diesem Jahr erstmalig nach der SEACON durchgeführte Architekturtag wurde von den Teilnehmern gut angenommen. Deshalb wird es auch im kommenden Jahr wieder einen Architekturtag geben (6. Juni). Um diese drei Tage informativ und abwechslungsreich zu gestalten, suchen die Fachbeiräte von SEACON und Architekturtag praxisrelevante Beiträge. Die Details zum Call for Papers sind auf der SEACON-Website zu finden.

Die SEACON steht 2012 unter dem Motto “Denkzelle oder Lernfabrik: Innovation in kleinen und großen Unternehmen”. Woran denken die meisten von uns, wenn sie das Wort “Konzern” hören? Bürokratie. Hierarchie. Starre Strukturen, die Innovation im Keim ersticken. Diese Innovation findet der landläufigen Meinung nach in kleineren Einheiten statt: Start-ups und Netzwerke von Freiberuflern und Einzelunternehmern. Viele dieser “jungen Kreativen” haben früher selbst in Konzernen gearbeitet. Sie sind dann aus diesen Strukturen ausgebrochen, um es selbst zu versuchen – und es dabei vor allem besser zu machen. Und manchmal stellen sie fest, dass viele der “alten” Vorgehensweisen, die sie für unnötig oder übertrieben hielten, durchaus sinnvoll sind. Anders herum können die Konzerne von den “Kleinen” lernen: etwa, wie man erfolgreich in Netzwerken arbeitet, und wie man die Fähigkeiten und Wünsche des Einzelnen achtet und nutzt. Um diese Lerneffekte soll es auf der SEACON 2012 gehen. Deshalb freuen wir uns auf Vortragende und Teilnehmer aus großen und kleinen Unternehmen. Sie sollen die SEACON als Plattform für den Erfahrungsaustausch nutzen, voneinander und miteinander lernen. Und sollten auch Sie Großunternehmen für verkrustet und langsam halten, dann denken Sie mal an Google und Apple. Vielleicht ist “groß” doch gar nicht so übel…

Gespart – ein Software­leben lang

Enno Thieleke und Stefan M. Heldt, Business Technology 4.2011

Waschen Sie Ihre Wäsche per Hand? Sicher ist die Investition in eine Waschmaschine nicht sehr interessant. Dennoch muss sie sein, um Ihnen aufwändige Handarbeit zu ersparen und damit Personalkosten zu reduzieren. Ganz nebenbei hebt es sicher Ihre Stimmung, nur noch die Maschine füllen und starten zu müssen. Ähnlich verhält es sich mit Software Configuration Management, Build Management, Release Management, Qualitätsmetriken und diversen Formen der Testabsicherung. Diese machen es IT-Abteilungen möglich, Software professionell zu entwickeln, auszuliefern und zu betreiben.

Die aufgezählten Aktivitäten werden von den Ausführenden größtenteils als stetig wiederkehrend und wenig kreativ betrachtet. Sie eignen sich damit perfekt, um automatisiert zu werden. Diese Bestrebung wird von den Geldgebern jedoch häufig als reiner Kostenblock interpretiert. Wir zeigen in unserem Beitrag in der aktuellen Ausgabe der Business Technology auf, wie Sie mit der Automatisierung nicht nur Ihre Entwickler glücklich machen, sondern obendrein auch noch Geld sparen. Außerdem legen Sie den Grundstein, um die Qualität Ihres Softwareprodukts konsequent zu messen und zu verbessern. Die Wäsche wird einfach blütenrein.

Während der vergangenen Projekte hatte ich in den Gesprächen mit Kunden und Kollegen bisher stets den Eindruck, dass auch in Hamburg durchaus großer Bedarf für ein Forum zum Thema Software Craftsmanship besteht. Deshalb wird es höchste Zeit auch in Hamburg eine solche Community zu gründen, um allen interessierten und engagierten Entwicklern die Möglichkeit zu bieten sich außerhalb des täglichen Arbeitsumfeldes zu Themen wie Agile Developer Skills, Clean Code, TDD, XP, Know-how-Transfer in Entwicklerteams etc. auszutauschen.

Nun steht der Termin, am 25.10.2011 geht’s endlich los! Zunächst soll dies eine Möglichkeit sein Networking mit anderen agilen Entwicklern und jenen die es werden wollen zu betreiben. Ich werde bei der Gelegenheit auch über die Eindrücke von der SoCraTes als Mutter der Software Craftsmanship Bewegung in Deutschland erzählen. Aber in allererster Linie sind natürlich eure Ansichten und Erfahrungen zum Thema Software Craftsmanship gefragt. Deshalb möchte ich mit Allen Ideen für Themen, Workshops, Coding Dojos oder generell zum Format der Veranstaltung als Hamburger Spin-Off der SoCraTes sammeln. Also bin ich schon sehr gespannt auf das erste Treffen und werde auch an dieser Stelle regelmäßig von den Ergebnissen berichten.

Mehr Infos zum Event gibt es hier: https://www.xing.com/events/softwerkskammer-hamburg-software-craftsmanship-community-818260

In der Softwareentwicklung, insbesondere in agilen Projekten, steht das Team im Mittelpunkt. Der Teambegriff ist durch Werte und Prinzipien wie Eigenverantwortung, Vertrauen und offene Kommunikation geprägt. Auch in anderen Domänen gibt es Teams – aber gilt dort dasselbe Begriffsverständnis? Wie ist beispielsweise die Besatzung eines Feuerwehrfahrzeugs organisiert, und was kann ein Softwareentwicklungsteam daraus lernen? Dieser Frage geht der Pecha Kucha nach.

“Die Feuerwehr: Ein agiles Team?” (Pecha Kucha, SEACON 2011) auf Vimeo

EJB 3.1 professionell

Als Nachfolger zu unserem erfolgreichen Buch “EJB 3 professionell” erschien unlängst die zweite, aktualisierte und erweiterte Auflage “EJB 3.1 professionell – Grundlagen- und Expertenwissen zu Enterprise Java Beans 3.1″.

Wie schon beim Vorgänger taten sich auch dieses Mal einige unserer Kollegen von Holisticon zusammen, um ihr Wissen und ihre Praxiserfahrung in das Buch einfließen zu lassen. Unter ihnen ein Mitglied der EJB 3.1 Expert Group sowie Mitglieder der Expert Groups zu den kommenden Spezifikationen von EJB und CDI. Aber auch (oder gerade?) die vielen wertvollen Anmerkungen der Leser des Vorgängers sind in das Buch eingeflossen – danke an dieser Stelle noch einmal für die eingegangenen Hinweise.

Über EJB 3.1 hinaus liefern die Autoren fundierten Einblick in die Java Persistence API 2.0 – der Persistenzstandard für die gesamte Java-Plattform (Java SE und EE). Abgerundet wird das Buch durch projektrelevante Themen wie Contexts and Dependency Injection (CDI), Sicherheit und Softwaretest. Das Themenspektrum und viele Praxishinweise sowie Checklisten machen das Buch nicht nur zum Grundlagenwerk, sondern auch zum ständigen Begleiter und Nachschlagewerk im Projekteinsatz.

Weitere Informationen finden Sie auf unserer Webseite und auf der Verlagsseite.