Anmelden
Das Eclipse-MicroProfile-Projekt ist angetreten, eine portable Lösung für Microservices im Enterprise-Java-Umfeld zu liefern. Neue APIs sollen die Lücke zwischen dem Java-EE-Standard und den Praxisanforderungen von Microservices-Architekturen schließen.
Microservices und Java EE (a.k.a. EE4J)? Das passt nicht wirklich! So zumindest die landläufige Meinung, wenn es darum geht, Microservice-Anwendungen auf Grundlage des Java-Enterprise-Standard umzusetzen. Dabei bietet Java EE mit JAX-RS, CDI, JPA und JSON-P alles, was es braucht, um RESTful-Microservices zu implementieren. Und auch asynchrone, auf Messages oder Events basierende Services lassen sich dank JMS, WebSockets und Server-Sent Events (seit Java EE 8) mit wenigen Zeilen Code realisieren. Wo also liegt das Problem?
Microservice-Anwendungen zeichnen sich in der Regel dadurch aus, dass eine Vielzahl von Services, die jeweils in eigenen Prozessen laufen, miteinander interagieren und so ein großes Ganzes ergeben. Nicht selten werden diese Services zusätzlich in Containern verpackt und in der Cloud deployt. Unterm Strich haben wir es also mit einem hoch dynamischen, stark verteilten System zu tun.
Die eigentliche Herausforderung liegt somit weniger in der Umsetzung der (fachlichen) Logik eines einzelnen Service als vielmehr in der Realisierung des reibungslosen Zusammenspiels der Gesamtheit aller Services. Und genau hier liegt das Problem beziehungsweise die Schwachstelle von Java EE. Denn Java EE ist darauf ausgerichtet, dass die einzelnen Artefakte – in diesem Fall also die Services – innerhalb eines Application Server deployt werden, damit dieser übergreifende Dienste (Cross-Cutting Concerns) wie Configuration, Monitoring, Logging, Security et cetera übernehmen kann. Fällt der Server weg oder gibt es mehrere autarke Server-Instanzen, von denen jede einen eigenen Microservice verwaltet, fehlt die koordinierende Schaltzentrale.
Genau dieses Manko hat auch eine Reihe von Application-Server-Anbietern erkannt und 2016 die Initiative MicroProfile.io[1] ins Leben gerufen. Die inzwischen in der Eclipse Foundation beheimatete Initiative ist angetreten, die Lücke zwischen dem Java-Enterprise-Standard und den Praxisanforderungen Microservices-basierter Architekturen zu schließen. Laut eigener Aussagen möchte man das bestehende Momentum der Java-EE-Community als Hebel nutzen und organisch um den Bedarf der Microservices-Community ergänzen. Der Plan scheint aufzugehen. In nur wenigen Monaten ist es gelungen, eine Reihe sinnvoller Microservices-relevanter APIs mit bestehenden Java-EE-7/8-APIs zu kombinieren und diese in regelmäßigen MicroProfile-Releases zu veröffentlichen. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, MicroProfile scheint die richtigen Antworten – sprich APIs – im Gepäck zu haben.
Dieser Blogbeitrag ist der erste Teil einer kleinen Serie, die sich mit den Microservice-spezifischen APIs des MicroProfiles beschäftigt. Also den APIs, die nicht Bestandteil der Java-EE-Spezifikation sind. Den Anfang macht die Config API, die erst vor wenigen Tagen in der Version 1.2 veröffentlicht wurde.
Die Idee, Anwendungslogik und Konfiguration voneinander zu trennen, ist nicht wirklich neu. Mithilfe einer ausgelagerten Konfiguration lässt sich die Anwendung beziehungsweise der Service von außen auf die jeweilige Laufzeitumgebung anpassen. Für die lokale Testumgebung nutzt man zum Beispiel im Test-Quellcode vorgegebene Einstellungen, während die Laufzeitumgebung des Containers in einer produktiven Umgebung innerhalb eines Containers in der Cloud die notwendigen Werte für die Konfiguration setzt.
Was einfach klingt, kann in der Praxis zu unerwarteten Herausforderungen führen. So stammen die einzelnen Werte für die Konfiguration einer Anwendung beziehungsweise eines Service in der Regel aus mehreren verschiedenen Quellen, wie System Properties, Umgebungsvariablen, Dateien, Datenbanken oder proprietären Konfigurationsquellen. Auch das Format, in dem die Werte abgelegt sind, ist oftmals nicht einheitlich und entspricht normalerweise nicht dem Objektformat, in dem die Konfigurationswerte innerhalb der Anwendung beziehungsweise des Service verwendet werden sollen. Während es bei statischen Konfigurationswerten ausreicht, diese einmalig beim Start zu laden, sind dynamische Werte permanent auf ihre Aktualität zu prüfen und bei Bedarf neu einzulesen. Und natürlich sollte eine Anwendung auch dann noch sinnvoll funktionieren, wenn eine Konfiguration einmal nicht gefunden werden kann.
All diese Aspekte und noch etliche mehr berücksichtigt die MicroProfile Config API (im Folgenden Config API). Sie bietet einen vereinheitlichen Zugriff auf verschiedenste Konfigurationsquellen an. Die einzelnen Quellen lassen sich dabei mit Prioritäten versehen, sodass ein gezieltes Überschreiben von Konfigurationen möglich wird. Von Haus aus kennt die Config API drei verschiedene Quellen:
Standardwerte für die Konfiguration können so in einer Datei mit dem Namen microproifile-config.properties im Verzeichnis META-INF abgelegt und bei Bedarf in den jeweiligen Deployment-Umgebungen überschrieben werden. Natürlich ist es auch möglich, eigene Quellen einzubinden und mit einer individuellen Priorität zu belegen. Zum Beispiel ließe sich ein zentraler Key-Value-Store als weitere Konfigurationsquelle verwenden.
Die Config API bietet zwei unterschiedliche Wege zum Zugriff auf die im Hintergrund verwalteten Konfigurationen. Zum einen kann der Zugriff programmatisch erfolgen, zum anderen via CDI Injection.
Der programmatische Zugriff erfolgt mithilfe einer Instanz der Config-Klasse, die sich im einfachsten Fall via ConfigProvider erzeugen lässt:
// get access to the Config instance via ConfigProvider
Config config = ConfigProvider.getConfig();// access config properties via Config instance
String someStringValue = config.getValue("SOME_STRING_KEY", String.class);
Boolean someBooleanValue = config.getValue("SOME_BOOL_KEY", Boolean.class);
Möchte man beim Erstellung der Config-Instanz mehr Einfluss nehmen, kann anstelle des ConfigProvider auf einen ConfigBuilder zurückgegriffen werden. Der Builder erlaubt die eine oder andere individuelle Anpassung. Der oben gezeigte Code würde mit einem ConfigBuilder wie folgt aussehen:
// get access to the Config instance via ConfigBuilder
ConfigBuilder builder = ConfigProviderResolver.getBuilder();
builder.addDefaultSources();
Config config = builder.build();// access config properties via Config instance
String someStringValue = config.getValue("SOME_STRING_KEY", String.class);
Boolean someBooleanValue = config.getValue("SOME_BOOL_KEY", Boolean.class);
Anmerkung: Bei der Verwendung des ConfigProvider wird die beim Aufruf der getConfig()-Methode zurückgelieferte Config-Instanz aus Gründen der Effizienz automatisch gecacht. Das ist bei der Verwendung des ConfigBuilder beziehungsweise des ConfigProviderResolver nicht der Fall.
Deutlich einfacher als der ebene gezeigte programmatische Zugriff ist der via CDI Injection:
FreshRSS @Inject @ConfigProperty("SOME_STRING_KEY")
String someStringValue; @Inject @ConfigProperty("SOME_BOOL_KEY")
String someBooleanValue;
Was aber, wenn sich der gesuchte Schlüssel in keiner der Konfigurationsquellen finden lässt? Im obigen Beispiel würde das automatisch zu einer Exception führen. Im ersten Beispiel, dem programmatischen Zugriff, wäre es eine NoSuchElementExeption zur Laufzeit. Im zweiten Beispiel dagegen, im Falle der CDI Injection, würde eine DeploymentException während des Start-ups geworfen werden.
Soll eine Konfiguration lediglich optional sein, um so zum Beispiel nur in speziellen Umgebungen Standardwerte zu überschreiben, in anderen dagegen nicht, ist dies ebenfalls für beide gezeigten Zugriffsmechanismen möglich. Im Falle des programmatischen Zugriffs sieht das wie folgt aus:
// get access to the Config instance
Config config = ConfigProvider.getConfig();// access optional string property
String someStringValue = config.getOptionalValue("SOME_KEY", String.class)
.orElse("someDefaultValue");
Bei CDI Injection dagegen reicht die einfache Angabe eines Default-Werts vom richtigen Typ:
// inject optional property
@Inject @ConfigProperty("SOME_KEY", defaultValue="someDefaultValue")
String someValue;
Auch wenn Microservice-basierte Anwendungen so entworfen sein sollten, dass sie einen Restart einzelner Services problemlos überleben, macht es sicherlich keinen Sinn, einen Service jedes Mal neu zu starten, nur weil sich ein Wert einer Konfiguration geändert hat. Aus diesem Grund sieht die Config API einen Mechanismus vor, Konfigurationswerte dynamisch in dem Moment der Verwendung zu laden.
Das macht natürlich wenig Sinn, wenn die Konfigurationsquelle eine gemeinsam mit dem WAR deployte Properties-Datei ist. Anders dagegen sieht es schon aus, wenn als Quelle eine Datenbank oder ein Konfigurationsserver angebunden wird.
Um in dem Moment der Nutzung einer Property tatsächlich immer ihren aktuellen Wert und nicht den Wert zum Zeitpunkt der Injection zu erhalten, muss anstelle der ConfigProperty ein Provider injiziert werden. Mithilfe des Providers und dessen get()-Methode kann anschließend eine Just-in-Time-Konfiguration erfolgen.
// inject property provider
@Inject @ConfigProperty("SOME_KEY")
ProvidersomeValueProvider;
...
// get property value "just-in-time" via provider
String someValue = someValueProvider.get();
Der Begriff "Just-in-Time" ist in diesem Fall allerdings eher relativ zu sehen und bedeutet lediglich, dass der gerade in der Konfigurationsquelle hinterlegte Wert herangezogen wird. Wie die Quelle wiederum die Werte aktualisiert und wann auf ihr ein Refresh durchgeführt wird, ist nicht spezifiziert und somit dem Autor der ConfigSource-Klasse überlassen. Die Implementierung von OpenLiberty zum Beispiel erlaubt die Angabe einer Refresh-Rate via System-Property microprofile.config.refresh.rate für die Konfigurationsquellen. Der Standardwert liegt bei 500 (ms), sodass bei Bedarf alle halbe Sekunde ein Refresh erfolgt.
Die Config API unterstützt, wie im ersten Beispiel gezeigt, nicht nur Properties vom Typ String. Dank sogenannter Converter lassen sich die in den Konfigurationsquellen hinterlegten String-Werte in beliebige Java-Typen überführen.
Für eine Reihe von Java-Typen existieren bereits sogenannte Build-in Converter. Neben den bisher gezeigten Typen String und Boolean werden unter anderem auch Integer, Long, Double, Float sowie Duration, LocalTime, LocalDate, LocalDateTime, Instant und URL "out of the box" unterstützt. Und auch die Verwendung von Arrays ist seit Version 1.2 möglich:
// injection list property via array converter
@Inject @ConfigProperty("SOME_LIST_KEY")
private ListsomeListValues; ...
// get access to the Config instance via ConfigProvider
Config config = ConfigProvider.getConfig();
// access config properties via Config instance
private String[] someArrayValues = config.getValue("SOME_ARRAY_KEY", String[].class);
Was aber, wenn nicht unterstützte oder eigene Datentypen via Config API gesetzt werden sollen? In diesem Fall lässt sich ein spezifischer Custom-Converter, der das Converter
@Priority(200)
public class EmailConverter implements Converter{ @Override
public Email convert(String email) throws IllegalArgumentException {
return new Email(email);
}
}
Damit der Converter zur Laufzeit automatisch herangezogen werden kann, muss er zusätzlich registriert werden. Dies kann entweder via Java ServiceLocator – durch Angabe des voll qualifizierten Klassennamens des Converters in einer entsprechenden Datei META-INF/services/org.eclipse.microprofile.config.spi.Converter – geschehen oder alternativ programmatisch mithilfe des ConfigBuilder:
// get access to the Config instance via ConfigBuilder
ConfigBuilder builder = ConfigProviderResolver.getBuilder();
builder.addDefaultSources();// add custom converter for Email class
ConverteremailConverter = new EmailConverter();
builder.withConverters(emailConverter);
Config config = builder.build();// read email property into email object
OptionalemailOpt = config.getOptionalValue("ADMIN_EMAIL", Email.class);
...
Wie das Listing des EmailConverter zeigt, lassen sich auch Converter mit einer Priorität versehen. Sind also mehrere Converter für denselben Typ registriert, dann überschreibt der Converter mit der höheren Priorität diejenigen mit geringerer Priorität. Der Standardwert ist 100.
Alles in allem macht die Config API einen runden Eindruck, was aber auch nicht wirklich verwundert, wenn man einmal einen genaueren Blick auf die Ursprünge der API wirft:
Wer ein wenig Lust bekommen hat, die API einmal auszuprobieren, kann das mit folgenden Implementierungen tun:
Für die Zukunft sind bereits weitere Features geplant. Ein Hauptaugenmerk wird darauf liegen, dynamische Konfigurationsänderungen besser zu unterstützen. Man darf gespannt sein.
URL dieses Artikels:http://www.heise.de/-3928886
Links in diesem Artikel:[1] https://microprofile.io[2] https://deltaspike.apache.org/documentation/configuration.html[3] http://tamaya.incubator.apache.org/index.html[4] https://github.com/apache/geronimo-config[5] https://developer.ibm.com/wasdev/[6] https://docs.payara.fish/documentation/microprofile/config.html[7] https://github.com/wildfly-extras/wildfly-microprofile-config/
Copyright © 2017 Heise Medien
Das Implementieren von Bestell- beziehungsweise Bezahlprozessen innerhalb von Webanwendungen kann mitunter recht komplex sein. Die sogenannte Payment Request API [1], die momentan beim W3C ausgearbeitet wird und vor etwa einem Monat zusammen mit den Payment Method Identifiers [2] als "Candidate Recommendation" veröffentlicht wurde, soll hier Abhilfe schaffen.
Die API sieht vor, den Browser als Vermittler zwischen folgenden bei einem Bestellprozess involvierten Akteuren einzusetzen: dem Zahlungsempfänger (beispielsweise einem Online-Händler), dem Zahlungssender (also dem Käufer) und demjenigen, der die Hilfsmittel für eine Zahlung bereitstellt (Kreditkarte etc.).
Folgende Typen werden durch die API bereitgestellt:
Ob die API vom aktuellen Browser unterstützt wird, lässt sich innerhalb einer Website wie gewohnt über Feature Detection prüfen, beispielsweise durch Überprüfung auf das PaymentRequest-Objekt:
if (window.PaymentRequest) {
// Payment Request API wird unterstützt
} else {
// Payment Request API wird nicht unterstützt
}
Momentan unterstützen lediglich Chrome, Opera und Microsoft Edge die API [3], in Firefox kann die API als experimentelles Feature über das Flag "dom.payments.request.enabled" unter "about:config" aktiviert werden.
Um eine Bezahlanfrage zu formulieren, erstellt man eine Instanz von PaymentRequest, wobei dem Konstruktor drei Konfigurationsobjekte als Parameter übergeben werden können:
const methodData = { /* siehe Listings unten */ };
const details = { /* siehe Listings unten */ };
const options = { /* siehe Listings unten */ };
const paymentRequest = new PaymentRequest(
methodData,
details,
options
);
Über methodData lassen sich die zur Verfügung stehenden Bezahlmethoden angeben. Der Eigenschaft supportedMethods kann dabei ein Array von Kennzeichnern für unterstützte Bezahlmethoden hinterlegt werden:
// Konfiguration der Bezahlmethoden
const methodData = [
{
supportedMethods: ['basic-card'],
data: {
supportedNetworks: ['visa', 'mastercard'],
supportedTypes: ['debit', 'credit'],
}
}
];
Nähere Angaben zu der Bestellung wie etwa Identifikationsnummer einer Bestellung, die zu bestellenden Artikel, Versandkosten etc. lassen sich über das Konfigurationsobjekt details konfigurieren:
// Konfiguration der Bestelldetails
const details = {
id: 'order-123-12312',
displayItems: [
{
label: 'Summe',
amount: { currency: 'EUR', value: '25.00' },
},
{
label: 'Mehrwertsteuer',
amount: { currency: 'EUR', value: '4.75' },
},
],
shippingOptions: [
{
id: 'standard',
label: 'Standardversand',
amount: { currency: 'EUR', value: '5.00' },
selected: true,
},
{
id: 'express',
label: 'Expressversand',
amount: { currency: 'EUR', value: '11.00' },
},
],
total: {
label: 'Gesamtsumme',
amount: { currency: 'EUR', value: '34.75' },
},
};
Über das dritte Konfigurationsobjekt options lässt sich definieren, welche Informationen der Nutzer während des Bestellvorgangs eingeben muss, beispielsweise Name, E-Mail-Adresse oder Telefonnummer:
// Konfiguration der Pflichtangaben
const options = {
requestPayerEmail: true,
requestPayerName: true,
requestPayerPhone: true,
requestShipping: true,
};
Um eine Bezahlanfrage zu starten und damit den entsprechenden Dialog zu öffnen, verwendet man die Methode show() am PaymentRequest-Objekt. Zurück gibt die Methode ein Promise-Objekt, das erfüllt wird, wenn der Nutzer den Bezahlprozess über den Dialog abschließt. Innerhalb des darauf folgenden Callbacks lässt sich dann auf die vom Nutzer eingegebenen Daten zugreifen, üblicherweise um sie zur Überprüfung an den Server zu senden (im Folgenden durch den Aufruf von verify() symbolisiert).
// Hier normalerweise Überprüfung durch Server
const verify = (paymentResponse) => Promise.resolve(true);
Der Aufruf der Methode complete() teilt dem Browser anschließend mit, dass der Bezahlprozess abgeschlossen wurde. Als Parameter lassen sich hier die Werte "success" für eine erfolgreiche Bezahlung oder "failure" bei Auftreten eines Fehlers übergeben. Dem Browser steht es laut Spezifikation dann frei, ob er eine entsprechende Meldung anzeigt oder nicht.
paymentRequest.show()
.then((paymentResponse) => {
// Zugriff auf die vom Nutzer
// eingegebenen Daten.
const {
requestId,
methodName,
details,
shipping,
shippingOption,
payerName,
payerEmail,
payerPhone
} = paymentResponse;
// verify() als imaginäre Funktion, mit der
// die Bezahlanfrage mit der Serverseite überprüft wird
verify(paymentResponse).then((success) => {
if (success) {
console.log('Bezahlung erfolgreich durchgeführt');
return paymentResponse.complete('success');
} else {
console.error('Fehler bei Bezahlung');
return paymentResponse.complete('failure');
}
});
})
.catch((error) => {
console.error('Fehler:', error);
});
Die Payment Request API will Bestell- bzw. Bezahlprozesse innerhalb von Webanwendungen vereinfachen und vereinheitlichen. Wer die API heute schon testen möchte, kann den oben gezeigten Code in einem der zuvor genannten Browser ausführen. Anmerkungen und Verbesserungsvorschläge zur API kann man übrigens über die Issue-Seite [4] des entsprechenden GitHub-Projekts loswerden.
URL dieses Artikels:http://www.heise.de/-3694012
Links in diesem Artikel:[1] https://www.w3.org/TR/payment-request/[2] https://www.w3.org/TR/payment-method-id/[3] http://caniuse.com/#feat=payment-request[4] https://github.com/w3c/browser-payment-api/issues
Copyright © 2017 Heise Medien
Gemeinsame Verantwortung für Code hört sich nach einer gute Idee an. Aber sie ignoriert wichtige Konzepte der Softwareentwicklung.
Collective Code Ownership stammt aus dem Extreme Programming (XP), einer frühen agilen Methode. Es bedeutet, dass alle Entwickler jedes Problem beheben müssen, das sie im Code finden. Gemeinsam die Verantwortung für ein System zu übernehmen, sorgt dafür, das Probleme beseitigt werden, statt sie einfach hinzunehmen. Moderne Ansätze für Projektarbeit setzten auf eigenverantwortliche Teams. Dafür ist bei Softwareentwicklung die Verantwortung für den Code sicherlich zentral.
Woher wissen die Entwickler, was verbessert werden muss und wie das geschehen soll? Im Buch "Extreme Programming Explained" von Kent Beck steht, dass nicht alle Entwickler Experten für jeden Codeteil sein können, aber sie müssen zumindest ein grundlegendes Verständnis für den gesamten Code haben.
Wissen über den gesamten Code widerspricht dem Information Hiding, das schon in einem anderen Beitrag[1] eine Rolle gespielt hat. Information Hiding bedeutet, dass Nutzer eines Moduls nur die Schnittstelle kennen, aber nicht die Interna. Das erleichtert die Nutzung des Modul, weil Nutzer weniger über das Modul wissen muss. Das Modul ist auch einfacher änderbar. Änderungen sind ohne Beeinträchtigung der Nutzer des Moduls möglich, so lange die Schnittstelle unverändert bleibt.
Collective Code Ownership fordert aber mehr als nur Wissen über die Schnittstelle. Jeder muss die Interna aller Module zumindest oberflächlich verstehen. Welche Alternativen gibt es?
Für jedes Modul könnte ein Entwickler verantwortlich sein. Das hat entscheidende Nachteile. Wenn die zuständigen Entwickler Urlaub haben oder krank werden, wird es schwierig, das Modul zu ändern, weil nur sie das Modul verstehen.
Eine Lösung ist, dass mehrere Entwickler jedes Modul kennen, aber nicht alle Entwickler jedes Modul kennen. Die Organisation spielt dabei eine wichtige Rolle: Das Gesetz von Conway[2] besagt, dass die Softwarearchitektur den Kommunikationsbeziehungen unter den Entwicklern entspricht. Die These: Entwickler sind jeweils für ein oder mehrere Module zuständig und müssen miteinander reden, wenn sie Module anderer Entwickler nutzen wollen. Auch das widerspricht dem Collective Code Ownership, weil nicht jeder Entwickler jeden Code versteht oder gar ändern kann
Kommunikation innerhalb eines Teams ist einfacher. Sie arbeiten oft in denselben Räumlichkeiten und haben gemeinsame Meetings. Das erleichtert die Kommunikation. Bessere Kommunikation kann nach dem Gesetz von Conway Auswirkungen auf die Architektur haben. Wenn Entwickler aus einem Team den Code anderer Teammitglieder kennen, kann das ein Zeichen guter Zusammenarbeit im Team sein. Wenn die Entwickler die Module anderer Teams kennen müssen, dann ist dazu aufwendige Kommunikation wie während extra organisierter Meetings notwendig. Also sollte Collective Code Ownership auf Teams beschränkt sein und nicht die gesamte Organisation umfassen.
Collective Code Ownership bedeutet, Verantwortung für Code zu übernehmen und Code zu verbessern. Das ist ein gute Sache. Den gesamten Code zu verstehen, ist dank Modularisierung zum Glück nicht notwendig.
URL dieses Artikels:http://www.heise.de/-3909449
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Meine-Datenbank-gehoert-mir-3608372.html[2] http://www.melconway.com/Home/Conways_Law.html
Copyright © 2017 Heise Medien
Die Independent System Architecture (ISA) stellt Prinzipien für Microservices auf. ISA definiert grundlegende Eigenschaften von Microservices, die erhebliche Probleme aufwerfen, wenn sie nicht eingehalten werden.
Das Ziel ist, die fundamentalen Konzepte von Microservices darzustellen und nicht nur einen bestimmten Ansatz, Microservices umzusetzen, wie dies Self-contained Systems[1] (SCS) tun. SCS waren schon Thema eines anderen Blog-Beitrags[2].
Es gibt neun Prinzipien:
1. Das System ist in Module aufgeteilt. Module sind eine alte Idee. Das erste Prinzip stellt Microservices in diese Tradition. So wird deutlich, dass andere Modularisierungsansätze Alternativen zu Microservices sein können. Wegen des Modulbegriff treffen auch Konzepte wie Information Hiding auf Microservices zu. Microservices dürfen daher nicht von den Interna anderer Microservices abhängen. Beispiel: Wie Klassen in einem OO-System keine internen Daten anderer Klassen (Instanzvariablen) nutzen dürfen, so dürfen Microservices nicht Daten anderer Microservices direkt auslesen, indem sie beispielsweise auf die Datenbank-Schemata des Microservice zugreifen.
2. Die Module laufen als Docker-Container, Prozesse oder virtuelle Maschinen. Also würde ein Bestellprozess-Modul beispielsweise in einem eigenen Docker-Container laufen. Diese Implementierung unterscheidet ISA fundamental von anderen Modularisierungen und hat einige Vorteile. Beispielsweise können Module in unterschiedlichen Programmiersprachen geschrieben sein oder unabhängig voneinander deployt werden.
3. Die Architektur wird in die Mikro-Architektur, die nur einzelne Module betrifft, und die Makro-Architektur unterteilt, die das gesamte System umfasst. Die Makro-Architektur gibt die minimalen Regeln vor, um die langfristige Evolution sicherzustellen und zu garantieren, dass das System nach außen wie ein System erscheint. Die weiteren Prinzipien sind Teile der Makro-Architektur.
4. Die Integration der Module muss definiert sein. Die Module können synchron, asynchron oder auf der UI-Ebene integriert werden. Das ist notwendig, damit das System am Ende tatsächlich ein System ist und nicht etwa nur Module ohne Zusammenhalt.
5. Kommunikation beispielsweise per RESTful HTTP oder Messaging muss ebenfalls standardisiert sein, damit die Module miteinander kommunizieren können.
6. Jedes Modul hat eine eigene Continuous Delivery Pipeline. Die Module können prinzipiell unabhängig voneinander deployt werden, weil sie als Container umgesetzt sind. Mit einer getrennten Continuous Delivery Pipeline ist ein getrenntes Deployment auch tatsächlich möglich. Da die Pipeline vor allem Tests umfasst, müssen also insbesondere die Test der Module unabhängig voneinander sein.
7. Der Betrieb sollte standardisiert sein. Das betrifft zum Beispiel Logs, Monitoring, Konfiguration und Deployment. Die Standardisierung reduziert den Aufwand, weil so zwar die Anzahl der Containern steigt, aber sie zumindest einheitlich behandelt werden können.
8. Alle Standards sollen auf Ebene der Schnittstelle definiert sein. Eine Kommunikation per RESTful HTTP mit einem festen Datenschema oder ein bestimmtes Monitoring-System auf einem bestimmten Server sind Standardisierungen auf Ebene der Schnittstelle. Wenn die konkrete REST-Bibliothek oder eine Bibliothek für Monitoring vorgegeben wird, wird die Technologie standardisiert. Das schränkt die mit ISA gewonnenen Freiheiten ein. In einem Projekt kann sich natürlich dennoch ein einheitlicher Technologie-Stack durchsetzen und so Aufwände einsparen. Langfristig kann der Stack bei der Evolution des Systems durch einen anderen Stack abgelöst oder ergänzt werden, ohne die Standards zu verletzen. So kann der Technologie-Stack aktualisiert werden, und das System bleibt zukunftssicher.
9. Resilience ist die Fähigkeit eines Moduls, bei einem Ausfall eines anderen Moduls weiter zu funktionieren - gegebenenfalls mit schlechteren Ergebnissen. Das unterbindet Fehlerkaskaden, bei denen der Ausfall eines Moduls andere Module ebenfalls zum Ausfall bringt und so das gesamte System letztendlich ausfällt. Ebenso müssen Module damit umgehen können, dass sie auf einen anderen Server neu gestartet werden. Das erleichtert den Betrieb im Cluster, bei dem Module auf unterschiedlichen Servern laufen müssen und gegebenenfalls Server ausfallen oder gewartet werden müssen.
Dieser Blog-Beitrag bietet nur eine Einführung in die ISA-Prinzipien. Weitere Informationen finden sich unter isa-principles.org[3]. Insbesondere die Begründungen sind für ein besseres Verständnis interessant.
Die gesamte Website steht unter Creative Commons Attribution Share Alike. Der Quellcode der Website findet sich auf GitHub[4] wieder. Wer Verbesserungsvorschläge oder Kritik hat, kann einen Issue einstellen, einen Pull Request erstellen oder an der Diskussion[5] teilnehmen. Ebenso gibt es eine Präsentation[6], die man auch als PowerPoint[7] herunterladen kann und die ebenfalls unter Creative Commons Attribution Share Alike steht.
URL dieses Artikels:http://www.heise.de/-3889160
Links in diesem Artikel:[1] http://scs-architecture.org[2] https://www.heise.de/developer/artikel/Self-contained-Systems-ein-Architekturstil-stellt-sich-vor-3038718.html[3] http://isa-principles.org[4] https://github.com/ISA-Principles/isa-principles.org/[5] http://isa-principles.org/discussion.html[6] http://isa-principles.org/slidedeck/ISA.pptx[7] https://speakerdeck.com/isaprinciples/isa-principles
Copyright © 2017 Heise Medien
iX richtet sich an IT-Profis, gibt tiefe Einblicke und Orientierung in aktuelle IT-Entwicklungen. iX-Nutzer schätzen insbesondere den starken Praxisbezug und den unabhängigen Journalismus. Zu den treuen Lesern zählen IT-Leiter, Softwareentwickler, Systemadmins sowie Security-Spezialisten. Es erscheint monatlich - gedruckt und digital.
Jetzt sichern!
Die zweite Developer Preview von ARCore bringt neben erweiterten Funktionen eine C-API für Android. Das Projekt Tango ist nun endgültig Geschichte: Der Internetriese stellt den Support für das ambitionierte, frühe AR-Projekt ein.
Nachdem Google bereits im Sommer beschlossen hatte[1], die AR-Plattform (Augmented Reality) Tango durch das deutlich einfachere ARCore zu ersetzen, verkündet ein Blogbeitrag[2] nun das endgültige Aus für Tango mit dem Einstellen des Supports für das bereits 2014 offiziell gestartete AR-System. Die Erfahrungen aus dem Projekt, das mit Johnny Chung Lee einen ausgewiesenen Experten für Mensch-Computer-Interaktion als Leiter hatte, sind in ARCore eingeflossen. Lee war zuvor maßgeblich in Microsofts Kinect-Entwicklung eingebunden, ist aber wohl nicht in Googles aktuelle AR-Plattform involviert.
Mit dem Plattformwechsel verspiele der Internetriese auch den Vorsprung gegenüber Apple: ARKit ist zwar erst seit iOS 11 verfügbar, dafür läuft es inzwischen funktionsfähig auf mehreren Millionen Geräten. Google hat von ARCore dagegen noch keine Variante für Android-Endanwender, sondern veröffentlicht nun die zweite Developer Preview der Plattform. Allerdings wird der Internetriese wohl das Tempo noch weiter anziehen, um ebenfalls eine breite Palette an Endgeräten zu bedienen. Der Vorteil von ARCore gegenüber Tango ist, dass die Plattform keine spezielle Hardware benötigt, sondern lediglich die standardmäßig verfügbaren Sensoren und die Kamera nutzt.
Die zweite Developer Preview von ARCore bringt zudem erstmals eine Anbindung an die C-API für Android, sodass Entwickler AR-Anwendungen künftig mit dem Android NDK (Native Development Kit) schreiben können. ARCore lässt sich bereits mit Java sowie den Game-Engines Unity[3] und Unreal[4] verwenden. Auch Telerik entwickelt ein AR-Plug-in für NativeScript [5], das sowohl mit ARKit als auch mit ARCore zusammenarbeitet. Ebenfalls neu in der zweiten Developer Preview ist die Möglichkeit, AR-Sessions zu pausieren, um beispielsweise Anrufe anzunehmen. Außerdem vermeldet der Blogbeitrag eine erhöhte Genauigkeit und eine bessere Effizienz.
Ein genaues Datum für die Veröffentlichung von ARCore v1.0 bleibt der Blogbeitrag schuldig, stattdessen heißt es vage "innerhalb der nächsten Monate". Die ARCore-Projektseite[6] zeigt einige erste Anwendungen, und Google AR-Entwickler-Site[7] bietet Einstiegshilfen für Programmierer. Gerade die Anbindung an Unity und Unreal dürfte für Entwickler spannend sein, da sie damit ihre Mixed-Reality-Spiele plattformübergreifend für Apples und Googles Mobilsystem sowie möglicherweise zusätzlich für Windows Mixed Reality schreiben können.
URL dieses Artikels:http://www.heise.de/-3920207
Links in diesem Artikel:[1] https://www.heise.de/meldung/Googles-Augmented-Reality-Tango-ist-tot-es-lebe-ARCore-3817226.html[2] https://www.blog.google/products/google-vr/arcore-developer-preview-2/[3] https://www.heise.de/meldung/Spiele-Engine-Unity-2017-2-zielt-vor-allem-auf-2D-Entwicklung-und-Extended-Reality-3860769.html[4] https://www.heise.de/meldung/Unreal-Engine-4-18-bringt-verbesserte-Lichteffekte-3871165.html[5] https://www.heise.de/meldung/Cross-Platform-Entwicklung-NativeScript-bekommt-ein-AR-Plug-in-3829393.html[6] https://thisisarcore.com/[7] https://developers.google.com/ar/[8] mailto:rme@ct.de
Copyright © 2017 Heise Medien
(Bild: Google)
Google stellt die Entwicklung seiner Augmented-Reality-Umgebung "Tango" für Smartphones wie erwartet ein. Der Support endet am 1. März 2018. Das Nachfolgeprojekt "ARCore" stand bereits fest.
Das Augmented-Reality-Projekt "Tango" ist bald Geschichte: Google hat die Weiterentwicklung eingestellt und wird den Support am 1. März 2018 beenden [1], wie es im Entwicklerblog heißt. Dass Google seine ambitionierte AR-Plattform aufgeben wird [2], hatte sich bereits seit Längerem abgezeichnet. In Gestalt von ARCore [3] steht auch schon ein Nachfolger fest – ein technisch einfacheres System, das offensichtlich besser für den Massenmarkt taugt, da es auf zahlreichen Android-Geräten funktioniert.
Mit ARCore versucht Google, mit Apples ARKit [4] Schritt zu halten, das auf allen aktuellen iPhones funktioniert. Für Tango hingegen sind spezielle Smartphones notwendig. Doch es mangelte offenbar an Hardware-Herstellern, die sich von den Vorzügen dieser speziellen Plattform zum Einblenden virtueller Objekte in die Darstellung der realen Umgebung auf dem Mobilgerät überzeugen ließen.
URL dieses Artikels:
https://www.heise.de/ix/meldung/Google-gibt-AR-Plattform-Tango-auf-3919801.html
Links in diesem Artikel:
[1] https://plus.google.com/+ProjectTango/posts/SE8SHaDKLmu
[2] https://www.heise.de/ix/meldung/Googles-Augmented-Reality-Tango-ist-tot-es-lebe-ARCore-3817226.html
[3] https://developers.google.com/ar/
[4] https://www.heise.de/ix/meldung/ARKit-Schlaegt-Apple-Google-3771409.html
[5] mailto:un@ix.de
(Bild: Volker Weber )
Die größte Befürchtung der BlackBerry-Kritiker trifft ein. Genau zwei Jahre nach Vorstellung des PRIV beendet BlackBerry die Versorgung mit monatlichen Updates. Alternativen gibt es nicht.
BlackBerry stellt keine Smartphones mehr her. Von den BlackBerry-10-Geräten gibt es noch Restbestände, die ersten drei Android-Geräte PRIV[1], DTEK50[2] und DTEK60[3] sind im Abverkauf. Und nun lässt Alex Thurber die Bombe platzen. Er ist als Senior Vice-President and General Manager für die Mobility Solutions Division bei BlackBerry verantwortlich. Für den PRIV enden die monatlichen Updates[4]. Man kann sich ausrechnen, dass es den beiden anderen Geräten DTEK50 und DTEK60 genauso gehen wird, wenn die 24 Monate erreicht sind.
Als uns Thurber vor 14 Monaten ein Interview[5] gab, klang das alles noch ganz anders: "Wir unterstützen alle Produkte mindestens zwei Jahre über EOL (End of life) hinaus. Und dieser EOL liegt irgendwann in der Zukunft, er ist gar nicht abzusehen." Updates auf Nougat stellte Thurber ebenfalls in Aussicht. "Es läuft bereits in unserem Labor und wir arbeiten eng mit Google an unserer Weiterentwicklung." Auch das ist nicht passiert[6].
Mit dem Auslaufen der Sicherheits-Updates sind die Geräte keineswegs mehr so sicher, wie BlackBerry gerne in Anspruch nimmt. Und Alternativen gibt es nicht, da sich keine andere Firmware auf die Geräte spielen lässt. Das einzige Angebot, dass Thurber in Aussicht stellt, ist ein Upgrade-Programm auf KEYone[7] und Motion[8], die Geräte von TCL-Partner BlackBerry Mobile. Aber auch die haben nichts anderes versprochen als 24 Monate ab Vorstellung und ein Oreo Update nächstes Jahr.
(Volker Weber) /
URL dieses Artikels:http://www.heise.de/-3919087
Links in diesem Artikel:[1] https://www.heise.de/preisvergleich/blackberry-priv-schwarz-a1341632.html?hocid=newsticker&wt_mc=intern.newsticker.textlink-pvg.pvg_a1341632[2] https://www.heise.de/preisvergleich/blackberry-dtek50-schwarz-a1482972.html?hocid=newsticker&wt_mc=intern.newsticker.textlink-pvg.pvg_a1482972[3] https://www.heise.de/preisvergleich/blackberry-dtek60-schwarz-a1517352.html?hocid=newsticker&wt_mc=intern.newsticker.textlink-pvg.pvg_a1517352[4] http://blogs.blackberry.com/2017/12/status-of-priv-monthly-updates/[5] https://www.heise.de/meldung/BlackBerry-verspricht-Android-weitere-Updates-3341461.html[6] https://www.heise.de/meldung/Keine-Upgrades-mehr-fuer-BlackBerry-PRIV-3827231.html[7] https://www.heise.de/preisvergleich/blackberry-keyone-silber-a1584430.html?hocid=newsticker&wt_mc=intern.newsticker.textlink-pvg.pvg_a1584430[8] https://www.heise.de/preisvergleich/blackberry-motion-schwarz-a1706993.html?hocid=newsticker&wt_mc=intern.newsticker.textlink-pvg.pvg_a1706993[9] mailto:vowe@vowe.net
Copyright © 2017 Heise Medien
Mit der Freigabe des Programms der Konferenz zur Parallelprogrammierung wurde auch die Registrierung eröffnet. Mehr als ein Monat besteht nun Zeit, sich inklusive Frühbucherrabatt zu registrieren.
Das Programm der parallel 2018[1] steht nun online. Damit verbunden können sich interessierte Entwickler ab sofort für die Konferenz zur Parallelprogrammierung zum Frühbucherrabattpreis registrieren[2]. Die von heise Developer, iX und dem dpunkt.verlag von 6. bis 8. März 2018 organisierte Veranstaltung findet bereits zum siebten Mal statt – erneut in der Heidelberger Print Media Academy.
In ihrer siebten Auflage knüpft die parallel 2018 programmatisch am Charakter der bisherigen Ausgaben der Konferenz an. Im Programm finden sich verteilt auf zwei Tage über 30 Lang- und Kurzvorträge[3] zu Best Practises bei paralleler Programmierung, dem High-Performance Computing sowie aus dem spannenden Bereich des Deep beziehungsweise Machine Learning, wo sich einige der interessantesten Anwendungsszenarien im Bereich des parallelen Rechnens auftun. Einen Schwerpunkt bilden Vorträge zur Performance paralleler Anwendungen. Abgerundet wird das Programm durch zwei Keynotes.
Bis 20. Januar gilt für den Kauf des Konferenztickets noch ein Frühbucherpreis von 790 Euro: Statt des regulären Preises von 930 Euro lassen sich also für die zwei Konferenztage ganze 140 Euro sparen. Weiteren Rabatt gibt es bei der zusätzlichen Buchung eines von fünf Workshops am Vortag der Hauptkonferenz. Bei ihnen geht es um Themen wie die Programmiersprachen C++ und Java, die Wahl der richtigen Technik und Architektur für Projekte zur parallelen Programmierung sowie eine Schulung zur Entwicklung von robusten, nebenläufigen Systemen hoher Parallelität mit Erlang/OTP.
Wer über den weiteren Fortgang der Konferenz auf dem Laufenden gehalten werden möchte, kann sich über einen Newsletter[4] vormerken lassen oder den Veranstaltern auf Twitter[5] folgen.
Die Veranstalter der parallel sind heise Developer, iX und der dpunkt.verlag, die Teil der Heise Gruppe sind.
URL dieses Artikels:http://www.heise.de/-3918227
Links in diesem Artikel:[1] https://www.parallelcon.de/index.php[2] https://www.parallelcon.de/anmeldung.php[3] https://www.parallelcon.de/programm.php[4] https://www.parallelcon.de/benachrichtigen.php[5] https://twitter.com/parallelConf[6] mailto:map@heise.de
Copyright © 2017 Heise Medien
(Bild: Palo Alto Networks)
Kombinieren Angreifer drei Sicherheitslücken, könnten sie Firewalls von Palo Alto Networks kompromittieren, warnt ein Sicherheitsforscher.
Verschiedene Firewalls mit PAN-OS von Palto Alto Networks sind unter gewissen Umständen angreifbar. Das ist der Fall, wenn Admins das Management Interface so eingestellt haben, dass es aus dem Internet erreichbar ist. Das kommt häufig vor, warnt[1] ein Sicherheitsforscher. Derzeit sind fast 7000 Firewalls öffentlich erreichbar[2].
Angreifer könnten drei Sicherheitslücken zu einem gefährlichen Cocktail kombinieren. So sollen Attacken aus der Ferne ohne Authentifizierung möglich sein, die damit enden, dass Angreifer Code mit Root-Rechten auf betroffenen Firewalls ausführen können.
Die auf den Firewalls laufenden Betriebssystemversionen PAN-OS 6.1.19, 7.0.19, 7.1.14 und 8.0.6-h3 sind abgesichert. Alle vorigen Ausgaben sind bedroht, warnt[3] Palo Alto Networks.
[UPDATE, 15.12.2017 12:00 Uhr]
Weitere PAN-OS-Versionen hinzugefügt.
URL dieses Artikels:http://www.heise.de/-3918909
Links in diesem Artikel:[1] http://seclists.org/fulldisclosure/2017/Dec/38[2] https://www.shodan.io/report/mPWsUHOS[3] https://securityadvisories.paloaltonetworks.com/Home/Detail/102?AspxAutoDetectCookieSupport=1[4] mailto:des@heise.de
Copyright © 2017 Heise Medien
Bei der Weiterentwicklung des Java-Applikationsservers hat Red Hat den Fokus vor allem auf Performance und Sicherheit gelegt. Das aktuelle Enterprise Java spielt offenbar keine Rolle, aber HTTP/2 gehört nun zum Lieferumfang.
Red Hat hat Version 7.1 der JBoss Enterprise Application Platform (EAP) veröffentlicht. Trotz des vermeintlich kleinen Release-Schritts sind seit Version 7 inzwischen eineinhalb Jahre vergangen. Die im Bezug auf Java-Applikationsserver augenscheinlichste Neuerung seitdem ist die Veröffentlichung von Java EE 8 im September[1]. JBoss 7.1 setzt jedoch weiterhin auf Java EE 7. In den Release Notes[2] findet sich nicht einmal ein Verweis auf das aktuelle Enterprise Java.
Denkbar ist, dass Red Hat gleich den Nachfolger EE4J berücksichtigt, der als Open-Source-Projekt unter dem Dach der Eclipse Foundation entsteht[3]. So verweist der Red-Hat-Blog[4] auf den Übergang von Java EE zu EE4J. Oracles offizielle Liste[5] mit Java-EE-Servern und deren Kompatibilität zu den unterschiedlichen Versionen der Plattform ließ beim Schreiben dieses Beitrags einen Hinweis auf Java-EE-8-Server gänzlich vermissen.
Bei der Weiterentwicklung von JBoss standen wohl vor allem die Performance, Verfügbarkeit und Security im Fokus. So haben die Macher die Domain-Fehlertoleranz verbessert, indem der Applikationsserver automatisch die Host-Controller mit den Domain-Controllern über eine gecachete Konfiguration verbindet. Um den Status von Anwendungen besser zu überwachen, können Administratoren nun Listener-Module, darunter JMX-Listener (Java Management Extensions) registrieren.
Red Hat hat JBoss EAP um ein zusätzliches Subsystem für Security erweitert, das auf dem Community-Projekt WildFly Elytron[6] aufsetzt. Es enthält APIs und SPIs, über die Entwickler individuelle Funktionen integrieren können. Außerdem ermöglicht Elytron ein Container-verwaltetes Single-Sign-on-System und kann automatisch Zertifikate für Anwendungen ausstellen.
Eine der prominenten Neuerungen von Java EE 8 hat zumindest unabhängig von der offiziellen Plattform ihren Weg in JBoss EAP 7.1 gefunden: HTTP/2 ist eigentlich Bestandteil von Servlet 4.0, aber JBoss implementiert den Nachfolger des achtzehn Jahre alten HTTP/1.1 über die interne ALPN-Anbindung (Application Layer Protocol Negotiation), damit jedoch nur für OpenJDK und Oracle JDK, oder über JBoss Core Services OpenSSL, das allerdings nicht mit HP-UX zusammenarbeitet.
Siehe dazu auf heise Developer:
URL dieses Artikels:http://www.heise.de/-3918769
Links in diesem Artikel:[1] https://www.heise.de/meldung/Java-EE-8-ist-offiziell-erschienen-3838062.html[2] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html-single/7.1.0_release_notes/[3] https://www.heise.de/meldung/Java-Enterprise-Edition-Java-EE-Nachfolger-EE4J-nimmt-Gestalt-an-3897130.html[4] https://www.redhat.com/en/blog/red-hat-releases-jboss-eap-71[5] http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html[6] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security[7] https://www.heise.de/meldung/Java-EE-8-ist-offiziell-erschienen-3838062.html[8] https://www.heise.de/meldung/Oracle-will-Java-EE-an-die-Open-Source-Community-uebertragen-3806673.html[9] https://www.heise.de/meldung/Java-Enterprise-Edition-Java-EE-Nachfolger-EE4J-nimmt-Gestalt-an-3897130.html[10] https://www.heise.de/developer/artikel/Mit-Java-auf-dem-HTTP-2-Zug-3918097.html[11] mailto:rme@ct.de
Copyright © 2017 Heise Medien
Das Cloud-Geschäft bei Oracle wächst zwar, entwickelt sich aber schwächer als erwartet - die Anleger sind nicht sehr begeistert und strafen Oracle an der Börse ab.
Der SAP-Rivale Oracle hat Gewinn und Umsatz im vergangenen Geschäftsquartal deutlich gesteigert – bei Anlegern kamen die Zahlen dennoch schlecht an. In den drei Monaten bis Ende November kletterte der Überschuss[1] verglichen mit dem Vorjahreswert um zehn Prozent auf 2,2 Milliarden Dollar. Der Umsatz wuchs um sechs Prozent auf 9,6 Milliarden Dollar.
Obwohl die Prognosen der Analysten damit übertroffen wurden, sank die Aktie nachbörslich um über vier Prozent. Trotz eines starken Umsatzwachstums um 44 Prozent auf 1,5 Milliarden Dollar entwickelte sich das Cloud-Geschäft mit IT-Diensten im Internet schwächer als erwartet.
(dpa) /
URL dieses Artikels:http://www.heise.de/-3918778
Links in diesem Artikel:[1] https://www.oracle.com/corporate/pressrelease/earnings-q2fy18-121417.html[2] mailto:jk@ct.de
Copyright © 2017 Heise Medien
Stubby in Action: Ist die Software installiert und aktiviert, ändert sie die DNS-Konfiguration so, dass sie die DNS-Anfragen des Betriebssystems selbst erhält (sie gehen an die lokale IP-Adressen 127.0.0.1 oder, bei IPv6 an ::1). Diese gibt sie dann selbst TLS-verschlüsselt weiter.
Die Entwicklung steckt zwar noch in den Kinderschuhen, aber inzwischen gibt es immerhin zwei Tools für macOS und Android, mit denen man ein Datenschutz-freundlicheres DNS einfach per Mausklick nutzen kann.
Der quelloffene DNS-Privacy-Daemon namens Stubby ist erstmals mit einer graphischen Oberfläche für macOS erschienen[1]. Stubby wird parallel auch für andere Betriebssysteme entwickelt und verschickt TLS-verschlüsselte DNS-Anfragen an geeignete Resolver. So trägt die Software zu mehr Privatheit bei der Internet-Kommunikation bei. Denn übliche, im Betriebssystem eingebaute Stub-Resolver verschicken DNS-Anfragen unverschlüsselt, sodass man leicht auslesen kann, welche Web-Seiten der Absender der DNS-Anfrage besucht.
Stubby verwendet die Spezifikation "DNS over TLS" der Internet Engineering Task Force (RFC 7858[2]). Die Technik setzt Resolver voraus, die TLS-verschlüsselte Anfragen annehmen. Und natürlich sind solche Resolver nur dann hilfreich, wenn die Betreiber die DNS-Anfragen der Nutzer nicht protokollieren. Eine Liste haben die Betreiber des Projekts "DNS-Privacy" auf ihrer Web-Seite[3] veröffentlicht.
Am sicheren Stub-Resolver für PCs arbeiteten bislang vor allem Sara Dickinson und die Partner des DNS-Privacy-Projekts. Es handele sich um eine Vorschauversion, ein "Alpha-Release der Version 0.1.0", unterstrich Dickinson in einer Mail an heise online. Bislang wurde die Software auf macOS Sierra und High Sierra getestet.
An mehreren Punkten gilt es noch zu feilen, sodass sich die Software keinesfalls für den Produktivbetrieb eignet: Der Sleep-Modus kann Stubby aus der Bahn werfen und manchmal ist er ohne Einfluss von Außen verwirrt. Was man dann tun kann, beschreibt die Entwicklerin im Bereich Known Issues[4] auf der Download-Seite der Software. Weitere wichtige Schritte bei der Entwicklung sind die klare Unterscheidung des strikten Datenschutzmodus (nur verschlüsselt) vom opportunistischen (wenn vorhanden). Auch soll die Transparenz bei Veränderungen der Netzwerkkonfiguration verbessert werden. Später soll es für Stubby auch auf Windows und Linux ein GUI geben.
Auch Android-Nutzer können seit ein paar Wochen DNS über TLS testen. Die Software entstammt den Tastaturen von Erik Kline und Ben Schwarz (beide sind Google-Mitarbeiter) und ist auf der zugehörigen Website erhältlich[5]. Nach dem Herunterladen können Nutzer zwischen drei Optionen wählen: privacy mode, opportunistic mode oder privacy-off mode – also durchgängiger Standardbetrieb ohne Verschlüsselung.
Beim jüngsten Treffen der Internet Engineering Task Force konnten die Autoren für eine Demonstration auf den TLS-fähigen Server ihres Kollegen Warren Kumari zugreifen. Wer die Software in freier Wildbahn testen will, kann einen der Resolver von der Liste des DNS-Privacy-Projekts im Android-Gerät einstellen.
Die DNS-Resolver Unbound, Knot und BIND setzen das RFC 7858 schon länger um und laufen stabil. Alle drei sind aber nur für die Steuerung per Kommandozeile ausgelegt. Wie man Unbound mit DNS-Privacy zum Beispiel auf einem Raspi für ein ganzes Netz einrichtet, erklärt der c't-Artikel "Privatsphäre per Tunnel[6]" Schritt für Schritt.
(Monika Ermert) /
URL dieses Artikels:http://www.heise.de/-3918634
Links in diesem Artikel:[1] https://dnsprivacy.org/wiki/display/DP/Stubby+GUI+for+macOS[2] https://www.heise.de/netze/rfc/rfcs/rfc7858.shtml[3] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers[4] https://dnsprivacy.org/wiki/display/DP/Stubby+GUI+for+macOS[5] https://android-review.googlesource.com/q/topic:dns-dev-opt+(status:open+OR+status:merged[6] https://www.heise.de/ct/ausgabe/2017-20-Domain-Name-Service-Datenschutz-selbstgebaut-3825108.html[7] mailto:dz@ct.de
Copyright © 2017 Heise Medien
(Bild: dpa, Bernd Thissen/Symbolbild)
Eine Übernahme durch den französischen Konzern sei nicht im Interesse des Unternehmens und seiner Angleger, teilte der niederländische Chipkarten-Hersteller mit. Der Aufsichtsrat habe einstimmig abgewunken.
Chipkarten-Hersteller Gemalto hat das Übernahmeangebot des französischen Atos-Konzerns zurückgewiesen. Als Weltmarktführer für digitale Sicherheitsanwendungen sei Gemalto hervorragend aufgestellt, um eigenständig und langfristig zu wachsen, teilte das Unternehmen am Mittwoch in Amsterdam mit[1]. Gemalto werde seinen Anteilseignern nun einen Entwicklungsplan für die nächste Zukunft vorlegen, erklärte der Vorstandsvorsitzende Philippe Vallée.
Der französische IT-Dienstleister Atos hatte am Montag sein Übernahmeangebot für Gemalto veröffentlicht[2] und will insgesamt rund 4,3 Milliarden Euro auf den Tisch legen. Durch den Zusammenschluss solle ein führendes Unternehmen bei Cyber-Sicherheit und digitalen Dienstleistungen entstehen. Die Franzosen hatten bereits vor Jahren die IT-Tochter SIS von Siemens übernommen.
Der Aufsichtsrat habe das Angebot zusammen mit Finanzberatern eingehend geprüft, heißt es von Gemalto nun. Das Gremium sei dabei einmütig zu dem Schluss gelangt, dass eine Übernahme nicht die beste Lösung für das Unternehmen und seine Anteilseigner wäre. Atos hatte betont, das Angebot sei freundlich gesinnt. Nach der Zurückweisung durch Gemalto bleibt nun abzuwarten, ob die Franzosen eine feindliche Übernahme versuchen.
URL dieses Artikels:http://www.heise.de/-3918684
Links in diesem Artikel:[1] https://www.gemalto.com/press-site/Documents/2017/2017-13-13_Gemalto_Reponse_Atos_PR_EN.pdf[2] https://www.heise.de/meldung/IT-Spezialist-Atos-will-Chipkarten-Hersteller-Gemalto-schlucken-3915775.html[3] mailto:vbr@ct.de
Copyright © 2017 Heise Medien
(Bild: Dusan Zivadinovic )
TLS-Zertifikate lassen sich mittels DANE weit zuverlässiger gegen Missbrauch absichern als herkömmlich über Zertifizierungsstellen. Ein Tages-Workshop für Administratoren und Sicherheitsbeauftragte führt in die Technik ein.
Verschlüsselte Kommunikation verhindert unerwünschtes Mitlesen durch Dritte und schützt die Privatsphäre zwischen zwei Kommunikationspartnern. Dafür setzt man häufig kryptografische Schlüssel ein. Einem Schlüssel sieht man aber nicht an, wem er gehört. Beim verbreiteten Verschlüsselungsstandard TLS (Transport Layer Security) sollen daher x509-Zertifikate die Authentizität der Schlüssel und Schlüsseleigner beglaubigen.
Genau da steckt eine konzeptbedingte Schwäche: Denn jede Zertifizierungsstelle der Welt darf Zertifikate für jede beliebige Domain ausstellen – auch wenn das der Eigner der Domain gar nicht abgenickt hat. Außerdem sind die Herausgeber der Zertifikate wegen Sicherheitslücken in deren IT-Systemen und auch wegen Misswirtschaft in Verruf geraten.
Die DANE-Technik räumt mit alten Konzeptfehlern auf und bringt mehrere Vorteile: Die dafür ausgelegten Tools und Clients beziehen einen Schlüssel automatisch nur aus der angefragten Domain – es gibt also nur noch eine Quelle für den Schlüssel einer Domain. Und weil bei DANE der digitale Fingerabdruck eines TLS-Zertifikats im Domain Name System hinterlegt wird, weiß die Seite, die eine Verbindung aufbauen will, vorher schon, woran sie das richtige Zertifikat erkennt. So werden Man-in-the-Middle-Attacken vereitelt.
Zudem wird der Fingerabdruck mittels den DNS Security Extensions auf dem Übertragungsweg zum Empfänger gegen Manipulation abgesichert (DNSSEC). Last but not least, behalten die Eigner die Kontrolle darüber, können Schlüssel also ersetzen oder entfernen. Denn, um bei DANE einen Schlüssel zu manipulieren, müsste gleich das gesamte DNSSEC manipuliert werden.
Der Workhop zu DANE (DNS-Based Authentication of Named Entities) führt schnell in die Technik ein und zeigt, wie man sie auf dem DNS-Server BIND 9 einrichtet und mit dem freien Mailserver Postfix verwendet. Sie lernen, wie Sie einen SMTP-Server so einrichten, dass er E-Mails verschlüsselt weiterreicht und wie Sie Ihren Nutzern mittels DANE einen Mehrwert bei der PGP- oder S/MIME-verschüsselten Kommunikation bieten.
Der Workshop richtet sich an DNS- und Mail-Administratoren, Sicherheitsbeauftragte in Unternehmen sowie Auditoren für Netzwerksicherheit. Der Workshop findet in Hannover am 27.02.2018 statt. Themenschwerpunkte sind:
• Grundlagen DNSSEC
• Grundlagen TLS/SSL-Transportverschlüsselung
• DANE-Techiken, TLSA/OPENPGPKEY/SMIMEA-Records
• BSI Technische Richtlinie TR3108 "Sicherer E-Mail-Transport"
• Beispiel-Implementierung DNSSEC und DANE mit BIND 9 und Postfix
Vorausgesetzt werden grundlegende Linux- und Unix-Kommandozeilen-Kenntnisse sowie Grundkenntnisse des Domain-Name-System. Weitere Informationen sowie die Möglichkeit zur Anmeldung finden Sie auf der Workshop-Website[1]. Für Anmeldungen bis zum 16.01.2018 ist ein Frühbucherrabatt erhältlich.
URL dieses Artikels:http://www.heise.de/-3913495
Links in diesem Artikel:[1] http://www.heise-events.de/dnssec[2] mailto:dz@ct.de
Copyright © 2017 Heise Medien
Eine neues Encoding für HDFS reduziert den Speicherbedarf, und YARN Timeline Service v.2 erweitert die im YARN Timeline Server eingeführten Dienste zum Speichern anwendungsspezifischer Informationen.
Vier Jahre nach Version 2.0 hat die Apache Software Foundation nun Hadoop 3.0.0 freigegeben. Die Entwicklung der neuen Hauptversion erfolgte parallel zu den 2.x-Releases, und die erste Alpha hatten die Macher bereits im September 2016 veröffentlicht. Nun erachten sie nach einer gut zweimonatigen Betaphase Hadoop 3 als stabil für den produktiven Einsatz.
Zu den Neuerungen gehört unter anderem eine alternative Art der Replikation im Hadoop Distributed File System (HDFS): Das sogenannte Erasure Encoding[1] bringt einen maximalen Overhead von 50 Prozent mit sich. Beim bisher verwendeten 3x Replication Scheme lag er bei 200 Prozent. Der Preis dafür ist jedoch eine höhere Netzwerk- und CPU-Auslastung, sowohl für die HDFS-Clients als auch für die DataNodes. Außerdem sind einige HDFS-Schreiboperationen wie hflush, hsync und append nicht möglich.
Hadoop 3 enthält zudem den YARN Timeline Service v.2[2] als Nachfolger des YARN Timeline Server. Er dient zum Speichern der anwendungsspezifischen Informationen und von Informationen über abgeschlossene Applikationen. So können Entwickler beispielsweise die Zahl der Map- und Reduce-Tasks im Service speichern, und die Informationen lassen sich über eine REST API abrufen.
YARN Timeline Service v.2 soll im Vergleich zum Vorgänger vor allem die Skalierbarkeit verbessern und einfacher zu verwenden sein. Der Dienst separiert neuerdings die Schreib- von den Leseoperationen. Erstere erledigen Kollektoren, von denen jeweils einer für eine einzelne YARN-Applikation zuständig ist. Das Lesen geschieht über separate Instanzen, und die Reader sind über eine REST API angebunden. Als primäres Speichersystem kommt nun HBase zum Einsatz. Der YARN Timeline Service v.2 befindet sich derzeit noch in der Preview-Phase.
Neu ist zudem das erweiterte Framework für YARN Resource Types, um Ressourcen jenseits der CPU und des Hauptspeichers zu verwalten. Besonders mit Blick auf containerisierte und Machine-Learning-Anwendungen lassen sich nun auch GPU und Plattenspeicher managen. Die neu eingeführte YARN Federation ist mit der bereits vorhandenen HDFS Federation vergleichbar und soll die Skalierbarkeit von YARN auf mehrere Zehntausend Knoten erhöhen.
Weitere Neuerungen wie die Opportunistic Container Execution lassen sich dem Blogbeitrag[3] entnehmen. Hadoop 3.0.0 benötigt nun die Java-8-Laufzeitumgebung. In Kürze sind aktualisierte Versionen von HBase, Hive und Phoenix zu erwarten, die ebenfalls für Java 8 kompiliert sein werden. Beim Verfassen dieser Meldung war auf der Download-Seite[4] lediglich die Beta-Version von Hadoop 3 verfügbar, aber das fertige Release sollte in Kürze folgen.
Hadoop ist ein Vorreiter im Bereich Big Data, und der Elefant trotzt weiterhin jeglichen Stimmen, die in Zeiten von Apache Spark und Flink das Ende des Urgesteins sehen. Ihre Anfänge hatte die Plattform bei Google bereits 2003, das zentrale MapReduce-Dateisystem entstand jedoch erst 2004. Der Name Hadoop kam erst später auf, und Version 0.1 erschien 2006. Bis zum 1.0-Release unter dem Dach der Apache Foundation zogen weitere sechs Jahre ins Land. Die Entwicklung zur zweiten Hauptversion benötigte anschließend gerade mal ein Jahr. Dagegen ist die vierjährige Phase bis zum aktuellen Release wieder behäbiger.
URL dieses Artikels:http://www.heise.de/-3918281
Links in diesem Artikel:[1] http://hadoop.apache.org/docs/r3.0.0-beta1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html[2] http://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2.html[3] https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces26[4] http://hadoop.apache.org/releases.html[5] mailto:rme@ct.de
Copyright © 2017 Heise Medien
Neben der aktuellen Programmierer-Studie 2017 präsentiert WeAreDevelopers auch ein eigens von und für Developer entwickeltes Jobportal, dass deren Bedürfnissen besser gerecht werden soll.
Programmierer scheinen scheue Wesen zu sein, diesen Schluss lässt die neue Studie der Plattform WeAreDevelopers[1] zu. So sind nur sechs Prozent der im Rahmen der Studie befragten Programmierer überhaupt aktiv auf Jobsuche und damit für die Personaler suchender Unternehmen erreichbar. Dem entgegen stehen jedoch 41 Prozent Programmierer, die willig und offen für einen Jobwechsel wären. 86 Prozent aller Programmierer im DACH-(Deutschland, Österreich, Schweiz)- & CEE-Raum (Osteuropa und Balkan) würden für eine neue Beschäftigung sogar das Land wechseln. Besonders beliebte neue Heimatländer sind dabei Deutschland, Schweden und Großbritannien.
Softwareentwickler sind ein bedeutender Faktor für die Wachstumsziele vieler Unternehmen, gerade in der zunehmend digitalisierten Wirtschaft. Jedoch fehlen gerade in Europa und besonders in der DACH-Region viele dieser Fachleute. Laut den aktuellen Daten der EU-Kommission gibt es bei 52 Prozent der offenen Entwicklerstellen Probleme mit deren Besetzung, in Österreich liegt der Anteil mit 61 Prozent sogar noch höher. Der aktuelle Wirtschaftsaufschwung verschärft den Mangel an Entwicklern noch zusätzlich, so WeAreDevelopers.
Damit sich zukünftig Programmierer und Personaler einfacher finden können, stellt WeAreDevelopers jetzt das Jobportal devjobs[2] vor – nach dem Muster einer Partnerbörse. Dort sollen sich, laut Benjamin Ruschin, CEO bei WeAreDevelopers, Softwareentwickler durch die eigens für sie programmierte Plattform besser verstanden fühlen und Personaler ihre Jobangebote durch Nachfragen seitens devjobs, besser auf Programmierer abstimmen können. WeAreDevelopers will Programmierer und Personaler vor allem über das Alleinstellungsmerkmal der genau auf Softwareentwickler zugeschnittenen Matching-Elemente erreichen.
Denn, bei der Frage, warum so wenig Personaler die richtigen Entwickler finden, scheint die Antwort der WeAreDeveloper-Umfrage fast schon zu einfach: Mangelnde Entwickler-Fachkenntnis bei den Personalern. So möchten Developer auf Augenhöhe mit dem Personaler sprechen. Dazu gehört, so die Auswertung der Umfrage, dass diese zumindest eine grundlegende Vorstellung vom Programmieren haben. Denn der Mangel an Sachkenntnis führt häufig dazu, dass konkrete Nachfragen zu der offenen Stelle und dem Tätigkeitsumfeld von den Personalern schlecht bis unzureichend beantwortet werden können. Am liebsten wäre den Befragten demnach, dass Personalabteilungen eine Entwickler-Schulung bekommen oder sich zumindest mit der entsprechenden Abteilung kurzschließen, was und wer genau gesucht wird.
85 Prozent der Entwickler sind der Meinung, dass es schwierig ist ein passendes Arbeitsumfeld zu finden. Aktuelle Trends und Entwicklungen wie Home Office, legerer Dresscode, flexible oder auch Vertrauensarbeitszeiten, die für ein angenehmes Arbeitsumfeld sorgen, sind auch bei Entwicklern beliebt und gefragt.
Zu Arbeitsplätzen und Stellenangeboten in der IT-Branche siehe auch den Stellenmarkt auf heise online:
URL dieses Artikels:http://www.heise.de/-3918319
Links in diesem Artikel:[1] https://www.wearedevelopers.com/[2] https://www.wearedevelopers.com/devjobs/[3] https://jobs.heise.de/[4] mailto:kkr@heise.de
Copyright © 2017 Heise Medien
Noch bis zum 14. Januar sind JavaScript-Entwickler eingeladen, sich mit Vortrags- und Workshopideen für die fünfte Auflage der enterJS-Konferenz zu bewerben.
Vom 19. bis 21. Juni 2018 findet in Darmstadt erneut die Enterprise-JavaScript-Konferenz enterJS[1] statt. Vortrags- und Workshopvorschläge[2] nehmen die Veranstalter heise Developer, dpunkt.verlag und iX noch bis zum 14. Januar 2018 entgegen. Willkommen sind alle Einreichungen, die sich mit dem Einsatz von JavaScript im Enterprise-Umfeld beschäftigen – von Herausforderungen, Praxis- und Sicherheitstipps bis hin zu Erfahrungsberichten.
Beispiele für gewünschte Themen sind unter anderem die Integration von JavaScript in bestehende Softwarearchitekturen, Performance- und Sicherheitsoptimierungen sowie der Einsatz von Tools und Frameworks. Wie bereits in den vergangenen Jahren sind Vorträge zu Angular, TypeScript, React und Node.js, aber auch zu Vue.js oder Electron gerne gesehen. Bei Fragen zu Themen oder Gestaltung der Einreichung, hilft das Team der enterJS gern per Mail[3] weiter. Außerdem ist es möglich, sich bestimmte Themen oder Sprecher mit dem Call for Suggestions[4] zu wünschen.
Den Vorträgen am 20. und 21. Juni geht ein Workshoptag voraus, an dem Besucher die Gelegenheit haben, praktisch in die Themen einzusteigen. Das komplette Programm ist Anfang Februar zu erwarten, Rückmeldungen zu den Einreichungen gibt es bis Ende Januar. Wer über enterJS-Neuigkeiten informiert werden möchte, kann den Konferenz-Newsletter abonnieren[5] oder den Veranstaltern auf Twitter[6] folgen.
Impressionen der enterJS 2017
URL dieses Artikels:http://www.heise.de/-3918114
Links in diesem Artikel:[1] https://www.enterjs.de/[2] https://www.enterjs.de/call-for-proposals-de[3] mailto:hello@enterjs.de[4] https://www.enterjs.de/call-for-suggestions-de[5] https://www.enterjs.de/newsletter_eintragen[6] https://twitter.com/enterjsconf[7] mailto:bbo@ix.de
Copyright © 2017 Heise Medien
SuperMUC am LRZ 2012
(Bild: MMM/LRZ)
Der Zuschlag ging an Lenovo und Intel: 6448 Xeon-SP-Server bilden 2018 den SuperMUC Next Generation mit 26,7 PFlops und Warmwasserkühlung.
Heute wurde in München der Vertrag zur Lieferung des SuperMUC Next Generation an das Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften unterzeichnet. Ab März 2018 sollen die ersten Racks installiert werden, die Lenovo mit 6448 Dual-Socket-Maschinen vom Typ ThinkSystem SD 650 DWC bestückt. In jedem davon sitzen zwei Intel Xeon Scalable Processors (Xeon-SP)[1] mit je 24 Kernen, die per AVX-512 rund 2 TFlops Rechenleistung pro CPU liefern.
Alle 309.504 Kerne zusammen leisten also theoretisch 26,7 Petaflops, das Leibniz-Rechenzentrum (LRZ) erwartet 20,4 PFlops Linpack-Rechenleistung – das wäre derzeit Platz 3 auf der Top500-Liste[2] kurz vor dem Piz Daint aus der Schweiz[3]. Letzterer schöpft seine Kraft aber vor allem aus Tesla-Rechenbeschleunigern, während der SuperMUC-NG eben die AVX-512-Einheiten seiner x86-Prozessoren nutzt.
6304 Rechenknoten sind als sogenannte "Thin Nodes" mit je 96 GByte RAM ausgestattet, 144 weitere Fat Nodes mit je 768 GByte; das ergibt insgesamt 715 TByte Hauptspeicher. Als Verbindung kommt Intel Omni Path Architecture (OPA) zum Einsatz, direkt in den Prozessoren angebunden.
Wie beim bisherigen SuperMUC[4] kommt in den einzelnen Servern wieder eine direkte Warmwasserkühlung zum Einsatz, um die Energieeffizienz zu steigern. Rechen-Jobs werden Energie-optimiert ausgeführt, indem die beteiligten Prozessoren ihre Taktfrequenz an passen. Die Phase-2-Aufrüstung des SuperMUC 2015 steht mit 2,8 PFlops derzeit auf Platz 45 der Top500[5].
Zusätzlich bekommt der SuperMUC-NG eine separat laufende Cloud-Komponente mit 64 Knoten, von denen 32 mit je einer Nvidia Volta 100 bestückt sind, beispielsweise zur Visualisierung von Simulationsdaten.
SuperMUC-NG läuft unter SuSE Linux Enterprise (HPC Module), Version 12. Als paralleles Dateisystem dient IBM Spectrum Scale (GPFS).
SuperMUC-NG wird im Rahmen eines Strategie- und Finanzierungsplanes für das Gauss Centre for Supercomputing (GCS) gemeinsam von Bund und Freistaat Bayern je zur Hälfte finanziert. Die Gesamtkosten des Projektes betragen bei einer Laufzeit von 6 Jahren 96 Millionen Euro. Darin sind die Kosten für Energie, Wartung und Personal eingeschlossen.
URL dieses Artikels:http://www.heise.de/-3918072
Links in diesem Artikel:[1] https://www.heise.de/meldung/Intels-Xeon-Prozessorfamilie-Skylake-SP-laeuft-vom-Stapel-Erste-Benchmark-Ergebnisse-gegen-AMD-Epyc-3765089.html[2] https://www.heise.de/meldung/Supercomputer-China-wieder-first-America-second-3889197.html[3] https://www.heise.de/meldung/Top500-der-Supercomputer-Schweizer-Supercomputer-als-Europas-Spitzenreiter-unter-den-Top10-2048325.html[4] https://www.heise.de/meldung/Leistung-des-Hochleistungsrechners-SuperMUC-verdoppelt-2730663.html[5] https://www.top500.org/system/178544[6] mailto:ciw@ct.de
Copyright © 2017 Heise Medien
Mit dem Azure Bot Service können Entwickler automatisierte Chat-Bots erstellen. Cognitive Services Language Understanding (LUIS) dient dem Verständnis natürlicher Sprache und ist aus dem Projekt Oxford hervorgegangen.
Der Microsoft Azure Bot Service und die Microsoft Cognitive Services Language Understanding sind nun allgemein verfügbar. Letzteren Dienst hatte Microsoft 2015[1] ursprünglich als Bestandteil von Projekt Oxford in die Betaphase geschickt, damals noch unter dem Namen Language Understanding Intelligent Service. Den Namen und die Plattform hat Microsoft inzwischen geändert, das Akronym LUIS jedoch beibehalten. Im Sommer 2016[2] ist Project Oxford in den Cognitive Services aufgegangen.
Der Azure Bot Service ist eine Plattform, mit der Entwickler Chat-Bots erstellen. Der Dienst bietet einige Vorlage unter anderem als Frage-und-Antwort-Bot oder zum Ausfüllen von Formularen. Als Programmiersprache kommen C# oder Node.js zum Einsatz. Insgesamt vierzehn vorgefertigte Channels kennt der Dienst zur Interaktion mit den Endanwendern, darunter Skype, Facebook Messenger und Cortana. Mit der allgemeinen Verfügbarkeit sind zusätzliche Sprachen hinzugekommen, und Microsoft bietet Premium Channels an, die unter anderem eine in Websites eingebettete Kommunikation ermöglichen und eine Verfügbarkeit von 99,9 % garantieren.
Language Understanding ist eine Schnittstelle zum Verständnis natürlicher Sprache, wie Anwender es von digitalen Assistenten gewohnt sind. Entwickler können für ihre Apps diverse Sprachmodelle nutzen und eigene erstellen, die auf bestimmte Anwendungen und Bereiche ausgelegt sind. Das System erkennt sogenannte Intents, also die Absichten des Nutzers, und zugehörige Entities mit Zusatzinformationen. Aus dem Text "Buche mir ein Ticket nach Paris" erkennt das System den Intent Flugbuchung und die Entity Paris. Die jeweiligen Intents lassen sich über Funktionen anbinden, die als Parameter die Entities erhalten.
Mit der allgemeinen Verfügbarkeit lassen sich in LUIS nun 500 Intents und 100 Entities verwalten. Außerdem erweitert Microsoft die erweiterten Funktionen für weitere Sprachen. So schlägt LUIS Phrasen für sieben neue Sprachen, darunter Deutsch vor. Vorgefertigte Entities waren bisher nur in Englisch verfügbar. Deutsche Entwickler müssen weiterhin darauf verzichten, aber die Sprachen Französisch und Spanisch sind hinzugekommen.
Weitere Details lassen sich dem Blogbeitrag[3] entnehmen. Demnach haben sich während der Beta gut 240.000 Entwickler für die Azure Bot Services registriert. 760.000 Entwickler aus sechzig Ländern nutzen die Cognitive Services, die allerdings nicht auf LUIS beschränkt sind.
URL dieses Artikels:http://www.heise.de/-3917927
Links in diesem Artikel:[1] https://www.heise.de/meldung/Maschinelles-Lernen-Microsoft-erweitert-Beta-Programm-fuer-Project-Oxford-2860576.html[2] https://www.heise.de/meldung/Maschinelles-Lernen-Microsoft-teilt-Project-Oxford-auf-3265437.html[3] https://azure.microsoft.com/en-us/blog/announcing-the-general-availability-of-azure-bot-service-and-language-understanding-enabling-developers-to-build-better-conversational-bots/[4] mailto:rme@ct.de
Copyright © 2017 Heise Medien
