Docker dir einen!

Nach etwas Skepsis zu dem Thema Docker bin ich begeistert von Docker. Es vereinfacht (darum die Beliebtheit) das ganze
Thema Installation / Modifizierbarkeit der IT-Infrastruktur, vor allem der Applikationsserver.

Was braucht man? Docker natürlich und das “Dockerfile”. Das Dockerfile wiederum stellt die Konfigurationsdatei. Also auf welcher
Basis soll das Image erweitert werden, sollen zusätzliche Programme installiert werden und welches Programm soll gestartet werden. Das wäre das Grundprinzip und mit docker selber wird das Image gestartet und die entsprechenden Ressourcen eingestellt (CPU,Speicher,IPs,etc.). Natürlich kann da man noch viel mehr machen, aber dafür gibt es die Webseite von Docker selber 😉 .

Unter https://registry.hub.docker.com/ werden übrigens fertige Images angeboten, inkl. Applikationsserver

Wie geht man als Old-School Java / Maven Developer nun vor?

Als erstes unter src/main/resource den Ordner docker und die Datei “Dockerfile” anlegen

Diesen Inhalt in diese Datei kopieren

FROM java:oracle-java8
MAINTAINER Yourname
VOLUME /tmp
ADD yourmavenpacked.jar app.jar
RUN bash -c 'touch /app.jar'
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
EXPOSE 8080

Maven anpassen..nutze das Plugin von Spotify, aber da gibt es genug Alternativen.

<build> 
        <plugins> 
           <plugin>
            <groupId>com.spotify</groupId>
            <artifactId>docker-maven-plugin</artifactId>
            <version>0.2.3</version>
            <configuration>
                <imageName>${docker.image.prefix}/${project.artifactId}</imageName>
                <dockerDirectory>src/main/resources/docker</dockerDirectory>
                <resources>
                    <resource>
                        <!-- <targetPath>/</targetPath> -->
                        <directory>${project.build.directory}</directory>
                        <include>${project.build.finalName}.jar</include>
                    </resource>
                </resources>
            </configuration>
        </plugin>
        </plugins>
    </build>

und mit mvn clean package docker:build bauen…das Image steht im lokalen Docker bereit und kann nun mit docker run gestartet werden! Nutzt man Windows via Boot2Docker, muss in dieser Umgebung gebaut werden.

That’s all…für den schnellen Einstieg. Dieses Image kann wiederum modifiziert werden z.B. im IT-Betrieb mit anderen Einstellung für Passwörtern, IP-Adresse zu Datenbanken etc.

JPA und OneToOne

Obwohl eigentlich JPA easy einzusetzen ist, sprich das Mapping, gibt aber manchmal Situation, wo es nicht ganz trivial wird bzw. man wieder überlegt…wie war das nochmal…

Folgende Situation bei einer OneToOne-Relation:
Die “Sub”-Entität hat eine ForeignKey-Beziehung zur “Haupt”-Entität (die alles aggregiert). Die Haupt-Entität jedoch keine definierte Relation zur “Sub”-Entität. Der primäre Schlüssel in der “Sub”-Entität ist gleichzeitig also auch der ForeignKey zur “Haupt”-Entität.

JPA geht jedoch nun aus, das die FK-Beziehung von der Haupt-Entität ausgeht. Ist diese jedoch inverse und noch Unidirektional geht es ohne den Standardweg nicht.

Abhilfe schafft hier nur bei der Annotation JoinColumn das Attribut referencedColumnName….ich vergesse das immer.. 😉

Boot me up, Spring

In einem PoC beschäftige ich mich aktuell mit Spring Integration und Spring Boot. Mit Spring Boot
lässt sich auf sehr schnelle Art und Weise das Thema “Microservices” realisieren und dank Spring Integration inkl. Messaging 😉

Damit lässt sich also fancy stuff entwickeln…was braucht man?

Einfach mal den Maven-Archetype spring-boot-sample-integration-archetype:1.0.2.RELEASE ausführen und um folgende
Abhängigkeiten erweitern:

  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  <dependency> 
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
   </dependency>

Und mal folgende URL ausprobieren:

http://localhost:8080/dump
http://localhost:8080/metrics
http://localhost:8080/health

Damit hätten wir ein Grundgerüst was so jeder “Application-Server” kann, aber alles in einer Anwendung und “zusammengestöpselt”…

Injection Field or Constructor based?

Bei vielen Tutorials / Dokus sieht man meistens die Field-Injection oder gar die Setter-Injection und kaum die Constructor-Injection. Aber warum?
Wo ist der grosse Vorteil bei Constructor-Injection?

Field-Injection und Constructor-Injection haben gemeinsam erst einmal den Vorteil, dass bei der Erzeugung des Objektes die Abhängigkeiten gesetzt werden und im späteren Lebenszyklus das Objekt seine Abhängigkeiten nicht mehr ändert. Was je nach gewünschtem Ziel (Immutable, Mutable) ein Vorteil ist. Pauschal sind Immutable Objekte vom Design immer besser, da keine Seiteneffekte im Lebenszyklus zu erwarten sind 😉

Aber was ist bei Constructor-Injection der Vorteil? Folgendes Beispiel

 
class TestField {
 
 @Inject
 private Test field;
 
 public void doSomething() {
    field.blabla();
 }
 
}

Wie kann ich die Eingeschaft field nun in einem JUnit-Test setzen? Na kla bieten DI-Frameworks wie Weld, Spring ihre TestRunner an und mit einem Mock-Framework kann ich es auch modifizieren…aber was ist wenn ich es nicht nutzen kann? Dann geht es schlicht bei Field-Injection nicht…daher ist Constructor-Ansatz die wartbare / flexible Variante! Also bevor man wieder im selben Trott Field-Injection nutzt…einfach mal überlegen, ob nicht der Constructor-Ansatz der bessere wäre.. 😉

 
class TestField {
 
 private Test field;
 
 public TestField(@Inject Test field) {
   this.field = field;
 }
 
 public void doSomething() {
    field.blabla();
 }
 
}

D3.js und JSF2

Im JSF-Umfeld gibt es mit ICEFaces und Primefaces gute Bibliotheken für JSF, jedoch lässt die Visualisierung von Daten zu wünschen übrig. Sucht man
nach Alternativen trifft man z.B. auf D3.js. Dies ist eine JavaScript-Bibliothek, die
fast “alle” Diagrammtypen visualisiert. Dabei setzt D3.js zeitgemäß auf CSS3/HTML5…meine Projektidee ist es nun also D3.js mit JSF2 zu verheiraten.

Wer Lust hat, kann gerne bei GitHub mitwirken!

Was ist die Grundidee?

DS3 verarbeitet JSON-Daten zu Grafiken, daher ist die Idee eine JSF-Komponente pro Diagrammtyp bereitzustellen, die JSON-Daten oder Listen entgegennimmt:

z.B.

Mapper / Translater / Builder / Factory

Hmm…stehe gerade bei einem aktuellen Projekt vor der Herausforderung, wo ich zwischen 3 Komponenten die “eigentlich” semantisch, identischen Objekte austausche und quasi von einer Komponente zur nächsten immer mappe. Mit Dozer oder BeanUtils klappt es nicht wirklich, so dass es händisch durchgeführt wird. Schöner wäre natürlich ein herausschneidern der “Domainmodelle” in ein separates Modul, aber so einfach geht es im IT-Leben nicht immer. Kurz um, es gibt ein Kunden-Objekt, was im Modul A, B, C spezifiziert ist und zwischen diesen Modulen/Anwendungen “ausgetauscht” wird.

Also was nehmen, welches Pattern ermöglicht bessere Wartbarkeit / Erweiterbarkeit?

Factory? Factory erzeugt Objekte vom gewünschten Typ bzw. Produktfamilien. Könnte passen, aber es geht ja im Sinne von “neu”. Daher ist Factory also eher unpassend und zwingt auch, dass Modul A, B, C irgendwie diese Produktfamilie berücksichtigen. Dann könnte man auch gleich ein neues Modul D mit den extrahierten Domainmodellen erstellen 😉 .

Builder? Builder passt von der Definition her. Beim Builder geht es um unterschiedliche Repräsentation bei einem gemeinsamen Konstruktionsprozess und erzwingt auch keine abstrakten Vererbungshierachien. Jedoch müsste man für jede Richtung ein Builder bauen und bei neuen Strukturen immer den Builder anpassen.

Translater? Translater wird ähnlich wie der Interpreter von der GoF implementiert und könnte auch passen. Die Grammatik wäre das Kunde-Objekt vom Modul A und lässt dies mit dem Interpreter (Context/Expression) für Modul B übersetzen. Kommt dem gewünschten Ansatz noch besser entgegen und durch Expressions und Contexte lassen sich neue / modifizierte Domainmodelle hinzufügen ohne bestehende Klassen anzupassen.

Und der Mapper? So ein richtiges Pattern habe ich nicht gefunden, ausgenommen das DataMapper von Martin Fowler, was aber im Prinzip in Richtung OR-Mapper geht 😉 Beim Mapper geht es um 1:1 kopieren von Eigenschaften von einer Quelle zum Target. Ein Mapper ist eher ein Prinzip, was durch die oben genannten Patterns realisiert werden kann.

DIP / DI / IOC

Kürzel schon mal gehört?

DIP:
Beim Dependency Inversion Principle geht es um die Umkehrung von einer direkten Implementierung zu einer Abstraktion. Beispielweise eine Desktopanwendung nutzt direkt die Windows-Komponenten, würde die Desktopanwendung eine “Abstraktion” nutzen, so könnte man die Desktopanwendung z.B. auch auf einem MacOS laufen lassen. Also beim Entwerfen! einer Anwendung immer im Auge haben, lieber Abstraktionen zu nutzen, als etwas konkretes. Erhöht die Testbarkeit (kann ich mocken?) und mindert die Kopplung

IOC:
Läuft auch unter dem “Hollywood”-Prinzip und ist ein Prinzip bei “Frameworks”. Über definierte Schnittstellen (Callbacks) vom Framework, implementieren
Clients die Spezialisierung, die dann vom Framework genutzt werden. Man kann also einen generischen Code – hinsichtlich Wiederverwendbarkeit – in ein Framework auslagern und die Spezialisierungen nutzen diese Funktionalitäten.

DI:
DI ist eine spezielle Form vom IoC. Sieht man auch schönen Beispiel vom Spring-Framework. Ein IoC-Container, welches DI implementiert 😉
Bei DI geht es um das Managen der Abhängigkeiten, anstatt das der Client die Abhängigkeiten direkt managed (Java new-Operator), werden die Abhängigkeiten extern “injiziert”. Extern ist dem Sinne der IoC-Container oder auch Assembler genannt.

Also DI geht es um das wie (wie komme ich an die Abhängigkeit) und bei IOC um das wer (wer ruft wen auf). Daher ist auch DI ist eine spezielle Variante von IOC. Bei DIP geht es, an wen richtet sich der Aufruf. Zusammen spielen alle 3 ihre Mächtigkeit aus. DIP kann auch für sich allein stehen und ist ein genereller Ansatz als IOC und damit DI. IOC/DI können demnach auch ohne DIP eingesetzt werden. Soweit alles klar?

Link:
http://openbook.galileocomputing.de/oop/index.htm
http://martinfowler.com/articles/dipInTheWild.html

Kommunikationsdiagramm..

Na wer nutzt das Kommunikationsdiagramm in seiner Architekturbeschreibung? Im meinen Beschreibungen oder am Whiteboard kommt zu 90% das Sequenzdiagramm vor und die restlichen Prozente verteilen sich auf das übliche Aktivitätsdiagramm für Prozessdarstellungen. Bei UML gibt es ja sagenhafte 7 verschiedene Verhaltensdiagramme, jedes hat seine spezielle Berechtigung, was man z.B. gut beim Timingdiagramm auf dem ersten Blick erkennt. Hingegen das Kommunikationsdiagramm – man kennt es – hatte ich nie so auf den Radar..bis ich mich die iSAQB Zertifizierungsvorbereitung auf das Thema gestoßen hat und ich mich frage, warum man es nicht häufiger verwendet und in anderen Dokumentationen sehe. Für mich quasi ein Paradigmawechsel 😉

Und so schaut es aus:

Dynamic

Durch die Nummerierung und unterschiedlichen Farbtöne der Verbindungslinien lassen sich unterschiedliche Kommunikationswege simultan darstellen.

Vorteil ?

Sehr viele interagierende Objekte lassen sich komfortabel darstellen. Beim Sequenzdiagramm ist man auf der horizontalen Zeitlinie eingeschränkt, was beim Bildschirm zum heftigen scrollen führt und bei noch komplexeren Sequenzdiagrammen zu einem A3-Druck führt. Der grosse Vorteil beim Sequenzdiagramm gegenüber dem Kommunikationsdiagramm ist die bessere optische Darstellung der zeitlichen Abfolge / Abhängigkeiten, die im Kommunikationsdiagramm (je nach Komplexität) leidet.

WebSocket…Nachfolger vom REST-Stuff?

Mit Java EE 7 ist WebSocket (JSR 356) offiziell in den Java EE Standard aufgenommen. Viele MV*-JavaScript-Framework können Services über diese bidirektionalen Standard ansprechen und stellen damit eine interessante Alternative zu REST. Der REST-Ansatz gibt es ja schon seit 2000 mit Dissertation von Roy Fielding. Zeit also was für neues! WebSocket ist auf der vertikalen Ebene wie HTTP, daher eigentlich ein Ersatz! Aber WebSocket – im Kontext eines WebBrowser – nutz jedoch für den “First-Contact” HTTP um über den selben Port ein Protokollwechsel durchzuführen 😉 Dank “Vollduplex” kann auf diesen Port simultan Nachrichten verschickt und empfangen werden. Das Prinzip ist dem Messaging identisch und daher auch asynchron. Im Gegensatz zu HTTP, wo dies “synchron” stattfindet. Bei HTTP kann über Umwege “Long Pooling” und “Streaming” das Verhalten simuliert werden, jedoch mit höheren Resourcenverbrauch (Bandbreite,stetiges senden von Datenpaketen) und Latenz.

Wo liegt der Unterschied nun zu ZeroMQ (siehe hier)? WebSockets sind standardisiert und jeder “neuer” Browser versteht diesen Kommunikationsweg. Deswegen ist eine ernt zunehmende Alternative zu REST, wo es auf Durchsatz und niedriger Latenz ankommt! Wenn noch die Verwendung von WebSockets in Java EE 7 so leicht wie bei JAX-RS funktioniert, gibt es auf der Serverseite keinen Grund seine bisherigen “Services” nicht auch da gegen zu entwickeln.

Mit NetBeans 7.4 gibt es paar schöne Beispiele für die Client- und Serverseite ausschaut.

@ServerEndpoint("/draw")
public class DrawEndpoint {
 
    private static Set<Session> peers = Collections.newSetFromMap(new ConcurrentHashMap<Session, Boolean>());
 
    @OnOpen
    public void onOpen(Session session) {
        peers.add(session);
    }
 
    @OnClose
    public void onClose(Session session) {
        peers.remove(session);
    }
 
    @OnMessage
    public void shapeCreated(String message, Session client) throws IOException, EncodeException {
        for (Session otherSession : peers) {
            if (!otherSession.equals(client)) {
                otherSession.getBasicRemote().sendText(message);
            }
        }
    }
}

Wäre bei dem Beispiel noch “@OnError” wäre der komplette Lebenszyklus in dieser Klasse dargestellt. Das Session-Objekt entspricht dem Request/Response-Objekt aus der HTTP-Welt. Darüber können Daten an den jeweiligen Client verschickt werden. Im Tutorial von Oracle wird das Handling über anonyme Klassen gehandelt, da finde ich das Beispiel aus NetBeans eleganter.

Als MessageTyp sind neben String noch ByteBuffer und PongMessage? erlaubt und natürlich dürfen die JSON/XML Marshaller nicht fehlen. Im Prinzip ist es alles, was man auf der Server-Seite gibt. Naja nicht ganz, so wie da oben, ist nix mit JSON. Man muss noch die Annotation für Decoder und Encoder erfassen und seine eigenen De-/ Serializer schreiben, damit die Java-Typen in JSON umgewandelt werden können. Mit Jackson kann man es jedoch recht generisch halten. Schade, warum man im JSR nicht paar Default-Implementierung mitgeliefert hat.

@ServerEndpoint("/draw",  encoders = {MyEncoder.class},  
                decoders = {MyDecoder.class})  )
public class DrawEndpoint {

Obwohl Java EE7 seit April offiziell raus, ist der einzige stabile AppServer der Glassfish 4, der diesen Standard unterstüzt. Tomcat 8 und Wildfly sind noch im Betastatus..

Auf der Client-Seite (JavaScript/Webbrowser) braucht man nur noch folgendes:

 websocket = new WebSocket(getRootUri() + "/websocket-draw/draw");
        websocket.onopen = function (evt) {
            onOpen(evt)
        };
        websocket.onmessage = function (evt) {
            onMessage(evt)
        };
        websocket.onerror = function (evt) {
            onError(evt)
        };

Ok, das obige Beispiel bezieht sich auf das JavaScript-Universum. Im Java-Umfeld gibt es auch die Client-Api und wird durch JSR 356 abgedeckt 😉

Links:
http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm