Cloud Foundry Einführung mit IBM Bluemix

Cloud Foundry (CF) ist eine OpenSource Platform, welches auf ein gängige IaaS bereitgestellt werden kann, um ein PaaS zu errichten, in dem dann unterschiedliche Applikationen und Services bereitgestellt werden können. Natürlich gibt es verschiedene Anbieter die ein PaaS auf Cloud Foundry basierend anbieten, dazu gehören u.a. Pivotal CF, IBM Bluemix. In dieser Einführung wird CF mit IBM Bluemix vorgestellt.

[Read More]

Dokumentation einfach gemacht

Dokumentation - es gibt nichts schlimmeres als nicht aktuelle und falsche Dokumentation. Da ist sogar keine Dokumentation besser. Keine Dokumentation ist spätestens dann keine Option, wenn mehrere Teilnehmer existieren und die Software für einen breiten/öffentlichen Nutzerkreis angedacht ist. Hier möchte ich mal aufzeigen, wie einfach Dokumentation sein kann. Spaß kann es sogar auch machen.

[Read More]

ELK Stack im Cluster-Betrieb

Mit dem ELK Stack bekommt man eine abgestimmte Umgebung um Log-Einträge per Logstash abzuholen, diese in Elasticsearch vorzuhalten und dann per Kibana anzuzeigen. Das Aufsetzen des ELK Stack wird mit den Docker Images von Elastic vereinfacht. Um diese jedoch im Cluster zu nutzen müssen ein paar Anpassungen durchgeführt werden, welche hier dargestellt werden.

[Read More]

DevEnv: Docker und Elasticsearch

Docker, eine simple Art seine Umgebung modular und wiederverwendbar aufzubauen. Da ich schrittweise exemplarisch eine ganze Entwicklungsumgebung auf Docker darstellen möchte, stelle ich heute vor, wie man Elasticsearch innerhalb eines eigenen Docker Container zum Einsatz bringt.

[Read More]

DevEnv: Docker und AppServer

Docker ist aktuell in aller Munde und das Ökosystem um Docker wächst kontinuierlich weiter. Somit lohnt sich mal ein genauerer Blick. Ich werde hier schildern, wie ein Docker Image mit einem Application Server erstellt werden kann. Als Application Server werde ich WildFly verwenden, jedoch ist jegliche andere Software denkbar.

Überblick

# This code block gets replaced with the TOC

Im einem Softwareprojekt strebt man an, dass alle Umgebungen (Entwicklung, Integration und Produktion) die selben Systeme, Versionen und Einstellungen besitzen. Dies kann man mit sehr genauen Installations- und Konfigurations-Anleitung bewerkstelligen. Jedoch ist der manuelle Aufwand hoch, genauso auch sehr fehleranfällig. Eine andere Möglichkeit ist es, immer das selbe VM Image zu verwenden. Dies kann einheitlich erstellt werde und dann auf allen Umgebungen verwendet werden. Ein solches VM Image beinhaltet jedoch neben der für das Projekt benötigte Software auch mind. das Betriebssystem. Dieser Sachverhalt verursacht ein verhältnismäßig zu großes Artefakt, was dann auch nicht schnell mal auf einer neuen Umgebung kopiert und bereitgestellt werden kann. Hier kommt dann Docker ins Spiel [1]. Docker kapselt die Software in einem Container und erwartet auf dem Host-System eine Docker Engine um den Container zum Laufen zu bringen. D.h. der Container beinhaltet nur die „projekt-relevanten“ Softwareprodukte. Dieser Container ist leichtgewichtiger als ein komplettes VM Image. Einmal erstellt, können diese Docker Container überall eingesetzt werden können, wo ein Docker Engine zur Verfügung steht – für Windows-User gibt es hier auch eine Lösung ;-).

[Read More]

JEE: Arquillian

Überblick

# This code block gets replaced with the TOC

Arquillian ist ein Framework für Integration Tests. Es bietet die Möglichkeit für bestimmte Testfälle ein Deployment bereitzustellen, was die nur die relevanten Klassen besitzt. Diese sogenannten Micro-Deployments können mittels Arquillian einfach definiert werden und dann in einem embedded or existierenden Container eingesetzt werden. In diesem werden dann die Testfälle durchgeführt. Zur Vollständigkeit ist noch erwähnt, dass Arquillian auch für client-seitige Tests verwendet werden kann, in solchen Fällen ist ein Deployment nicht notwendig. Als Deployment-Format stehen verschiedene zur Verfügung, z.B. Jar, War, Ear etc. Genauso stehen als Container verschiedene Alternativen zur Verfügung. Arquillian bietet hierfür die gängigsten Adapter an, siehe [2].

[Read More]

CDI in JavaSE

CDI – Contexts and Dependency Injection for the Java(tm) EE platform [1] - ist nicht neu und man findet im Netz auch genug gute Einführungen (z.B. [2] und natürlich immer auch bei [3], [4] etc). Möchte man jedoch CDI außerhalb eines Container (AppServer) verwenden, sprich in einer Java SE Umgebung, sucht man schon etwas länger. Bei CDI gibt es u.a. folgende Implementierungen: Weld [5] und OpenWebBeans [6]. Bei der Referenzimplementierung Weld ist die Dokumentation vorbildlich und es gibt auch ein Kapitel [7] welches den Einsatz in einer Java SE Umgebung beschreibt. Solch ein Kapitel sucht man bei OpenWebBeans leider vergebens – das Kapitel an sich existiert schon, leider ohne Inhalt. Zum Glück findet man im SVN jedoch ein SE-Bespiel [8]. Für Version 1.1.2 ersetzt man folgende Zeil:

[Read More]
cdi  java 

Nodejs HTTP-Server

Schreibt man eine Client-Anwendung, die mit einem Server kommunizieren soll, weclhes zum Testing nicht zur Verfügung steht, muss man schauen, wie man die Kommunikation simulieren kann. Am besten wäre eine Test-Implementierung des Servers, der die Spezifikation/API unterstützt. Bevor die Spezifikation zum Test implementiert werden kann, muss jedoch die Grundfunktionalität (HTTP) des Server implementiert werden. Um sich das zu ersparen, kann man z.B. nodejs verwenden.

var http = require('http'),
	url = require('url');

var results = \["status=OK&desc=Alles paletti&url=http://www.heise.de/",
			   "status=NOK&desc=Oh, problem&url="\];
	
var httpServer = http.createServer();

httpServer.on('request', function(request, response) {
	// Parse the entire URI to get just the query
	var query = url.parse(request.url, true).query;
	// parse the query parameters
	var param1 	= query\['p1'\];
	var param2	= query\['p2'\];
	var param3	= query\['p3'\];
	
	// Do something with the parameters to generate the response.....
	
	// return random response
	response.writeHead(200, {'Content-Type': 'text/plain'});
	var rnd = Math.floor(Math.random() \* results.length)
	response.end(results\[rnd\]);
});

httpServer.listen(1337, '127.0.0.1');

console.log('- Server running at http://127.0.0.1:1337/');

Wie man sehen kann, wird in wenigen Zeilen JavaScript ein HTTP-Server geschrieben, der auf den “request”-Event horcht. Bei jedem Request werden die Parameter ermittelt und die Response generiert. Nodejs bietet verschiedene Events an, für die ein Callback-Funktion registriert werden kann. Beim HTTP-Server sind das z.B.: request, connection, close. Weitere Details sind in der Docu zu finden.

[Read More]
js  test  web 

REST JMX Monitoring

Ich bin wieder auf der JAX und auch bei Adam Bien. Beides ist nur zu empfehlen! ;-) Während des Workshops kamen wir auf REST und JMX und das es eigentlich eine gute Idee wäre, JMX Monitoring mittels REST anzubieten. Klingt interessant. Sofort ausprobiert.

Mit Eclipse mal fix ein dynamisches Webprojekt erstellt. Drauf geachtet, dass REST (JAX-RS) ausgewählt wird. Glassfish ist schon vom letzten Projekt in Eclipse integriert. Während der Projekterstellung bietet der Wizard u.a. die Konfiguration für REST an. Da kann u.a. das URL matching pattern eingeben werden (default: /rest/*)

[Read More]
jee  jmx  rest 

Derby Export

Beim Einsatz der Java Derby Datenbank kommt irgendwann der Wunsch einzelne Daten oder eine komplette Tabelle zu exportieren. Hierfür bietet Derby verschiedene Procedures an:

  • SYSCS_UTIL.SYSCS_EXPORT_TABLE: Zum exportieren einer kompletten Tabelle
  • SYSCS_UTIL.SYSCS_EXPORT_QUERY: Exportiert die Daten, die dem mitgegebenen SELECT entsprechen
  • SYSCS_UTIL.SYSCS_BACKUP_DATABASE: Kompletter Backup der DB.

Die Export-Procedures liefern eine CSV-Datei, wobei man die Trennzeichen definieren kann. Beim Backup-Procedure wird die ganze Ordnerstruktur in einen gewünschten Ordner kopiert.

Zum Exportieren einer ganzen Tabelle sieht die Signatur der Procedure wie folgt aus:

[Read More]
db2  java