Weekly Snap: OpenLDAP & Jasper Reports, OSMC Partners & Xsensior Sensors

22 – 26 August offered tips on Jasper Reports and OpenLDAP, introduced the OSMC partners and USB sensors for Windows.
To start the week, Pamela announced our partners for this year’s OSMC (Open Source Monitoring Conference). Linux Magazin, Admin Magazin and Thomas Krenn will support us again, while SuSE Linux will for the very first time.
From our hardware store, Martin introduced a simple environmental monitoring device for Windows. The Xsensior Lite USB temperature and humidity sensors come equipped with software to monitor up to 10 sensors displayed in tabs side by side. They can also export .csv metrics to other formats e.g. MS Excel, for further processing and can alert via email. With a USB extension, these simple sensors can also be set up a little further away.
Marius  then offered an easier way to prepare reports – with Jasper and SOAP. Alongside an interface to manage reports and their resources, JasperServer also exports its functionality via SOAP. Installation is easy – either the complete package or just the application can be deployed on a Tomcat server. Report templates can also be created with the report designer iReport, and transferred to the server. Marius showed how to format a report with PHP and recommended a bunch of other docs for more advice.
Finally, Philipp followed with his own 4-step how-to on extending OpenLDAP 2.4 schemas with cn=config.

JasperServer und SOAP

Sich eigene Reports oder sogar erweiterbare Reportframeworks zu schreiben ist mühsam und zeitaufwendig. Vor allem wenn es bereits gute Lösungen in dem Bereich gibt wie z.B. JasperServer. Neben einem eigenem Interface zur Verwaltung von Berichten und deren Ressourcen exportiert der Server gleichzeitig seine ganze Funktionalität durch SOAP nach außen. Die Installation geht mit wenigen Zeilen von statten. Entweder kann man sich ein Komplettpaket ziehen oder nur die Applikation welche auf einem Tomcat Server deployed werden muss.
Jasper Reports können mit einem Reportdesigner (iReport) erstellt werden und auf den Server übertragen werden. Danach können sie entweder direkt abgerufen werden oder zeitgesteuert per Mails verschickt werden.
Mit PHP und etwas gemogel kommt man relativ einfach zu seinem Report im gewünschten Format:

<?php
$jasper_wsdl = 'http://10.121.0.95:8080/jasperserver/services/repository?wsdl';
$client = new SOAPClient($jasper_wsdl, array (
        'login' => 'jasperadmin',
        'password' => 'jasperadmin',
        'trace' => true
));
$request = '<?xml version="1.0" encoding="UTF-8"?>
<request operationName="runReport" locale="en">
        <argument name="RUN_OUTPUT_FORMAT"><![CDATA[PDF]]></argument>
        <resourceDescriptor name="" wsType="" uriString="/Icinga/reports/host.overview" isNew="false">
                <label>null</label>
                <parameter name="p_host_object_id"><![CDATA[1]]></parameter>
        </resourceDescriptor>
</request>';
// Rückgabe ist nicht XML sondern multipart
try {
 $re = $client->runReport($request);
} catch (SOAPFault $e) {
        if ($e->getMessage() !== 'looks like we got no XML document') {
                throw $e;
        }
}
$headers = $client->__getLastResponseHeaders();
$m = array();
// Splitten der Ausgabe und finden des reports
if (preg_match('/boundary="([^"]+)"/', $headers, $m)) {
        $content = explode('--'. $m[1], $client->__getLastResponse());
        foreach ($content as $part) {
                if (strpos($part, 'Content-Id: <report>')!==false) {
                        list($header, $content) = explode("\r\n\r\n", $part);
                        file_put_contents('report.pdf', $content);
                        break;
                }
        }
}

Die Antworten vom Jasper sind MIME multipart/related weshalb man den nativen PHP Soap Client etwas austricken und die die Inhalte zusammensuchen muss.
Der Webservice ist übrigens hervorragend dokumentiert.

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Architekturstile: REST

Vor einiger Zeit sind wir ja bereits auf SOAP intensiv eingegangen. SOAP ist zwar zu Beginn oft Komplex und konfrontiert die Entwickler mit einer etwas anstrengenderen Lernkurve, spielt jedoch auf der Geraden den ein oder anderen Vorteil in Bezug auf komplexe Übermittlungen in heterogenen Umgebungen aus.
REST steht für REpresentational State Transfer und beschreibt ein Architekturmodell, dass man täglich an vielen Stellen des WWW, seinem logischen Vorbild, wiederfindet. Während SOAP “nur” ein Transfermedium von Nachrichten ist, hat REST eine konkrete Vorstellung wie mit entsprechenden Schnittstellen umgegangen wird.
Hierfür stehen die klassischen Web-Methoden GET, POST, PUT und DELETE zur Verfügung. Abhängig von Ihrer Verwendung ist somit auch die grundlegende Funktion beschrieben.
Ein Beispiel:

GET http://rest.service.de/hosts/server1/status

Hier ist klar zu erkennen, dass die Ressourcenauflösung über Pfade dazu verwendet wird ein Objekt eindeutig zu identifizieren und den Status zu ermitteln. Soll ein neuer Status hinzugefügt werden, kann das folglich mit einem POST-Request erfolgen. Die Ausgabe des REST-Kommandos ist im Vergleich zu SOAP nicht im Detail spezifiziert, jedoch wird häufig XML verwendet, da sich die Weiterverarbeitung deutlich einfacher gestaltet. Über den Verweis auf anderer REST-Ressourcen mit Hilfe der sogenannten XLinks’s können auch hierarchische Beziehungen abgebildet und aufgelöst werden.
In dieser Einfachheit liegt der klare Vorteil von REST, da sich der Entwickler, mit Ausnahme der strukturierten Verzeichnisauflösung, an keine definierten Übertragungsformate halten muss und die Anwendung leichtgewichtig gestalten kann. Daraus ergibt sich jedoch auch eine stark verzahnte Kommunikationsebene zwischen Client und Server, da der Spezifikation kein Routingmodell hinterlegt ist.
Die Entscheidung für SOAP oder REST ist, wie bereits im vorhergehenden Artikel erläutert, abhängig vom Bedarf an Komplexität und der Möglichkeit komplexere Transaktionen zu bündeln und zu routen. Der überwiegende Teil an Systemen wird jedoch leicht mit REST auskommen und von den agilen Möglichkeiten profitieren.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Weekly Snap: SOAP architecture, OSDC to OSMC and Schorsch’s latest

12 – 16 July looked at SOAP architecture, reflected on the OSDC and reported on apprenticeship happenings.
As promised, Bernd started his SOAP vs. REST series, with a look at the architecture of SOAP (Simple Object Access Protocol). Unfortunately not so simple, the XML protocol deals with the structure of messages and not the transmission. Compared to REST it needs defined interfaces and namespaces to function properly in large environments with diverse services. This XML overhead makes transmitting large amounts of data particularly slow. On the other hand, SOAP’s advantage lies in the accuracy it demands, as services have to be designed to answer specific requests, eliminating inconsistencies. Its ability to aggregate complex transactions and structure in a message makes it best suited to highly complex needs.
Following on, our apprentice Schorsch gave us his latest update. In sponsorship of the Linux user group and Bernd Stroessenreuther, Schorsch had a chance to set up a new XEN –VM, its volume and network with VLANS and DNS, install FAI and of course integrate it into our Nagios monitoring.
Finally, Manuela made a formal farewell to the 2nd Open Source Data Center Conference, with a few thanks, reflections and images. In particular she noted contributions from Baron Schwartz (MySQL and InnoDB Performance) and Dr. Hendrik Schöttle (Legal Pitfalls in the Data Center), pointing to the presentation slides for all speakers and Linux Magazin Video Archive for participants to access. In the same breath, she invited all to the Open Source Monitoring Conference on Nagios coming up on 6 -7 October – this time with a new day long workshop, ‘Nagios SLA Reporting with Jasper’ on the conference eve. We hope to see you there!

Architekturstile: SOAP

Wie vor einigen Wochen versprochen, möchte ich heute einmal auf das SOAP-Protokoll eingehen. SOAP steht für Simple Object Access Protocol, besser gesagt stand. Seit den letzteren Versionen hat man dieses Akronym aufgrund der hohen Komplexität, die zugegeben mit Simple nicht viel zu tun hat, aufgegeben.
Als Protokoll beschreibt SOAP unter Nutzung von XML eher den Aufbau einer Nachricht als die eigentliche Übertragung. Eine SOAP-Nachricht besteht aus einer Hülle, dem so genannten SOAP-Envelop und beinhaltet einen entsprechenden Header und Body. Während der SOAP-Header optional ist, muss der Body ausgeführt sein und kann noch ein entsprechendes SOAP-Fault Element enthalten um Fehlersituationen zu übermitteln.
Ein Beispiel für eine gültige SOAP-Nachricht:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.icinga.org/status">
  <m:GetStatus>
    <m:ServerStatus>srv-lin-01</m:StockName>
  </m:GetStatus>
</soap:Body>
</soap:Envelope>

Zwar ist HTTP oder HTTPS der häufigste Standard um entsprechende Nachrichten zu übermitteln, es ist jedoch auch eine alternative Nutzung von JMS, SMTP oder anderen Transportmodellen möglich.
Im Unterschied zu REST, dazu bald mehr, ist SOAP kein leichtgewichtiges Unterfangen. Es Bedarf wohl definierten Schnittstellen und Namespaces um sich bei verschiedenen Services in größeren Umgebungen nicht in die Quere zu kommen und ist aufgrund des entsprechenden XML-Overheads bei der Übertragung von großen Datenmengen nicht besonders performant. Diese Nachteile verlieren durch immer größere Bandbreiten und entsprechende Performance jedoch zunehmend an Bedeutung und auch die entsprechende XML-Parser haben in Sachen Geschwindigkeit ordentlich zugelegt.
Der große Vorteil von SOAP liegt darin, dass ein entsprechender Service genau auf die Beantwortung bestimmter Requests vorbereitet werden muss und somit schon auf Schnittstellenebene gewisse Unstimmigkeiten eliminiert werden können. Ein “ungefähr” Request wird freundlich vom Server zurückgewiesen und vermeidet eine fehlerhafte Verarbeitung auf Definitionsebene.
Die beliebige Komplexität eines SOAP-Envelops ermöglicht jedoch die Zusammenfassung komplexer Transaktionen und Strukturen in einer Nachricht. So kann der Overhead der Einzelabfrage reduziert werden und komplexe Zusammenhänge einfacher dargestellt werden als durch Abbildung einer Vielzahl von REST-Requests.
Eine Entscheidung zugunsten von SOAP sollte nur bei Notwendigkeit der entsprechenden Komplexität fallen, ist dann aber oft auch sinnvoll.
Handle with Care!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Weekly Snap: Heatmap for Icinga, JIT cool, Windows 2000 and SOAP/REST?

14 – 18 June warned Windows 2000 users of looming support freezes, gawked in awe at JIT, shared Julian’s LinuxTag presentation, introduced the SOAP and REST developer conflict and announced our first Icinga addon.
Reflecting on hot summer days in data centers, Jannis revealed Heatmap for Icinga. Now while enjoying ice cream, admins can view their server room and react quickly to temperature problems. With a drag and drop, servers and sensors can be laid out on the map and intervals for temperature processing set. Replete with dashboard, it integrates seamlessly into Icinga Web and is ready for download at netways.org as always.
We paid our respects to JIT (JavaScript InfoVis Toolkit) while Julian shared his presentation slides from LinuxTag in Berlin on Nagios and Icinga. He then went on to bring bad news to Windows 2000 users – as of 13 July 2010, Microsoft will end support for all Windows 2000 regardless of type. This means no free updates or security updates, which may also mean security problems will no longer be fixed. On the same day, normal support for Windows 2003 Server (and Server R2) will run out and only extended support will be provided. So only issues critical to security will be fixed, for all others a patch will be offered only to those in their paid support program. This extended support will be available to 14 July 2015- so it seems now is high time to switch out!
Finally, Bernd introduced his new series to tackle the SOAP or REST question which all developers inevitably face in service oriented development. He plans to look at both architectures in detail and compare their advantages and disadvantages. In the meantime he pointed to a previous post from Julian for a good starting point. Till then, keep your eyes peeled!

SOAP oder REST: Was ist los?

Im Bereich der serviceorientierten Entwicklung steht der Developer häufig zu Beginn vor der entscheidenden Frage:
SOAP oder REST
Gleich vorweggenommen sei die Tatsache, dass auch diese kleine Serie keine universelle Antwort auf eine solche Frage geben kann. Es ist vielmehr der Versuch etwas Licht ins Dunkle zu bringen und die Vorteile beider Möglichkeiten zu erörtern. Letztendlich geht es wie immer um die richtig Lösung für die vorhandene Aufgabenstellung und vorhandenem Knowhow.
Grundsätzlich trifft es das Bild von Julian’s Blog Post ganz gut, jedoch ist die Tatsache das wenig “gesprochen” wird nicht nur ein Vorteil.
Die nächsten Tage werde ich auf beide Architekturmodelle etwas detaillierter eingehen und deren Vor- und Nachteile erörtern.

(via Geek And Poke)

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Soap Is Much More Polite Than Rest

6a00d8341d3df553ef012875f312f9970c-800wi
Aus dem fantastischen Blog Geek And Poke

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.