Seite wählen

NETWAYS Blog

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 IT Service Management

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

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:
[code lang=“xml“]
GET
[/code]
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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

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:
[code lang=“xml“]
<?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>
[/code]
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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.