Software Development Trends: Wegweisende Beiträge für eine neue IT: Wegweisende Beiträge für eine neue IT

Von entwickler.press

Die IT-Branche ist ständig in Bewegung. Dabei verliert man leicht den Überblick über neue Technologien und Trends. Bei den rasanten Änderungen, der stetig voranschreitenden Digitalisierung sowie der Komplexitätszunahme soll das Buch als Leitfaden dienen, der diesen Wandel untermauert und gleichzeitig durch ihn navigiert. Diese Sonderedition umfasst eine Auswahl der zentralen Themen und Artikel des Jahres 2013 und impliziert gleichzeitig die wegweisenden Trends 2014. Das Themenspektrum reicht von Mobile, Webentwicklung, Big Data, Softwarearchitektur und Agilität bis hin zu aktuellen Releases der wichtigsten Programmiersprachen.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 18. Dez. 2013
• ISBN: 9783868026382

Buchvorschau

Sebastian Meyen (Hg.)

Software-Development-Trends – Wegweisende Beiträge für eine neue IT

ISBN: 978-3-86802-638-2

© 2013 entwickler.press

Ein Imprint der Software & Support Media GmbH

Bibliografische Information Der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Ihr Kontakt zum Verlag und Lektorat:

Software & Support Media GmbH

entwickler.press

Darmstädter Landstraße 108

60598 Frankfurt am Main

Tel.: [phone]

Fax: [phone]

[e-mail]

http://www.entwickler-press.de

Projektleitung: Sebastian Burkart

Lektorat: Theresa Vögle

Korrektorat: Nicole Bechtel, Jennifer Diener, Frauke Pesch

Satz: Dominique Kalbassi

Covergestaltung: Maria Rudi

Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

Liebe Leserinnen und Leser,

das Softwareleben war schon immer rasanten Änderungen unterworfen. Was gestern noch Trend war, wird heute schon Alltag und zählt morgen zum alten Eisen. Aber so schnell wie derzeit hat sich das Rad der digitalen Innovation noch nie gedreht.

Noch wichtiger ist dabei aber die Erkenntnis, dass die Digitalisierung zunehmend über Erfolg und Misserfolg eines Geschäfts – und zwar in der Mehrzahl aller Branchen – entscheidet. Eine große Ehre für uns, die wir in der IT-Branche arbeiten, aber eine noch viel größere Verpflichtung!

Werden wir den Herausforderungen, die da kommen, eigentlich gerecht mit unseren traditionellen Tools, Technologien und Vorgehensweisen? Oder müssen wir nicht vielmehr radikal umdenken? Das Feld an Themen, das wir überschauen und bearbeiten müssen, erweitert sich schnell: Mobile und Big Data, die Notwendigkeit perfekter User Experience, dramatisch beschleunigte Releasezyklen, enorme Skalierung ohne jeden Performanceverlust … dazu eine Fülle an mobilen und stationären Devices mit ihren eigenen Technologien, das Internet der Dinge.

Was für manche Leser heute wie ein wildes Buzzword-Bingo erscheinen mag, wird bereits morgen in seinem Zusammenwirken Realität werden. IT-Experten werden zu Komplexitätsmanagern.

Um Ihnen dabei zu helfen, den Überblick zu behalten, haben wir in diesem Buch eine Fülle an Beiträgen zusammengestellt, die in ihrer Summe diesen Wandel treffend beschreiben. Wir, das ist die Redaktion von Software & Support Media, die wir die Zeitschriften Java Magazin, Windows Developer, PHP Magazin, Entwickler Magazin, Mobile Technology, Business Technology, Eclipse Magazin und SharePoint Kompendium herausgeben. Die Beiträge, die Sie in diesem Buch finden, sind in den genannten Magazinen erschienen.

Die Zusammenstellung ist kein „Best of, denn es gäbe noch viele weitere Artikel, die wir Ihnen empfehlen könnten. Es handelt sich vielmehr um eine Auswahl, die wir als Ensemble besonders aussagekräftig finden – „wegweisende Beiträge für 2014.

Ich wünsche Ihnen eine spannende und inspirierende Lektüre!

Sebastian Meyen, Chief Content Officer Software & Support Media GmbH

Typisierte Web-APIs mit Node.js und TypeScript

TypeScript-Turbo für Web-APIs

Rainer Stropek

Web-APIs, also APIs auf Basis der im Web üblichen Standards HTTP und JSON, sind im Internet mittlerweile zur Lingua franca geworden. Ihr großer Vorteil ist ihre Reichweite. Egal ob Smartphones, Tablets, Laptops, Server – Web-APIs sind der kleinste gemeinsame Nenner, mit dem praktisch jede gängige Plattform umgehen kann. In diesem Artikel zeige ich Ihnen an einem durchgängigen Beispiel, wie Sie mit Node.js, TypeScript und einigen Java­Script-Bibliotheken ein Web-API anbieten und typsicher mit jQuery konsumieren können. Sie werden sehen, wie Geschäftslogik einmal entwickelt auf Client und Server verwendet werden kann. Abschließend veröffentlichen wir das entstandene Projekt mit einer Hand voll Kommandos in Windows-Azure-Websites.

Als Entwickler auf der Windows-Plattform denkt man bei Web-APIs natürlich als Erstes an die gleichnamige Technologie, die Microsoft zur aktuellen Version von ASP.NET MVC hinzugefügt hat [5]. Mit .NET vertraute Entwickler werden sich darin sofort wie zu Hause fühlen. Die gewohnte Programmiersprache, die gewohnte Klassenbibliothek, die vertraute Entwicklungsumgebung Visual Studio. Hat man jedoch die Aufgabe, eine Gesamtlösung bestehend aus Web-UI und Web-API zu erstellen, steht man vor einer Herausforderung: Im Webclient stehen – sofern man Silverlight als Browser-Plug-in außer Acht lässt – weder C# noch die .NET-Klassenbibliothek zur Verfügung. Man muss sich zumindest für den Webclient zwangsläufig mit JavaScript auseinandersetzen. Mischt man aber ASP.NET MVC Web API am Server und JavaScript am Client, verliert man die Möglichkeit von Codewiederverwendung zwischen Client und Server. Wäre es nicht schön, Datenstrukturen für typsicheren Umgang mit dem Web-API zwischen Client und Server zu teilen? Will man wirklich Logik für beispielsweise Validierung von Formulardaten in zwei verschiedenen Sprachen doppelt entwickeln? Ein einheitliches Programmiermodell, eine gemeinsame Programmiersprache und Codewiederverwendung vom Server bis zum Webclient kann nur die durchgängige Verwendung von JavaScript bieten.

Hinweis zum Codebeispiel

Dieser Artikel demonstriert die behandelten Sprachen, Tools und Bibliotheken an einem Beispiel. Die wichtigen Teile des Quellcodes sind abgedruckt. Wenn Sie selbst mit dem Beispiel experimentieren möchten, können Sie den kompletten Code unter [1] herunterladen. Sie müssen zum Übersetzen und Starten des Beispiels folgende Systemvoraussetzungen erfüllen:

Als Programmiersprache wird TypeScript verwendet. In der Ausgabe 1.2013 des Windows Developer Magazins habe ich diese neue Sprache bereits vorgestellt. Damit Sie TypeScript-Quellcode in JavaScript übersetzen können, brauchen Sie den TypeScript-Compiler, den Sie unter [2] herunterladen können.

Grundsätzlich können Sie die TypeScript Sourcen mit tsc, der Kommandozeilenversion von TypeScript, kompilieren. Richtig Spaß macht die Entwicklung allerdings erst mit Visual Studio und den zugehörigen TypeScript-Tools. Visual Studio bringt Ihnen einen der entscheidenden Vorteile von TypeScript im Vergleich zu JavaScript: IntelliSense. Auch die Visual-Studio-Tools für Type Script finden Sie unter [2].

Zum Ausführen des Web-API auf Ihrem Computer brauchen Sie

Node.js. Sie können Node.js unter [3] herunterladen.

Wir werden im Beispiel TypeScript-Typdateien von GitHub laden und unser Projekt über Git in Windows-Azure-Websites veröffentlichen. Aus diesem Grund müssen Sie Git auf Ihrem Computer installieren. Sie können es unter [4] herunterladen.

Wie in der Ausgabe 1.2013 des Windows Developer Magazins bereits ausführlich berichtet, halten mit Type­Script Typinformationen Einzug in JavaScript. Im Gegensatz zu anderen Sprachen, die in JavaScript kompiliert werden, ist TypeScript jedoch nur eine Erweiterung von JavaScript. Ein gültiges JavaScript-Programm ist automatisch auch ein gültiges Type­Script-Programm. Als Entwickler können wir punktuell auf die TypeScript-Erweiterungen zurückgreifen, wo es uns sinnvoll erscheint. Wir verlieren jedoch weder die Kompatibilität noch die Flexibilität von JavaScript. Typinformationen vereinfachen die Verwendung von JavaScript und der dafür bestehenden Bibliotheken massiv. Schließlich hat man sich an IntelliSense und Typprüfungen zur Übersetzungszeit gewöhnt. Viele wollen darauf nicht verzichten und mit TypeScript müssen sie es trotz JavaScript als Zielplattform auch nicht.

Schritt 1 – Datenstruktur und Geschäftslogik

Unser Ziel ist es, ein Web-API für den Zugriff auf Kundendaten zu entwickeln. Listing 1 definiert ein TypeScript-Modul customer. Die Datenstrukturen (Interface ICustomer, Klasse Customer) und die darin enthaltene Logik (Methode Customer.fullName) sollen auf Client und Server identisch wiederverwendet werden, damit einerseits der Zugriff auf das Web-API typsicher wird und andererseits die Logik nur einmal entwickelt werden muss. Beachten Sie beim Durchsehen des Codes in Listing 1 eine Besonderheit, die mit einer der neueren Previewversion von TypeScript ergänzt wurde: Unterstützung für JSDoc [6].

Listing 1

export module customer {

    /**

      * Represents a customer

      * @param firstName First name of customer

      * @param lastName Last name of customer

      */

    export interface ICustomer {

        firstName: string;

        lastName: string;

    }

    /**

      * Represents a customer

      */

    export class Customer implements ICustomer {

        public firstName: string;

        public lastName: string;

        constructor (arg: ICustomer = { firstName: , lastName: }) {

            this.firstName = arg.firstName;

            this.lastName = arg.lastName;

        }

        /**

          * Returns the full name of the customer

          */

        public fullName() {

            return this.lastName + , + this.firstName;

        }

    }

}

Übersetzt man das TypeScript-Modul aus Listing 1 mit dem Kommando tsc customer.ts, erhält man den JavaScript-Code, den wir am Server für die Implementierung des Web-API nutzen können. Listing 2 enthält den JavaScript-Code, der aus unserem TypeScript-Modul wird. Achten Sie darauf, dass die Typinformationen (z. B. das Interface ICustomer) im JavaScript-Code nicht mehr zu finden sind. Sie werden nur vom TypeScript-Compiler und Visual Studio verwendet, führen jedoch zur Laufzeit zu keinem unnötigen Performance-Overhead.

Listing 2

(function (customer) {

    var Customer = (function () {

        function Customer(arg) {

            if (typeof arg === undefined) { arg = {

                firstName: ,

                lastName:

            }; }

            this.firstName = arg.firstName;

            this.lastName = arg.lastName;

        }

        Customer.prototype.fullName = function () {

            return this.lastName + , + this.firstName;

        };

        return Customer;

    })();

    customer.Customer = Customer;

})(exports.customer || (exports.customer = {}));

var customer = exports.customer;

Schritt 2 – Web-API mit express

Wie wird nun das eigentliche Web-API umgesetzt? Natürlich wäre es denkbar, mit den Bordmitteln von ­Node.js ein Web-API zu programmieren. Das wäre aber in der Praxis viel zu aufwändig. Wir nutzen stattdessen ein Node.js-Modul namens express [7]. Es erlaubt es, für HTTP Verbs (z. B. GET, POST etc.) Funktionen anzugeben, die bei entsprechenden HTTP Requests aufgerufen werden (z. B. app.get(/customer/:id, function (req, resp) { … });). Darüber hinaus können auch Routen registriert werden, über die auf statische Dateien (z. B. HTML, CSS, JavaScript) zugegriffen werden kann (z. B. app.use(/, express.static(__dirname + /website/));). Listing 3 zeigt die TypeScript-Quellcodedatei server.js, die wir in unserem Beispiel zur Umsetzung des Web-API verwenden.

Listing 3

/// ../DefinitelyTyped/node/node.d.ts />

/// ../DefinitelyTyped/express/express.d.ts />

/// ./customer.ts />

import express = require(express);

import crm = require(customer);

var app = express();

app.get(/customer/:id, function (req, resp) {

    var customerId = req.params.id;

    var c = new crm.customer.Customer(

        { firstName: Max + customerId.toString(), lastName: Muster });

    console.log(c.fullName());

    resp.send(JSON.stringify(c));

});

app.get(/customer, function (req, resp) {

    var customers: crm.customer.Customer [];

    customers = new Array();

    for (var i = 0; i<10; i++) {

        customers.push(new crm.customer.Customer(

            { firstName: Max + i.toString(), lastName: Muster }));

    }

    resp.send(JSON.stringify(customers));

});

app.use(/, express.static(__dirname + /website/));

var port = process.env.PORT || 1337;

app.listen(port);

Wenn Sie den Code aus Listing 3 in Visual Studio öffnen oder versuchen, ihn mit tsc server.js zu übersetzen, werden Sie als Ergebnis eine Fehlermeldung erhalten. Der Grund sind die ersten Kommentarzeilen mit den reference-Anweisungen. Sie verweisen auf TypeScript-Module, die im Code verwendet werden. customer.ts ist das von uns zuvor bereits erstellte customer-Modul. Woher nehmen wir aber die TypeScript-Typdateien für das Node.js-SDK (node.d.ts) und das express-Modul (express.d.ts)? Man bedient sich hier einer besonderen Eigenschaft von TypeScript: Die Sprache erlaubt es, dass man Typinformationen zu einer bestehenden JavaScript-Bibliothek in getrennten .d.ts-Dateien hinzufügt, ohne die eigentliche JavaScript-Bibliothek verändern zu müssen. Solche externen Typ­informationen bezeichnet man in TypeScript als Ambient Declarations. Im Communityprojekt DefinitelyTyped [8] wurden erste Versionen solcher Typinformationen für die meisten der gängigen JavaScript-Frameworks bereits entwickelt. Wir brauchen sie uns nur von GitHub zu laden:

Erstellen Sie dazu einen eigenen Ordner (in unserem Beispiel Defi­nitelyTyped genannt).

Initialisieren Sie in dem neuen Ordner ein Git Repository mit dem Kommando git init.

Laden Sie die notwendigen Dateien von GitHub mit dem Kommando git pull https://github.com/boris­yankov/DefinitelyTyped.git.

Wenn Sie jetzt server.ts in Visual Studio öffnen, werden Sie sowohl für express- als auch für unser customer-Modul IntelliSense nutzen können. Sie können die Datei jetzt auch fehlerlos mit dem Kommando tsc server.ts in JavaScript übersetzen.

Ein Schritt fehlt noch, bevor wir unser Web-API testen können. Wir müssen die JavaScript-Dateien des express-Frameworks laden, die wir zur Laufzeit brauchen. Bisher haben wir schließlich nur die Typinformationen für den TypeScript-Compiler bereitgestellt. Analog zu NuGet als Package Manager für .NET gibt es auch einen Package Manager für Node.js. Er heißt Node Package Manager (npm). Um das Paket für express zu laden, legen wir die Datei package.json an und tragen dort die entsprechende Abhängigkeit ein. Listing 4 zeigt, wie das gemacht wird.

Listing 4

{

  name: customer-service,

  description: Customer Web API,

  version: 0.0.1,

  private: true,

  dependencies: {

    express: 3.1.0

  }

}

Nach dem Eintragen der Abhängigkeit kann der Node Package Manager alle notwendigen Dateien für uns aus dem Internet laden. Sie führen dazu einfach das Kommando npm install in dem Verzeichnis aus, in dem Ihre package.json-Datei liegt.

Unser Web-API ist fertig entwickelt und wir können es testen. Sie starten dafür mit node server.js den Server. Mit einem Browser Ihrer Wahl oder auch mit einem Web-Debugger wie Fiddler [9] können Sie Kunden abfragen, indem Sie http://localhost:1337/customer aufrufen. Das Ergebnis sollten Customer-Objekte im JSON-Format sein.

Schritt 3 – Web-API mit jQuery verwenden

Im nächsten Schritt wollen wir unser Beispiel um einen browserbasierenden Client erweitern. Wir wollen von JavaScript aus mit jQuery [10] auf unser Web-API zugreifen. Das alleine wäre noch nichts Besonderes. Unsere Implementierung zeichnet sich aber durch zwei Besonderheiten aus:

Wir nutzen TypeScript und können daher jQuery typsicher und mit IntelliSense verwenden.

Client und Server verwenden beide unser customer-Modul. Auf diese Weise erfolgt auch die Verarbeitung der Ergebnisse des Web-API typsicher und mit IntelliSense. Darüber hinaus steht die exemplarisch hinzugefügte Logik auch am Client zur Verfügung.

Wenn Sie Visual Studio verwenden und die Tools für TypeScript [2] installiert haben, steht Ihnen eine eigene Projektvorlage für Webprojekte mit TypeScript zur Verfügung (Abb.1). In unserem Fall legen wir im Unterverzeichnis website ein solches Projekt an. Auf die Dateien des Projekts kann man über die statische Route, die unser Programm server.ts angelegt hat, zugreifen (Listing 3).

Abb. 1: Projektvorlage für Webprojekt mit TypeScript

Bevor wir unser customer-Modul in das Webprojekt einbauen, müssen wir uns damit auseinandersetzen, welchen Code TypeScript für Module generiert. In Listing 2 habe ich bereits gezeigt, welchen Code der TypeScript-Compiler standardmäßig erzeugt. Er passt wunderbar für die Verwendung am Server in Node.js. Am Client ist er in der Praxis so aber nicht verwendbar. Für größere, nicht triviale Webanwendungen, die sich aus vielen Modulen mit entsprechenden Abhängigkeiten zusammensetzen, brauchen wir ein Modul, das dem Asynchronous-Module-Definition-(AMD-)API entspricht (Kasten: „Asynchronous Module Definition (AMD)"). Solche Module können clientseitig z. B. mit der JavaScript Library RequireJS [12] asynchron geladen werden. RequireJS berücksichtigt dabei Abhängigkeiten der Module untereinander. Natürlich stehen im oben erwähnten Projekt DefinitelyTyped [8] Typinformationen für Re­quire­JS zur Verfügung. Typsicherheit und IntelliSense im Umgang mit RequireJS sind dadurch gewährleistet.

Asynchronous Module Definition (AMD)

In größeren JavaScript-Projekten ist es notwendig, den Code in Module zu unterteilen. Die Sprache JavaScript beinhaltet kein Modulkonzept, das dafür verwendet werden könnte. Die CommonJS-(CJS-)Initiative, ein Gremium, das es sich zum Ziel gesetzt hat, die Grundlagen für eine einheitliche JavaScript-Standard-Library zu erarbeiten, hat daher eine Definition für ein Modul für JavaScript festgelegt [11]. Das Konzept enthält außerdem ein API zum Referenzieren und Laden von Modulen. Die Website der JavaScript Library RequireJS, auf die wir im Beispiel dieses Artikels verweisen, enthält eine gute Einführung über die Gründe für JavaScript-Module [13].

Das AMD-Format baut teilweise auf dem Modulkonzept von CommonJS auf. Es behandelt insbesondere die Angabe von Abhängigkeiten zwischen Modulen und das asynchrone Laden von Modulen. Für das AMD-Format stehen eine Reihe von Loader-Frameworks zur Verfügung. Die Website von RequireJS enthält eine gute Einleitung in AMD, die unter anderem auch darauf eingeht, wie sich AMD von CommonJS-Modulen unterscheidet [14].Der TypeScript-Compiler kann Module generieren, die dem AMD-Format entsprechen. Dazu gibt man in der Kommandozeile die Option --module AMD an. Listing 5 zeigt, welcher Code aus unserem customer-Modul entsteht, wenn man es mit der AMD-Option kompiliert. Aus Gründen der Übersichtlichkeit habe ich die Implementierung der Klasse Customer ausgelassen, da sie sich nicht von Listing 2 unterscheidet. Achten Sie in Listing 5 insbesondere auf den Aufruf von define(…). Dadurch wird das AMD-Modul angelegt. Streng genommen wird eine Factory-Funktion definiert, die von RequireJS aufgerufen wird, wenn alle Abhängigkeiten (erster Parameter der Funktion define) geladen sind. Die AMD-Compileroption macht es auf diese Weise möglich, TypeScript-Module in Web-APIs server- und clientseitig unverändert zu verwenden.

Listing 5

define([require, exports], function(require, exports) {

    (function (customer) {

        var Customer = (function () { ... /* wie in Listing 2 */ })();

        customer.Customer = Customer;

    })(exports.customer || (exports.customer = {}));

    var customer = exports.customer;

})

Damit Visual Studio die AMD-Compileroption beim Übersetzen unseres Webprojekts verwendet, muss man in der aktuellen TypeScript-Previewversion noch die Projektdatei manuell ändern. Man fügt, wie in Listing 6 gezeigt, den PropertyGroup-Elementen für die gewünschten Build-Konfigurationen die Option TypeScriptModuleKind AMD hinzu. Dadurch verwendet Visual Studio die AMD-Compileroption beim Übersetzen von TypeScript-Dateien.

Listing 6

'$(Configuration)' == 'Debug'>

  ES3

  true

  true

  AMD

Nachdem wir jetzt unser customer-Modul für die Nutzung im Browserclient bereit gemacht haben, müssen wir uns an den Aufruf unseres Web-API mit jQuery machen. Listing 7 zeigt, wie es gemacht wird. Beachten Sie beim Durchsehen des Codes insbesondere folgende Punkte:

Der Code enthält einen Verweis auf die TypeScript-Typinformationen für jQuery. In Visual Studio haben Sie daher für jQuery IntelliSense und Typprüfung beim Kompilieren.

Aus dem import-Statement im TypeScript-Code wird eine Abhängigkeit des entstehenden AMD-Moduls. In Listing 8 finden Sie den relevanten Teil des JavaScript-Codes, der vom TypeScript-Compiler erzeugt wird. Sie sehen die Abhängigkeit im ersten Parameter der define(…)-Methode.

Die Kundendaten im JSON-Format, die von unserem Web-API zurückgegeben werden, verwenden wir, um eine Instanz unserer Customer-Klasse anzulegen. Dadurch wird die Arbeit mit dem Ergebnis des Web-API erstens typsicher (Variable c ist vom Typ Customer), wir haben IntelliSense und wir können die entwickelte Logik (Customer.fullName) am Client wiederverwenden.

Eine Besonderheit von TypeScript, die insbesondere auch beim Konsumieren von Web-APIs nützlich ist, sieht man beim Aufruf des Konstruktors der Klasse Customer. Dort übergeben wir die untypisierten Objekte, die durch Parsen des JSON-Ergebnisses aus dem Web-API entstehen. Wenn Sie jedoch die Methodensignatur des Konstruktors in Listing 1 ansehen, entdecken Sie, dass er ein Objekt des Typs ICus­tomer verlangt. Dieser scheinbare Widerspruch wird von Type­Script durch das so genannte Structural Subtyping gelöst. Jedes Objekt, das alle für das Interface notwendigen Members enthält, ist automatisch mit dem Interface kompatibel.

Listing 7

/// ../lib/jquery.d.ts />

import cust = module(app/classes/customer);

export class AppMain {

    public run() {