Anmelden
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
FreshRSS if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Background-Sync-API-Teil-1-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Background-Sync-API-Teil-1-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
Metaphern für Softwareentwicklung gibt es viele. Sie als Spiel zu begreifen, scheint zunächst respektlos. Wenn man tiefer gräbt, ergeben sich aber zahlreiche Parallelen.
Der Begriff "Spiel" steht erst mal für Spaß. Softwareentwicklung ist aber kein Spaß – es geht meistens um ernsthafte Geschäftsziele und oft hohe Budgets. So etwas ist kein Spiel.
Die Spieltheorie [1] ist allerdings eine wissenschaftlich anerkannte Theorie, die sich mit Strategien für Spiele und andere Entscheidungssituationen beschäftigt. Diese Theorie hat viele Anwendungen. Auch Kriege oder Vorgehen in der Wirtschaft werden spieltheoretisch untersucht und so bessere Strategien entwickelt.
Spiele scheinen außerdem trivial zu sein. Schließlich spielen schon Kinder. Aber auch hier liegen bei näherer Betrachtung die Dinge anders. Einige Profis widmen ihr ganzes Leben Spielen wie Schach oder dem asiatischen Spiel Go [2]. Es gibt viel mehr denkbare Go-Stellungen (ca. 10^170) als Atome im Universum (ca. 10^80). Das ist alles andere als trivial.
Softwareentwicklungsprojekte als Spiele zu betrachten, führt zu einigen Erkenntnissen:
Spiele haben Gewinnbedingungen. Jede Aktivität sollte auf die Gewinnbedingungen einzahlen und man muss kollaborieren. Das hilft auch bei Softwareentwicklung.
Vielen Dank an meine Kolleginnen und Kollegen Hanna Prinz, Tobias Erdle und Sonja Scheungrab für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4659442
Links in diesem Artikel:[1] https://de.wikipedia.org/wiki/Spieltheorie[2] https://de.wikipedia.org/wiki/Go_(Spiel)[3] https://www.heise.de/developer/artikel/Ueber-die-optimale-Softwarearchitektur-3785166.html[4] https://de.wikipedia.org/wiki/Pandemie_(Spiel).
Copyright © 2020 Heise Medien
Progressive Web Apps lassen sich auf allen relevanten Plattformen installieren. In manchen Punkten hakt die Integration allerdings noch. So lassen sich aus dem Browser heraus installierte PWAs unter Windows nicht über die Systemsteuerung deinstallieren oder automatisch mit dem Betriebssystem starten. Hier bessert Microsoft nun nach.
Seitdem Microsoft die eigene Entwicklung seiner eigenen Browser-Engine zugunsten von Chromium aufgegeben hat, [1] beteiligt sich das Unternehmen an der Entwicklung des quelloffenen Unterbaus der Webbrowser Google Chrome, Samsung Internet, Brave oder Microsoft Edge. Die Chromium-Kontributoren Google, Microsoft und Intel haben sich darüber hinaus zur Initiative Project Fugu [2] zusammengeschlossen, die Progressive Web Apps leistungsfähiger machen möchte. Als Teil dieser Initiative kümmert sich Microsoft um die Verbesserung der PWA-Integration ins Betriebssystem.
Auf vielen Desktop-Betriebssystemen können Benutzer ihre Anwendungen mit dem Start des Betriebssystems beziehungsweise der Benutzersession direkt ausführen lassen. Unter Windows kennt man diese Funktionalität unter dem Namen Autostart, unter macOS nennt man diese Programme auch Login Items. PWAs sollen bei der Installation vorschlagen können, sich automatisch mit dem System starten zu lassen [3]. Dazu muss die Funktionalität im Web App Manifest [4] angefordert werden. Außerdem ist ein Kontrollkästchen geplant, das Anwender aktivieren müssen, wenn die App in den Autostart gelegt werden soll.
Bei der Installation einer PWA aus dem Browser wird auf Desktop-Systemen eine Verknüpfung in der Programmliste des Betriebssystems hinterlegt. Unter Windows erhalten Anwender im Startmenü per Rechtsklick eine Option zum Deinstallieren von Anwendungen, die zur Liste installierter Programme in der Einstellungen-App führt. In dieser Liste sind PWAs aber noch nicht eingetragen, insofern läuft die Aktion ins Leere. Die Deinstallation funktioniert aktuell etwa nur über das Drei-Punkte-Menü des PWA-Fensters. Microsoft kümmert sich darum [5], dass diese Anwendungen in Zukunft auch aus der Einstellungen-App oder der Systemsteuerung entfernt werden können.
Das Web kann schon heute das Schließen einer Website verhindern, wenn noch offene Aktionen (zum Beispiel ein nicht abgeschicktes Formular oder nicht synchronisierte Änderungen) ausstehen. Die Beschriftung des Dialogs verrät aber nicht, was genau noch offen ist. Produktivitätsanwendungen erlauben Anwendern beim Schließen außerdem oftmals auch eine komplexere Auswahl, etwa das Speichern eines geöffneten Dokuments, das bewusste Verwerfen der Änderungen oder das Abbrechen des Schließvorgangs. Für installierte PWAs möchte Microsoft diese Funktionalität ebenfalls nachreichen [6].
Visual Studio macht es, Spotify macht es, Microsoft Teams macht es auch: Diese Anwendungen erweitern die Titelzeile des Fensters um eigene Steuerelemente, um den verfügbaren Platz effizienter zu nutzen. Auch diese Funktionalität soll installierten Progressive Web Apps bald offenstehen [7]. Die PWA darf sich dabei bis in die Titelzeile erweitern. Nur die Fenstersteuerelemente des Betriebssystems und des Webbrowsers legen sich dann noch über die Anwendung.
Die hier gezeigten Vorschläge verbessern die Benutzererfahrung von Progressive Web Apps besonders auf Desktop-Systemen. An allen Vorschlägen wird derzeit aktiv gearbeitet, ein Zieldatum gibt es derzeit allerdings noch nicht. Die Arbeit von Microsoft zeigt, dass die Lücke zwischen nativen Anwendungen und Progressive Web Apps kontinuierlich schmilzt und Entwickler auch weiterhin einen immer größer werdenden Funktionsumfang erwarten dürfen.
URL dieses Artikels:https://www.heise.de/-4653366
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Analyse-Da-waren-s-nur-noch-drei-4244599.html[2] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[3] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/RunOnLogin/Explainer.md[4] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[5] https://bugs.chromium.org/p/chromium/issues/detail?id=957043[6] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/CustomDialogOnClose/explainer.md[7] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/TitleBarCustomization/explainer.md
Copyright © 2020 Heise Medien
Progressive Web Apps sind in aller Munde. Mit der ersten PWAConf will die Community nun alle PWA-Beteiligten in London zusammenbringen. Auf der Bühne stehen Vertreter der Browserhersteller, Mitglieder der Standardisierungsorganisationen und Webentwickler aus der Community.
Die erste Ausgabe der PWAConf findet am Sonntag, den 19. April 2020, im Victoria Park Plaza Hotel in London statt. An einem ganzen Tag voller technischer Sessions wird zusammengefasst, was das Web als Anwendungsplattform schon heute leisten kann, welche Best Practices es zur Entwicklung nativ erscheinender Webanwendungen gibt und welche zukünftigen Features PWA-Entwickler erwarten. Die PWAConf soll Browserhersteller, Mitglieder der Standardisierungsgremien, Webentwickler und weitere PWA-Enthusiasten in den gemeinsamen Austausch bringen.
Das Programm wird von der PWA-Community zusammengestellt, vertreten durch Majid Hajian, Christian Liebel (Thinktecture), Laura Morinigo (Samsung Internet) und Maxim Salnikov (Microsoft). Gastgeber der Veranstaltung ist die International JavaScript Conference, die ihre Infrastruktur freundlicherweise für die Community-Konferenz bereitstellt. Die iJS schließt sich vom 20. bis 22. April 2020 im selben Hotel an. Tickets sind für 89 GBP zzgl. VAT erhältlich. Zehn kostenfreie Diversity-Tickets werden an Teilnehmer unterrepräsentierter Gruppen in der IT vergeben. Weitere Informationen sind unter PWAConf.io [1] zu finden.
URL dieses Artikels:https://www.heise.de/-4653876
Links in diesem Artikel:[1] https://pwaconf.io
Copyright © 2020 Heise Medien
Cross-Platform-Entwickler, die auf Webtechniken setzen, haben die Qual der Wahl: Verpackt man Web-Apps auf altbewährte Weise mit Apache Cordova und GitHub Electron? Oder greift man lieber auf Progressive Web Apps zurück, bei denen das Leben der Anwendung im Browser beginnt?
Optisch unterscheiden sich beide Methoden kaum: Am Ende läuft die eigene Web-App auf Desktopsystemen in einem eigenen Fenster, auf Mobilgeräten vollflächig – wie alle anderen Apps auch. Unterschiede gibt es jedoch in der Art der Verteilung und im Funktionsumfang.
Bei Cordova und Electron wird eine Webanwendung in einem nativen Anwendungsrahmen verpackt. Über ihn lassen sich sämtliche Funktionen und APIs aufrufen, die die jeweilige Plattform zur Verfügung stellt. Insgesamt stehen diese Anwendungen ihren nativen Gegenstücken in nichts nach. Daher können sie auch über alle Vertriebswege verteilt werden, typischerweise App-Stores im mobilen Umfeld oder als Executable für den Desktop.
Problematisch bei diesem Ansatz ist aber, dass nicht nur die Anwendung selbst zu warten ist, sondern auch der Container. Bei Electron sind neben der eigentlichen App darüber hinaus noch Node.js und Chromium Teil des Anwendungsbündels, die regelmäßig aktualisiert werden sollten. Im Falle von Cordova ist festzustellen, dass die bereitgestellten Plug-ins, die Zugriff auf native Funktionen erlauben, zunehmend altern und die Weiterentwicklung oftmals an einer überschaubaren Anzahl an Community-Mitgliedern hängt.
Progressive Web Apps kommen komplett ohne diesen Wrapper aus. Stattdessen beginnt das Leben der Anwendung im Browser, von dort kann sie auf dem jeweiligen Gerät installiert werden. Somit fallen auch keine Kosten für App-Stores an, Verkäufe oder Abogebühren sind ebenfalls nicht mehr zwingend mit dem Plattformanbieter zu teilen. Das heißt aber nicht, dass sich diese Anwendungen nicht später doch wieder in einen Store einstellen lassen. Der Microsoft Store und Google Play nehmen so auch Progressive Web Apps auf.
Allerdings können Progressive Web Apps nicht auf sämtliche nativen Schnittstellen zugreifen, sondern nur auf diejenigen, für die es auch eine Webschnittstelle gibt. Das Web hat in den vergangenen Jahren viele APIs mit nativer Power erhalten, etwa Browserdatenbanken, Zugriff auf Geolocation, Mikrofon und Kamera, doch es bleibt noch ein gewisser Versatz zum kompletten nativen Funktionsumfang. Dank Initiativen wie Project Fugu [1] schwindet dieser Abstand aber zusehends.
Webanwendungen sollten zunächst immer mit dem Ziel entwickelt werden, eine Progressive Web App zu sein. Niemand hindert Entwickler später daran, diese doch noch in einem nativen Anwendungscontainer zu verpacken. Wer zu sehr auf native APIs baut, kann seine Anwendung umgekehrt nicht so einfach als PWA bereitstellen. Nur dann, wenn Entwickler auf eine kritische Funktion stoßen, für die es keine Webschnittstelle gibt oder zwingend ein Executable oder eine Präsenz im Apple App Store gebraucht wird, sollten sie ergänzend oder alternativ auf Wrapper-Ansätze wie Cordova und Electron zurückgreifen.
Ausführlich beleuchten Christian Liebel und Thorsten Hans von Thinktecture dieses Thema am 27. Februar 2020 im Rahmen der BASTA! Spring in Frankfurt [2].
URL dieses Artikels:https://www.heise.de/-4634262
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://basta.net/web-development/electron-cordova-pwa-was-wann-wie-und-warum/
Copyright © 2020 Heise Medien
Zum Jahreswechsel sprechen wir in richtig großer Runde über 2019 und wagen uns an die Predictions für 2020. Und die Zuschauer/-hörer sind ebenfalls gefragt.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Pünktlich zum Jahreswechsel ist das Team von c't uplink noch einmal überkomplett: Zwar haben Fabian Scherschel und Hannes Czerulla den Verlag verlassen, aber für unsere Jahresendfolge sind die beiden extra wieder einmal nach Hannover gekommen. Mit ihnen sprechen Merlin Schumacher, Michael Wieczorek, Achim Barczok, Jan-Keno Janssen, Johannes Maurer und Martin Holland diesmal in einer sehr großen Runde über das abgelaufene Jahr. Außerdem wagen wir und unsere Leser uns einmal mehr an Vorhersagen für das beginnende und prüfen die für das abgelaufene Jahr.
Bevor wir nach vorne blicken, sprechen wir aber noch einmal darüber, dass wieder Meldungen über Sicherheitslücken oder Datenabgriffe das Jahr dominiert haben. Außerdem ging es auf heise online und in c't im vergangenen Jahr natürlich um das Vorgehen der US-Regierung gegen Huawei, Hacker, die einfach mal zurück hacken, FIDO2 und Hacking-Gadgets – aber auch ganz analog ums Schlösserknacken. Bevor wir dann einmal mehr versuchen, Vorhersagen für das beginnende Jahr zu treffen, darf jeder noch seinen Lieblingsfilm, seine Lieblingsserie, sein Lieblingsbuch und sein Lieblingsspiel aus 2019 kurz (!) vorstellen.
Diesmal mit dabei: Jan-Keno Janssen, Hannes Czerulla, Achim Barczok, Fabian Scherschel, Merlin Schumacher, Martin Holland, Johannes Börnsen und Michael Wieczorek
Die komplette Episode 30.8 zum Nachhören und Herunterladen:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Die c't 2/2020 [8] gibt's am Kiosk, im Browser [9] und in der c't-App [10] für iOS [11] und Android [12].
Alle früheren Episoden unseres Podcasts findet ihr unter www.ct.de/uplink [13].
()
URL dieses Artikels:https://www.heise.de/-4627361
Links in diesem Artikel:[1] https://ct.de/uplink[2] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[3] https://itunes.apple.com/de/podcast/ct-uplink/id835717958[4] https://itunes.apple.com/de/podcast/ct-uplink-video/id927435923?mt=2[5] https://podcasts.google.com/?feed=aHR0cHM6Ly93d3cuaGVpc2UuZGUvY3QvdXBsaW5rL2N0dXBsaW5rLnJzcw[6] https://blog.ct.de/ctuplink/ctuplink.rss[7] https://blog.ct.de/ctuplink/ctuplinkvideohd.rss[8] https://www.heise.de/select/ct/2020/2[9] https://www.heise.de/select/ct[10] https://www.heise.de/ct/Das-digitale-Abo-1818298.html[11] https://apps.apple.com/de/app/ct-magazin/id380266921[12] https://play.google.com/store/apps/details?id=de.heise.android.ct.magazin[13] http://www.ct.de/uplink[14] mailto:mho@heise.de
Copyright © 2020 Heise Medien
Große komplexe Projekte sind schwer zu handhaben. Software-Release-Trains sind eine Lösung zur Koordination. Aber der Ansatz läuft Selbstorganisation und modernen Management-Konzepten zuwider.
Ein Release Train [1] dient zur Koordination mehrerer abhängiger Projekte. Im Rahmen dessen entwickeln alle Projekte aufeinander abgestimmte Versionen, die Phasen wie Beta-Testing, Release oder Updates gemeinsam durchlaufen. Die Idee hat sich in vielen großen Projekte wie Eclipse, Ubuntu, dem Spring Framework oder LibreOffice bewährt.
Das Scaled Agile Framework (SAFe) schlägt einen Agile Release Train [2] vor, um die Arbeit mehrerer agiler Teams zu koordinieren. Sie haben einen festen Zeitpunkt, zu dem sie liefern, und bieten alle zwei Wochen ein neues Systeminkrement mit einer System-Demo. Der Agile Release Train koordiniert die Entwicklung der Software und dann das Release, nach dem Nutzer die neuen Features verwenden können. Also geht es darum, die Entwicklung eines oder mehrerer größeren Features über mehrere Teams zu koordinieren. Das Ziel ist es, dass nicht nur die einzelnen Teams, sondern auch das gesamte System regelmäßig neue Features ausrollt. So sollen mögliche Probleme bei den größeren Features offenbar werden. Natürlich gibt es für einen Agile Release Train diverse Rollen für eine zentrale Koordination.
Koordination ist für eine Zusammenarbeit immer notwendig, aber es erzeugt auch einen Overhead. Eine zentrale Koordination steht in einem Widerspruch dazu, möglichst viel Verantwortung zu delegieren. Moderne Organisationen sollten möglichst wenig Hierarchien haben und die Teams sollten selbstorganisiert arbeiten, statt auf die zentrale Koordination und ein Command & Control angewiesen zu sein. Ohne eine zentrale Kontrolle skaliert die Organisation außerdem besser.
Übermäßige Koordination ist zwar ein organisatorisches Problem, aber die Ursache kann ein Architektur-Problem sein: Wenn Änderungen, die für einen Kunden einen Wert darstellen, die Koordination mehrerer Teams und Komponenten erfordern, kann ein besserer fachlicher Schnitt die Anzahl der beteiligten Komponenten und damit der Teams reduzieren. Domain-driven Design [3] schlägt dafür einige Maßnahmen vor. Wenn die Koordination in einem Agile Release Train sehr kompliziert ist, dann lohnt es sich auf jeden Fall, einen Blick auf die Architektur zu werfen und zu schauen, ob dort Optimierungspotenziale vorliegen.
Aber auch wenn die Softwarearchitektur perfekt ist, können für ein Feature natürlich Änderungen notwendig sein, die mehrere Teams betreffen. Schließlich arbeiten die Teams gemeinsam an einem System, und Features können daher immer auf mehrere Teams verteilt sein. Dafür schlägt Domain-driven Design auch verschiedene Pattern vor. Bei dem Pattern "Customer/Supplier" (Kunde/Lieferant) kann das Customer-Team bei dem Supplier-Team die Implementierung von Features anfordern. Die Alternative ist "Conformist": Dann muss das Team nehmen, was es bekommt, und kann keine Implementierung von Features anfordern.
Also kann ein DDD-Team auch dann ein Feature implementieren, wenn es dazu auf Zulieferungen angewiesen ist. Dazu müssen lediglich die "Spielregeln" zwischen Teams wie Customer/Supplier festgelegt sein. Natürlich kann es gegebenenfalls notwendig sein, noch eine Eskalationsinstanz für Streitigkeiten zu definieren, aber unter normalen Umständen können die Teams so ohne zentrale Koordination arbeiten und sich untereinander dezentral koordinieren.
Die kollaborative Entwicklung von Features ähnlich wie bei einem Agile Release Train gibt es bei DDD auch. DDD beschreibt es als "Partnership". Nun ist eine Partnerschaft eigentlich positiv besetzt. Die englische Ausgabe der DDD-Referenz [4] nutzt zur Illustration von Partnership ein Drei-Bein-Rennen, also ein Rennen, bei dem die Teilnehmer an einem Bein zusammengefesselt sind. Eine solche Partnerschaft und die damit verbundene enge Koordination führen eher zu einem Problem, so wie es bei einem Agile Release Train auch zu erwarten ist.
Eine enge zentralen Koordination, wie sie Agile Release Trains umsetzen, sollte bei einer guten Softwarearchitektur nicht unbedingt notwendig sein und kann mit anderen Mitteln umgangen werden. Vielleicht ist die wahrgenommene Sicherheit ein Grund dafür, dass Ansätze wie SAFe erfolgreich sind. Durch die Koordination wird eine Kontrolle des Fortschritts auf der Ebene des Gesamtprojekts möglich und notwendig. Das kann eine höhere Sicherheit vermitteln. Zuständigkeiten wirklich an Teams zu delegieren erfordert hingegen ein hohes Maß an Vertrauen.
Release Trains koordinieren die Zusammenarbeit verschiedener Teams. Ansätze aus dem Domain-driven Design hingegen delegieren noch mehr Zuständigkeit in die Teams und benötigen daher weniger Koordination
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4598765
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Software_release_train[2] https://www.scaledagileframework.com/agile-release-train/[3] https://ddd-referenz.de/[4] https://domainlanguage.com/ddd/reference/
Copyright © 2019 Heise Medien
Agilität in der Softwareentwicklung wird oft unzureichend umgesetzt und gelebt. Hilft sie trotzdem?
Softwareentwicklung ist kompliziert und komplex. Deswegen führen viele Projekte zu Fehlschlägen. Es ist schon schwer genug festzustellen, ob ein Projekt erfolgreich war oder nicht. Die Ziele sind gegebenenfalls nicht klar definiert, aus politischen Gründen können Fehlschläge zu Erfolgen umdefiniert werden und schließlich gibt es verschiedene Parameter, nach denen Erfolg bewertet werden kann. Subjektiv scheint der Anteil der Projekte, die eines oder mehrere der Projektziele nicht erreichen, durchaus signifikant zu sein.
Eine schon lange etablierte Untersuchung über den Erfolg von Projekten ist der Chaos-Report der Standish Group [1]. Er stellt seit 1994 Erkenntnisse über IT-Projekte zusammen. Er verfügt über eine Datenbasis von über 20 Jahren und über 50.000 Projekten. Die Analysten bewerten die Projekte, sodass die Bewertung als Erfolg oder Misserfolg nicht auf den subjektiven Eindrücken der am Projekt Beteiligten basiert. Der Report aus dem Jahr 2015 ist kostenlos erhältlich. Er zeigt, dass schon seit mehreren Jahren circa 20 Prozent der Projekte Fehlschläge sind. Etwa 40 Prozent haben nicht alle Ziele erreicht und weitere 40 Prozent sind erfolgreich. In Kategorien wie Einhalten des Zeitplans, der Kosten oder der Termine erreichen zwischen 40 und 60 Prozent die Ziele nicht. Laut dem Report reduziert Agilität diese Zahlen erheblich, teilweise auf die Hälfte.
Diese Zahlen kann man sicherlich kritisieren: Erfolg ist kaum objektivierbar. Lange hat der Chaos-Report als Erfolgskriterien Budget, Scope und Zeit definiert. Agile Projekte können aber vorab keinen vollständigen Scope definieren, sondern planen nur das nächste Inkrement. Also können echte agile Projekte einen Scope nicht erfolgreich einhalten, weil er am Anfang des Projekts unbekannt ist. Das wirft die Frage auf, wie sich die Einhaltung des Scopes dann überhaupt bewerten lässt, wenn die Projekte tatsächlich agil sind.
Wegen dieser Widersprüche kann es gut sein, dass die "agilen" Projekte aus dem Chaos-Report zwar einige Praktiken umsetzen, aber nicht alle. Aber auch aus anderen Gründen sind Zweifel daran angebracht, ob die "agilen" Projekte wirklich agil sind. So gibt es viele Missverständnisse [2] in diesem Bereich. Viele Projekte nennen sich agil, obwohl sie in Wirklichkeit teilweise fundamentale Konzepte nicht umsetzen. Die agilen Projekte aus dem Chaos-Report sind also wahrscheinlich eher Projekte, die eine "kaputte" Version von Agilität umsetzen. Positiv ausgedrückt: Sie haben angefangen, Agilität zu adaptieren, aber haben noch lange nicht alles Wichtige umgesetzt. Da Agilität ein kontinuierlicher Verbesserungsprozess sein sollte, ist die Adaption von Agilität eigentlich nie vollständig abgeschlossen, aber auch dieser wichtige Aspekt wird oft nicht befolgt.
Wenn es tatsächlich so sein sollte, dass die "kaputte" Umsetzung agiler Mechanismen bereits erhebliche Verbesserungen bei den Projektergebnissen ergibt, dann ist dieser Weg wirtschaftlich auf jeden Fall sinnvoll. Man könnte sogar die Frage stellen, welchen weiteren wirtschaftlichen Vorteil die vollständige und korrekte Umsetzung von Agilität ergibt. Für solche wirtschaftlichen Vorteile gibt es aber durchaus gute Indizien [3]. Aber die Umsetzung vollständiger Agilität – und vor allem der agilen Werte – könnte aufwendig sein, ohne dass es dafür einen entsprechenden wirtschaftlichen Vorteil gibt. Dann könnten die teilweise sehr schlecht umgesetzten agilen Prozessen bezüglich der Kosten-Nutzen-Abwägung wirtschaftlich nahezu optimal sein, weil sie relativ leicht zu erreichen sind und bereits erhebliche Vorteile bieten.
Um es mit Voltaire zu sagen: Das Bessere – also "echte" Agilität – ist eben der Feind des Guten – also "kaputte" Agilität. Man wird also eine weitere Verbesserung nur erreichen, wenn man sich nicht mit etwas zufrieden gibt, das bereits ausreichend gut ist. In der Folge könnten kaputte agile Prozesse ein Dauerzustand werden. Das mag zwar wirtschaftlich sinnvoll sein. Aber es sind nur bedingt positive Aussichten, weil "kaputte" Prozesse demotivieren und oft gerade Werte und Kultur leiden – und darunter leiden dann oft auch Menschen. Hoffen wir also, dass es nicht so ist.
Wenn "kaputte" Agilität schon deutliche Vorteile bringt, erklärt das, warum die Prozesse oft kaputt sind und warum sie nicht noch weiter verbessert werden.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl und Hanna Prinz für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4599441
Links in diesem Artikel:[1] https://www.standishgroup.com/[2] https://www.heise.de/developer/artikel/Die-Perversion-agiler-Metaphern-4466436.html[3] https://www.heise.de/developer/artikel/Das-Problem-mit-der-Agilitaet-4140080.html
Copyright © 2019 Heise Medien
rel=self feed redirections when WebSub is disabled #2659
Bei der c't startet Weihnachten dieses Jahr schon im November – mit Geschenketipps der Redaktion für alle Lebenslagen und kleine wie große Geldbeutel.
Den Geschenkemarathon schon im November zu starten, ist aus unserer Sicht eine gute Idee: Kaum ein Geschenk ist ausverkauft, die Schlangen in den Geschäften sind kurz und in der Packstation ist noch genug Platz. Wenn alle Geschenke Anfang Dezember bereitliegen, können Sie die anschließende Adventszeit ohne Stress bei einem Glas Glühwein und mit gutem Gewissen genießen.
50 Redakteurinnen und Redakteure der c't haben ihre persönlichen Favoriten für Geschenke aus dem laufenden Jahr zusammengetragen. Dabei ist Originelles, Lustiges und Nützliches für jeden Geldbeutel zusammengekommen: Die Spanne reicht bei den Geschenkideen von unter 10 bis über 500 Euro.
Für eine bessere Übersicht haben wir unsere Geschenkvorschläge in fünf Kategorien unterteilt. In "Safer Christmas" [1] finden Sie alles, was Ihre Daten oder Ihr Zuhause sicherer macht, vom verschlüsselten Speicherstick bis zum Kellerschloss mit Fingerabdrucksensor.
Bei den Sachen für die Kindsköpfe [2] haben wir alles gesammelt, was Kindern und Kindgebliebenen Spaß macht, beispielsweise ein VR_Headset zum Selberbasteln für die Nintendo Switch oder programmierbare Roboter von Lego. Bei "Schöner arbeiten" [3] finden Sie Nützliches fürs Homeoffice, unter anderem mit ausgefallenen Tipps für eine mobile Bluetooth-Tastatur und eine handschonende Maus.
Geschenkideen für Feld, Wald und Flur gibt es in der Abteilung "Draußen im Walde ..." [4]. Dort finden Sie Geschenkideen wie einen Rucksack mit großem LED-Panel oder kabellose In-Ears, die richtig was taugen.
Ideen fürs intelligente Zuhause gibt es zu guter Letzt bei der "Smarten Weihnacht" [5]. Ihre Lieben können Sie mit stylishen Lautsprechern überraschen oder einem fleißigen Roboter, der die Wohnung nicht nur saugt, sondern gleich noch nass wischt.
URL dieses Artikels:https://www.heise.de/-4583006
Links in diesem Artikel:[1] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-eine-sichere-Weihnacht-4574100.html[2] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-Kinder-und-Junggebliebene-4574081.html[3] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuers-festliche-Homeoffice-4574075.html[4] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuers-offene-Gelaende-4574059.html[5] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-Smart-Home-Freunde-4574038.html
Copyright © 2019 Heise Medien
SameSite=Lax #2630
Rechtzeitig zu Halloween erschienen ist das First-Person-Horror-Game The Beast Inside. Der Gruselspaß mit spannender Story und düsterer Atmosphäre ist allerdings nichts für schwache Nerven.
Als der Kryptoanalytiker Adam und seine Frau Ende der 1970er Jahre aus der Großstadt aufs Land ziehen, wirkt alles noch recht idyllisch. Das Haus steht mitten in der Natur, ist umgeben von Bäumen und Bächen und liegt weitab der Zivilisation. Alles in allem also ein friedlicher Ort. Doch natürlich ist längst nicht alles so, wie es scheint.
Auf der Suche nach Farbe stößt Adam auf das mysteriöse Tagebuch von Nicolas Hyde, der das Haus früher bewohnte. Das ist dann auch der Auftakt zu einem Alptraum. Versetzt ins 19. Jahrhundert spielt man nun aus der Sicht des Tagebuchautors. Auf der Suche nach dessen Familie begegnen diesem seltsame, gefährliche Kreaturen.
Das Spiel The Beast Inside des polnischen Studios Illusion Ray ist nichts für schwache Nerven. Mit dem Sprung in die Vergangenheit ändert sich die Atmosphäre schlagartig. Im Gegensatz zur ruhigen und einladenden Umgebung des Jahres 1979 wirkt das Jahr 1864 sehr düster. In der First-Person-Perspektive läuft man nun durchs Spiel, löst Rätsel und sammelt und verschiebt Gegenstände, um voran zu kommen. Doch kaum versucht man, das Haus mit Kerzen zu beleuchten, tauchen erste ungeladene Gäste auf. Das ist der Startschuss für eine ganze Reihe an Schreckmomenten, die noch folgen werden.
Das Horror-Spiel The Beast Inside punktet mit einer fesselnden Story, aber auch mit vielen Interaktionsmöglichkeiten. Besonders die Ausarbeitung der Gegenstände ist gelungen. Man kann mit fast jedem Gegenstand interagieren, man kann vieles werfen, beiseiteschieben oder anheben. Die Art, wie man mit den Dingen umgeht, beeinflusst dabei auch das Spielgeschehen. Beeindruckend ist die mit Hilfe von Photogrammetrie erschaffene, sehr detailreiche Grafik des Spiels.
Die düstere Atmosphäre und die häufigen Schreckmomente machen The Beast Inside zu einem wunderbar grusligen Spiel. Aktuell gibt es das Horror-Game The Beast Inside für 20,99 Euro auf Steam [3].
()
URL dieses Artikels:http://www.heise.de/-4576718
Links in diesem Artikel:[1] [2] [3] https://store.steampowered.com/app/792300/The_Beast_Inside/[4] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Das erste Jakarta-EE-Release bringt keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war. Hinter den Kulissen hat sich aber einiges mehr getan.
Fast auf den Tag genau zwei Jahre, nachdem Oracle Java EE geöffnet und an die Eclipse Foundation übergeben hat, war es am 10. September endlich soweit: Jakarta EE 8, die erste vollständige Open-Source-Variante des Enterprise-Java-Standards, wurde veröffentlicht [1].
Was erwartet uns mit diesem Release? Eine zu 100 Prozent kompatible Version zu der bisher unter der Obhut von Oracle stehenden Java Enterprise Edition 8. Das ist nicht wirklich viel für zwei Jahre harter Arbeit, werden sich jetzt manche Leser sicherlich denken. Trotzdem stellt dieses Release einen der wohl wichtigsten Meilensteine in der mittlerweile 20-jährigen Geschichte der Java Enterprise Edition dar. Denn in den vergangenen 24 Monaten wurde in der Eclipse Foundation die Grundlage für eine offene, Community-getriebene Weiterentwicklung des Enterprise-Java-Standards in Richtung Cloud-native geschaffen und damit eine Zukunft für den bereits totgesagten Standard ermöglicht – nicht mehr und nicht weniger.
"Open Source Cloud Native Java: Powered by participation, Jakarta EE is focused on enabling community-driven collaboration and open innovation for the cloud”, heißt es entsprechend prominent auf der Startseite von Jakarte EE.
Natürlich verwundert gerade vor diesem Hintergrund ein wenig, dass sich im aktuellen Release keine neuen (Cloud-)APIs finden. Das hat seinen Grund.
Dass Jakarta EE mit seinem ersten Release noch keine Innovationen mit sich bringen würde, war bereits sehr früh klar. In einem ersten Schritt wollte die Jakarta EE Working Group, in der sich neben der Eclipse Foundation auch Vertreter von Oracle, Fujitsu, IBM, Payara, Red Hat und Tomitribe finden, zunächst sicherstellen, dass Jakarta EE 8 vollständig kompatibel zum bisherigen Standard ist. Nur so kann gewährleistet werden, dass alle bisherigen Nutzer von Java EE ihre Anwendungen mit möglichst wenig Aufwand migrieren und so ihr bis dato getätigtes Investment sichern können. Ein Muss für die Akzeptanz innerhalb der Java-EE-Community.
Das alleine dieser Schritt schon einem erheblichen Kraftakt gleichkommt, zeigt ein Blick auf die Webseite von Jakarta EE 8 [2]. Insgesamt 43 Projekte mit mehr als 60 Millionen Zeilen Code mussten von Oracle zur Eclipse Foundation umziehen, um dort, ein wenig aufgeräumt, in eine eigene Build- und Deplyoment-Infrastruktur eingebettet und via Git-Repositories der Öffentlichkeit zur Verfügung gestellt zu werden. Neben den Spezifikationen der APIs [3] selbst betrifft das vor allem die TCKs. Witzigerweise mussten auch alle Bugs beziehungsweise Issues übernommen werden, um eine 100-Prozent-Kompatibilität zu gewährleisten.
Das erste Jakarta-EE-Release bringt also keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war, hinter den Kulissen hat sich aber in den letzten zwei Jahren einiges mehr getan.
Alle Jakarta-EE 8-Spezifikationen wurden gemäß dem neu geschaffenen Jakarta EE Specification Process (JESP [4]) beschrieben, welcher der Nachfolger des Java Community Process (JCP) ist. Auch wenn die Namen der Spezifikation im Rahmen der Migration sinnvollerweise vereinheitlicht wurden und somit dem Wildwuchs der vergangenen Jahre – JMS zum Beispiel ist ein Service, JTA dagegen eine API und JCA eine Architektur – ein Ende gesetzt wurde, sind sie inhaltlich kompatibel zu ihren Java-EE-8-Pendants. Das gilt sowohl für die APIs und Javadocs als auch für die verwendeten javax.*-Namespaces. Eine Ausnahme stellen lediglich die Oracle-Trademarks dar, die ausgetauscht werden.
Neben den Spezifikationen selbst wurden auch die zugehörigen TCKs migriert und als Jakarta EE 8 TCKs veröffentlicht (Eclipse Public Licence, EPL 2.0). Auch diese sind kompatibel zu den Java EE 8 TCKs.
Bereits Anfang des Jahres wurde Eclipse GlassFish 5.1 veröffentlicht und mit Java EE 8 zertifiziert. Während die Sourcen des Anwendungsservers zu diesem Zeitpunkt bereits bei der Eclipse Foundation lagen, liefen die Tests damals noch auf der Infrastruktur von Oracle. Zeitgleich mit der Veröffentlichung von Jakarta EE 8 durchlief Eclipse GlassFish 5.1 auch auf der eigenen Infrastruktur die TCKs und gilt somit nicht nur als Java-EE-8- sondern auch als Jakarta-EE-8-kompatibel (Full Platform und Web Profile). Eine Liste aller bereits heute kompatiblen Server findet sich unter "Jakarta EE 8 Compatible Products [5]".
Der ganze Aufwand der letzten zwei Jahre rechnet sich natürlich nur dann, wenn die Zukunftsvisionen der Eclipse Foundation auch realisiert werden. Wir erinnern uns: "Open Source Cloud Native Java". Laut Aussage der Open-Source-Organisation möchte man zukünftig deutlich schneller und regelmäßiger neue Releases veröffentlichen. Schaut man sich einmal die Releasezyklen des JDKs oder aber der ebenfalls in der Eclipse Foundation beheimateten MicroProfiles an, scheint das ein durchaus realistisches Ziel zu sein.
Zusätzlich möchte man die Einstiegshürde deutlich verringern. Das gilt sowohl für Hersteller von Application-Servern als auch für Unternehmen, Gruppen oder einzelne Personen, die den neuen Standard vorantreiben wollen. Ein erster wichtiger Schritt hierzu ist durch die Öffnung der TCKs sowie dank des neu geschaffenen Jakarta EE Speficication Process bereits getan.
Laut eigenen Angaben sollen neue Spezifikationen zukünftig vornehmlich nach dem "Code First"-Ansatz entstehen. Das heißt, APIs sollen sich erst einmal in der Praxis etablieren, bevor sie in eine Spezifikation gegossen werden. Eine in der Open-Source-Community gängige Praxis, die vor den aus der J2EE-Welt – und teilweise auch noch aus der Java-EE-Welt – nur zu gut bekannten, am Reißbrett entworfenen Elfenbeinturm-APIs schützten soll und darüber hinaus sicherlich die Akzeptanz in der Community für neue APIs erhöhen wird.
Eine Umfrage in der Community [6] hat gezeigt, dass vor allem Cloud-native-Themen wie Microservices, Kubernetes und Services-Meshes (insbesondere Istio) kritisch für den zukünftigen Erfolg von Jakarta EE sein werden und daher Top-Kandidaten für neue Spezifikationen sind. Insbesondere in Hinblick auf die Unterstützung von Microservices ist davon auszugehen, dass neben der Spezifikation neuer APIs vor allem eine stärkere Annäherung an MicroProfile.io [7] stattfinden wird. Das legt auch die Agenda der parallel zum Release von Jakarta EE stattgefundenen Online-Konferenz JakartaOne [8] nahe, in der sich etliche Vorträge mit der gemeinsamen Verwendung von Jakarta EE 8 und MicroProfile 3 beschäftigt haben.
Bevor allerdings die nächsten Schritte angegangen werden können, muss zunächst noch ein "kleines" Problem aus der Welt geschaffen werden: Die Umbenennung aller Java-API-Packages von javax.* zu jakarta.*. Oracle hat zwar die weitere Verwendung des Package-Präfix javax gestattet, das aber nur dann, wenn die APIs unverändert bleiben. Neue APIs oder Änderungen (dies gilt übrigens auch für Bugfixes) an bestehenden APIs führen automatisch auch zu einem Verbot der Verwendung von javax.
Eine Diskussion darüber, ob es zukünftig immer dann zur Umbenennung kommen soll, wenn eine API angefasst wird oder alternativ alle Packages einmalig refaktorisiert werden sollen, hat eine klare Tendenz in Richtung Big Bang aufgezeigt. Man war sich ebenfalls einig darüber, dass lediglich ein Austausch von javax.* zu jakarta.* stattfinden soll, weitere Änderungen hinter dem Präfix aber zu unterlassen sind.
Entsprechend sieht es aktuell danach aus, dass auch das kommende Release Jakarta EE 9 weiterhin keine neuen APIs mit sich bringen wird, sondern lediglich die neuen Package-Strukturen realisiert. Bestehende Anwendungen, die zukünftig auf Jakarta EE 9 Servern laufen wollen, müssten also entsprechend umgestellt werden. Hierbei können die Refactoring-Tools der IDEs helfen. Alternativ könnten die Application-Server intern die alten Package-Namen auf die neuen mappen, sodass existierende Jakarta-8-Anwendungen ohne jeglichen Aufwand auch auf Jakarta 9+ lauffähig wären. Neben dem ganzen Voodoo, den Application-Server schon heute betreiben, kein wirkliches Hexenwerk.
Weiterhin ist davon auszugehen, dass nach GlassFish, OpenLiberty (IBM) und WildFly (Red Hat), auch andere Java-EE-8-Application-Server die Jakarta TCKs durchlaufen und sich somit Jakarta-EE-kompatibel nennen dürfen. Selbst Oracle hat bereits angekündigt, dass man mit Hochdruck an einer gleichzeitig mit Java EE 8 und Jakarta EE 8 kompatiblen Version des WebLogic Application Server arbeitet.
"We're extremely pleased that Jakarta EE 8 has been released. This represents the culmination of a great deal of work by the entire Jakarta EE community, including Oracle, and we appreciate everyone's contributions. Oracle is working on the delivery of a Java EE 8 and Jakarta EE 8 compatible WebLogic Server implementation…", so Tom Snyder, Vice President Oracle Software Development.
Die ersten wirklichen Innovationen in Richtung Cloud-native sind wahrscheinlich erst mit Jakarta EE 10 zu erwarten. In Zeiten des JCPs wäre das in fünf bis zehn Jahren gewesen. Die Eclipse Foundation schafft es hoffentlich in einem Zehntel der Zeit. Ein erster heißer Kandidat für eine neue API ist Jakarta NoSQL [9] zur herstellerunabhängigen Anbindung und Nutzung von NoSQL-Datenbanken innerhalb von Jakarta-EE-Anwendungen.
Es kommen spannende Zeiten auf uns zu. Zeiten, die über die Zukunft des Enterprise-Java-Standards entscheiden werden. Nach meiner persönlichen Erfahrungen mit der Eclipse Foundation (im Rahmen von MicroProfile.io) und der Enterprise-Java-Community bin ich sehr guter Hoffnung, dass diese Zeiten positiv sein werden.
URL dieses Artikels:https://www.heise.de/-4522665
Links in diesem Artikel:[1] https://www.heise.de/meldung/Quelloffene-Enterprise-Java-Spezifikation-Jakarta-EE-8-geht-an-den-Start-4519179.html[2] https://www.jakarta.ee/release[3] https://github.com/jakartaee/specifications[4] https://jakarta.ee/about/jesp/[5] https://jakarta.ee/compatibility[6] https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf[7] https://microprofile.io[8] https://jakartaone.org/#plan-of-the-day[9] https://projects.eclipse.org/proposals/jakarta-nosql
Copyright © 2019 Heise Medien
Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses mal habe ich mit Gunnar Morling über Change Data Capture und das Open-Source-Projekt Debezium gesprochen.
Thorben Janssen: Vielen Dank, dass du wieder für ein Gespräch bereitstehst. Der eine oder andere hat vielleicht das frühere Interview mit dir über die Bean-Validation-2.0-Spezifikation [1] verpasst. Kannst du dich bitte noch mal kurz vorstellen?
Gunnar Morling: Ich bin als Open-Source-Softwareentwickler für Red Hat tätig. Zunächst habe ich als Teil des Hibernate-Teams unter anderem an Projekten wie Hibernate Validator und Hibernate Search gearbeitet und die Entwicklung von Bean Validation 2.0 (JSR 380) geleitet. Als ein Bestandteil der Java-EE-Plattform wird aktuell übrigens auch die Bean-Validation-Spezifikation nach Jakarta EE überführt und künftig unter dem Dach der Eclipse Foundation weiterentwickelt werden.
Seit nunmehr reichlich zwei Jahren arbeite ich an Debezium [2], einer Open-Source-Plattform für Change Data Capture. Vielleicht kennt mich der eine oder andere Leser auch schon von Konferenzen wie dem JavaLand oder meiner Arbeit an anderen Projekten wie MapStruct und Deptective.
Janssen: Seitdem Microservices zunehmend an Popularität gewonnen haben, wird auch wieder mehr über Patterns zum Datenaustausch zwischen verschiedenen Datenquellen gesprochen. Eines davon ist Change Data Capture (CDC). Was genau hat es damit auf sich und was ist die grundlegende Idee dahinter?
Morling: Die Idee von Change Data Capture ist schnell erklärt: Wenn immer sich in einer Datenbank etwas ändert, also zum Beispiel ein Kunde angelegt, ein Auftrag aktualisiert oder eine Lieferung gelöscht wird, wird diese Änderung erfasst und als Event an interessierte Consumer verteilt. Diese Events beschreiben alten und neuen Zustand des betroffenen Datensatzes sowie Metadaten wie den Zeitstempel der Änderung, Transaktions-ID und einiges andere mehr. Im Sinne einer losen Kopplung werden die Change Events dabei typischerweise asynchron über Message Broker wie Apache Kafka an die Konsumenten übertragen.
Janssen: Und wie sieht ein ideales Anwendungsszenario für CDC aus?
Morling: Die Anwendungsfälle für CDC sind ausgesprochen vielfältig:
Zum einen kann man direkt auf die Events reagieren und zum Beispiel korrespondierende Einträge eines Caches invalidieren. Auch Streaming Queries fallen in diese Kategorie: Dabei werden vordefinierte Abfragen (z.B. "Wie hoch ist der akkumulierte Auftragswert der Produktkategorie Möbel innerhalb der letzten 60 Minuten?") automatisch ausgeführt, wann immer ein relevantes Change Event eintrifft, also etwa "Purchase order created". Die kontinuierlich aktualisierten Ergebnisse einer solchen Streaming Query können dann wiederum genutzt werden, um etwa ein Dashboard live zu aktualisieren oder zum Beispiel ein Alerting zu implementieren, wenn der Bestand eines Produkts unter einen bestimmten Schwellwert fällt.
Zum anderen können die Daten der Change Events auch genutzt werden, um andere Datenspeicher zu aktualisieren und konsistent mit der Quelldatenbank zu halten. Dies könnte etwa ein Volltextsuchindex in Elasticsearch sein, ein Data Warehouse oder andere Datenbanken für Analysezwecke. Aber auch Audit Logs oder optimierte Lesedatenmodelle in einer CQRS-Architektur (Command Query Responsibility Segregration) können per CDC erzeugt werden.
Im Kontext von Microservices kann Change Data Capture genutzt werden, um Datenänderungen zwischen verschiedenen Services zu propagieren. Services können dann beispielsweise eine Kopie der Daten anderer Services in ihrer eigenen lokalen Datenbank anlegen, wodurch synchrone Aufrufe zwischen den Services vermieden werden können.
Janssen: Mit dem Debezium-Projekt bietet ihr eine Implementierung der CDC-Patterns. Wie funktioniert das genau und mit welchen Datenquellen kann ich es verwenden?
Morling: Debezium implementiert das sogenannte Log-basierte CDC, das heißt, die Quelle der Change Events sind die Transaktionslogs der Datenbank. Dies bietet große Vorteile gegenüber alternativen Ansätzen wie dem Polling (also der wiederholten Ausführung von Queries, um neue oder geänderte Datensätze zu identifizieren):
Debezium basiert auf Kafka Connect [3], einem Framework zur Implementierung und Ausführung von Kafka-Konnektoren, welches unter anderem das Management von Konnektoren (Konfiguration, Start, Stopp etc.), Monitoring und Hochverfügbarkeit mittels Clustering von Kafka-Connect-Instanzen ermöglicht. Auch die Fehlertoleranz ist dabei berücksichtigt: Stürzt etwa ein Konnektor ab oder muss einfach aufgrund eines Updates neu gestartet werden, gehen keine Change-Events verloren, sondern das Log wird einfach ab der zuletzt verarbeiten Position weitergelesen. Im Kontext von Kafka Connect gibt es eine Vielzahl sogenannter Sink-Konnektoren, die mit Debezium genutzt werden können, um Datenänderungen zum Beispiel an andere Datenbanken, Elasticsearch, Hadoop-Cluster usw. zu übertragen.
Neben dem Deployment per Kafka Connect kann Debezium auch als Bibliothek in beliebigen Java-Applikationen genutzt werden, wovon Nutzer Gebrauch machen, um etwa Change-Events nach Amazon Kinesis zu streamen.
Debezium unterstützt diverse Datenbanken wie MySQL, PostgreSQL, SQL Server und MongoDB. Auch arbeitet die Community aktuell an einem Konnektor für Apache Cassandra.
Janssen: Was muss ich tun, wenn ich Debezium einsetzen möchte?
Morling: Ein Startpunkt könnte die Lektüre des Debezium-Tutorials [4] sein, das die erforderlichen Komponenten (eine Datenbank wie MySQL, Apache Kafka, Kafka Connect, Debezium) als Container-Images bereitstellt und die Schritte von der Konfiguration eines Konnektors bis zur Anzeige der Change-Events in Kafka aufzeigt.
Für den produktiven Einsatz basierend auf Kubernetes/OpenShift empfiehlt sich das Strimzi [5]-Projekt, welches einen Kubernetes-Operator zum Betrieb von Kafka und Kafka Connect bereitstellt. Hierfür gibt es bei Bedarf kommerziellen Support [6] durch Red Hat; dies gilt auch für Debezium selbst (aktuell als Developer Preview verfügbar [7]).
Janssen: Aktuell liegt Debezium in der Version 0.9 vor. Ist es bereits für den produktiven Einsatz geeignet? Was fehlt noch zur Version 1.0?
Morling: Die Community setzt die diversen Debezium-Konnektoren bereits im großen Stil in Produktion ein. User berichten von Deployments mit zum Teil Hunderten von Datenbanken. Wir als Entwicklungsteam sind daher sehr darauf bedacht, in neuen Releases die Kompatibilität mit früheren Versionen zu gewährleisten und ein möglichst reibungsloses Upgrade zu ermöglichen. Aktuell arbeiten wir an Version 0.10, welche unter anderem einige Vereinheitlichungen der Event-Formate der diversen Konnektoren und eine erste Version des Cassandra-Konnektors umfasst.
Debezium 1.0 sollte als Nächstes folgen, hier wird der Fokus im Wesentlichen auf Vereinheitlichungen bezüglich der Konfigurationsoptionen der Konnektoren und dem Ausbau der automatisierten Test-Suite liegen, um die Stabilität der Konnektoren noch weiter zu verbessern.
Einige Schlagworte für mögliche künftige Weiterentwicklungen sind die Integration mit dem CloudEvents-Standard, Integration mit weiteren Message-Brokern, Unterstützung für die Erstellung denormalisierter Datensichten und einiges andere mehr. Wir richten uns dabei sehr nach den Bedürfnissen der Community und passen die Roadmap stetig an.
Janssen: Wo kann ich mehr über das Projekt erfahren?
Morling: Zentraler Anlaufpunkt ist unsere Website [8]. Dort können die Konnektoren heruntergeladen werden; es gibt die Referenzdokumentation [9] und das oben genannte Tutorial für einen schnellen Einstieg. Im Blog [10] informieren wir über neue Releases und weiterführende Themen wie Demos zu spezifischen CDC-Use-Cases.
Für Fragen steht die Community bei Bedarf mittels einer Mailing-Liste [11] und einem Chat-Room [12] zur Verfügung, und natürlich findet man @debezium [13] auf Twitter.
Janssen: Und wo kann man dich finden?
Morling: Ich bin über die diese Kanäle und auch auf Twitter unter @gunnarmorling [14] erreichbar.
Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg mit Debezium.
URL dieses Artikels:https://www.heise.de/-4513865
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Bean-Validation-ist-sehr-nuetzlich-fuer-Microservice-Architekturen-3321829.html[2] https://debezium.io/[3] https://kafka.apache.org/documentation/#connect[4] https://debezium.io/docs/tutorial/[5] http://strimzi.io/[6] https://access.redhat.com/products/red-hat-amq#streams[7] https://access.redhat.com/articles/4259091[8] https://debezium.io/[9] https://debezium.io/docs/[10] https://debezium.io/blog/[11] https://groups.google.com/forum/#!forum/debezium[12] https://gitter.im/debezium/user[13] https://twitter.com/debezium[14] https://twitter.com/gunnarmorling
Copyright © 2019 Heise Medien
Dank Digitalisierung sind Software und IT für die Wettbewerbsfähigkeit entscheidend. Oder ist das IT-Chauvinismus?
Viele Produkte sind mittlerweile reine Software oder Software definiert zumindest wesentliche Eigenschaften. Ein Software-Update reichte aus, um Teslas Autos mit besserem Beschleunigungsvermögen auszustatten. Fahrassistenten der Teslas werden ständig verbessert. Ein Software-Update könnte eines Tages sogar autonomes Fahren ermöglichen. Wenn solche wichtigen Features, aber auch die Fahrleistungen "nur" von Software abhängen, dann ist diese selbst für so physische Produkte wie Autos entscheidend. Wer schneller und besser Software entwickelt, wird über kurz oder lang die besseren Produkte haben und wettbewerbsfähiger sein.
Dazu kommt, dass viele Geschäftsprozesse mittlerweile durch Software umgesetzt werden. Wer also seine Geschäftsprozesse optimieren will, muss am Ende Software schreiben. Auch hier gilt: Wer die Softwareentwicklung besser beherrscht, kann Prozesse besser optimieren und so wettbewerbsfähiger werden.
Viele Softwareexperten sagen, dass die Qualität der Software und die Codequalität entscheidend für die Änderbarkeit der Software und damit den wirtschaftlichen Erfolg eines Unternehmens sind. Nach einiger Zeit in der IT-Branche beobachtet man aber, dass wirtschaftlich erfolgreiche Unternehmen oft große Herausforderungen in ihren IT-Systemen haben. Eine offensichtliche Beziehung zwischen Softwarequalität und wirtschaftlichem Erfolg scheint es nicht zu geben. Warum?
Eine mögliche Erklärung ist, dass Marktmechanismen Zeit benötigen, um zu greifen. Wer zu wenig in IT und Software investiert, der wird vom Markt gefegt, aber das kann einige Zeit dauern. Mitwettbewerber werden mit überlegener IT schneller Features ausrollen, Marktanteile gewinnen, und dann ist es zu spät. Also müssen sich Unternehmen mit einer hervorragenden IT früher oder später durchsetzen.
Wer seine IT nicht ausreichend optimiert, kann sich schon mal einen geeigneten Insolvenzverwalter suchen. Damit ist der Sieg von besserer IT und überlegenen Softwareentwicklungsansätzen wie Agilität unausweichlich. Es erscheint aber oft nicht so, als würden diese Marktmechanismen wirklich so effektiv wirken. Daher muss es auch andere Erklärungsmöglichkeiten geben.
Vielleicht ist die Wahrnehmung der IT einfach falsch. IT-Experten finden IT wichtig, weil es ihr Bereich ist. Sie beschäftigen sich tagtäglich mit ihr. Wenn IT für einen persönlich so wichtig ist, nimmt man schnell an, dass es für alle wichtig sein muss. In einem Projekt habe ich die Aussage gehört, dass man im Notfall das Unternehmen ohne Fachbereich weiterführen kann, weil die IT die Prozesse ja sowieso am besten versteht. Das war zwar scherzhaft gemeint, zeigt aber, wie wichtig sich die IT teilweise nimmt.
Wenn IT für den Geschäftserfolg nicht entscheidend ist, dann muss es andere Dinge geben, die zum Erfolg oder Misserfolg eines Unternehmens führen. Und zwar muss es sie selbst dann geben, wenn das Produkt IT-getrieben ist. Ein Beispiel ist die Finanzbranche: In ihr ist eigentlich alles nur IT und Daten. Ein Konto, ein Depot oder eine Versicherungspolice haben anders als ein Auto keine physische Ausprägung, sondern existieren nur als Teil eines IT-Systems.
Also sollte alles ganz einfach sein: Fin-Tech-Start-up gründen, ein neues IT-System aufbauen und so unbelastet von der Legacy der etablierten Konkurrenz schnell neue Features ausliefern und den Markt aufrollen. In der Finanzbranche sind aber ganz andere Faktoren entscheiden: Finanzen, Versicherungen und Banken sind Vertrauenssache. Nicht jeder vertraut einem frischen, hippen Unternehmen sein Geld an. Ich kann mir beispielsweise nicht vorstellen, dass meine Eltern jemals von der Bank, bei der sie jetzt schon viele Jahrzehnte sind, zu einer anderen Bank wechseln. Wenn ein Fin-Tech-Start-up sie als Kunden gewinnen will, muss ein etabliertes Finanzunternehmen, bei dem sie bereits Kunden sind, die Produkte für das Start-up vertreiben. Ein lange am Markt präsentes Unternehmen genießt auch bei anderen Kunden sicherlich mehr Vertrauen als ein neues Start-up.
Demnach ist IT sogar in der so virtuellen Finanzbranche nicht der alleinige Faktor für eine bessere Wettbewerbsfähigkeit. Vielleicht ist es noch nicht einmal der Wichtigste. Das sollten wir IT-Experten im Hinterkopf behalten, denn es ist nur natürlich, die eigene Tätigkeit wichtiger zu finden, als sie tatsächlich ist. Außerdem dürfen wir Investitionen in IT nicht nur mit Wettbewerbsfähigkeit begründen oder gar darauf hoffen, dass sich bessere IT wegen der Marktmechanismen von selbst durchsetzt.
Vielen Dank an meine Kollegin Anja Kammer für die Kommentare zu einer früheren Version des Artikels.
IT ist oft weniger wichtig für den Erfolg eines Unternehmens, als wir IT-Experten denken.
URL dieses Artikels:http://www.heise.de/-4494332
Copyright © 2019 Heise Medien
