Blazor Server und Blazor WebAssembly: Alternativen zu JavaScript?

Sowohl Blazor WebAssembly als auch Blazor Server basieren auf Microsoft .NET, und man programmiert beide mit C#. Anders als sonst üblich bei .NET hat Microsoft eine andere Programmiersprache nicht vorgesehen. Aus der Community gibt es noch Bolero, das Blazor WebAssembly mit F# ermöglicht.

Offiziell heißt Blazor "ASP.NET Core Blazor". Erinnert sei, dass "ASP" früher für "Active Server Pages" stand. Damit stößt man direkt auf einen Widerspruch, denn bei Blazor Server läuft der C#-Code zwar auf dem Webserver, bei Blazor WebAssembly läuft das Programm hingegen im Webbrowser und hat damit das "S" im Namen nicht verdient. Der Ausführungsort ist der fundamentale Unterschied zwischen beiden Architekturen (s. Abb. 1). Dennoch sehen sowohl Softwareentwickler bei der Programmierung der Webanwendungen als auch Benutzer bei deren Einsatz nur geringe Unterschiede zwischen Blazor Server und Blazor WebAssembly.

Um Gemeinsamkeiten und Unterschiede zwischen Blazor WebAssembly und Blazor Server zu verstehen, muss man in deren Entstehungsgeschichte schauen. Microsoft entwickelte von 2007 bis 2012 sehr aktiv das Browser-Plug-in Silverlight, das beliebt war für die Entwicklung interaktiver Anwendungen im Webbrowser. Dann aber stellte Microsoft die Weiterentwicklung ein (u. a. weil die Firma Apple keine Browser-Plug-Ins auf Mobilgeräten zulassen wollte) und setzte auf JavaScript-basierte Webframeworks von Drittanbietern. Von Microsoft selbst gab es nur zaghafte Versuche in dem Markt dieser Frameworks. Microsofts für die Windows-App-Programmierung erschienene WinJS-Bibliothek ist inzwischen auch eingefroren.

Bei der Erstankündigung von Blazor im Februar 2018 hatte Microsoft zunächst nur ein Blazor auf Basis von WebAssembly vorgestellt. Hier laufen C#-Code und .NET-Assemblies direkt innerhalb des Browsers. Man denkt sofort an Silverlight, aber Blazor ist besser, denn es erfordert keine Browser-Plug-ins, sondern läuft in allen zeitgemäßen Webbrowsern, die WebAssembly unterstützen.

Blazor WebAssembly versus Blazor Server

Wie der obere Teil in Abbildung 1 zeigt, ist die Softwarearchitektur von Blazor WebAssembly durchaus komplex, denn die WebAssembly-VM des Browsers hat laut W3C-Standard keinen Zugriff auf dessen DOM. Das umgeht Microsoft mit einem Trick: Eine von dem Unternehmen entwickelte JavaScript-Bibliothek (blazor.webassembly.js) kommt hier zum Einsatz, um zwischen der WebAssembly-VM des Browsers und dem Document Object Model des Webbrowsers (DOM) zu synchronisieren. Jedes Ereignis im Browser sendet die JavaScript-Bibliothek an die Blazor-WebAssembly-Anwendung. Diese kann auf Ereignisse mit der Ausführung von C#-Code oder sogenannten Razor-Templates (mit Platzhaltern in der Syntax @xy) reagieren. C#-Code und Templates manipulieren aber mangels Zugangs nicht das echte DOM, sondern eine Kopie davon innerhalb der WebAssembly-VM, was "Virtual DOM" genannt wird. Der vordefinierte Code synchronisiert die Änderungen auf das echte DOM und ändert so die sichtbare Oberfläche im Webbrowser.

Ursprünglich gab es nur diesen Ansatz. Etwas später kam Microsoft auf die Idee, die JavaScript-Bibliothek und das Virtual DOM auch auf zwei Prozesse aufteilen (im Sinne eines "Remote Rendering") und ein Netzwerk dazwischen legen zu können, sofern das Synchronisierungsverfahren kompakt und effizient ist.

Am 10. August 2018 folgte dann in Preview 0.5 ein serverseitiges Blazor, bei dem der gleiche Programmcode auch auf dem Webserver laufen konnte. Dieses Feature wurde unter dem Stichwort "Out of Process Execution" entwickelt. Danach bezeichnete Microsoft zur Abgrenzung das ursprüngliche WebAssembly-basierte Architekturmodell nun als "Client-Side Blazor", später dann in Blazor WebAssembly umbenannt. "Server-Side Blazor" wurde nun Blazor Server genannt.

Bei Blazor Server läuft der .NET-Programmcode auf dem Webserver. Eine JavaScript-Bibliothek (blazor.server.js) agiert im Browser als Gegenpart. Die Synchronisierung zwischen DOM im Webbrowser und Virtual DOM auf dem Webserver erfolgt hier in einzelnen Datenpaketen mit ASP.NET Core SignalR via Netzwerk über eine kontinuierliche Websocket-Verbindung. Wie bei Blazor WebAssembly aktualisiert auch bei Blazor Server die JavaScript-Bibliothek die Oberfläche und sendet Ereignisse zurück an Blazor (in diesem Fall über das Netzwerk).

Manche Entwickler denken, "Blazor Server" sei der Server zu einer Blazor-WebAssembly-Anwendung. Jedoch ist Blazor Server ein eigenes Softwarearchitekturmodell für die Entwicklung von Single-Page Applications.

Razor Components

Blazor Server und Blazor WebAssembly teilen sehr viele Gemeinsamkeiten, insbesondere das gleiche Komponentenmodell (Razor Components), sodass die Benutzerschnittstellenbeschreibung und -steuerungen gleich und damit zwischen beiden Architekturmodellen austauschbar sind, sofern keine Eigenarten der jeweiligen Architektur zum Einsatz kommen. Razor Components darf man nicht verwechseln mit Razor Views (in ASP.NET Core Model View Controller – MVC) und Razor Pages (in ASP.NET Core Razor Pages). Views und Pages verwenden auch die Razor-Syntax, sind aber ältere Modelle für die serverseitige Programmierung von Multi-Page Applications.

Exemplarisch zeigen Listing 1 und 2 eine Razor Component, die in beiden Architekturen einsetzbar ist. Sie besteht aus einer Template-Datei (CodeBehindPartielleKlasse.razor) mit HTML-Markup und eingestreuten C#-Ausdrücken zur Datenbindung (@...) sowie einer rein in C# geschriebenen Code-Behind-Datei (CodeBehindPartielleKlasse.cs). Auch in der .razor-Datei sind Inline-Code-Blöcke (@code) mit Methoden möglich, da der Compiler aus der .razor- auch eine C#-Code-Datei erzeugt, die er anschließend mit der Code-Behind-Datei über das Sprachkonstrukt der partiellen Klassen (partial class) zu einer einzigen .NET-Klasse vereint. In diesem Fall wird exemplarisch zur Erläuterung des Konzeptes gezeigt, dass die Code-Behind-Datei die Lebenszyklusereignisse der Komponente sowie die Ereignisbehandlungen für Benutzerinteraktionen realisiert, von dort aber wieder eine Methode aus dem @code-Block der .razor-Datei aufruft. Solch einen Mischmasch der Codepositionierung sollte man in der Praxis vermeiden, um die Übersicht zu behalten.

Eine Razor Component kann auch auf eine Code-Behind-Datei verzichten (also nur aus Inline-Code-Blöcken bestehen – so zeigt es Microsoft in den eigenen Projektvorlagen, die Visual Studio und .NET SDK mitliefern) oder allein aus einer C#-Datei bestehen. In letzterem Fall schreibt man eine C#-Klasse, die von der Basisklasse Microsoft.AspNetCore.Components.ComponentBase erbt. Wenn eine .razor-Datei vorhanden ist, findet man diese notwendige Vererbung in der aus dieser Datei generierten C#-Code-Datei.

Eine Razor Component kann über eine URL direkt ansteuerbar sein (s. @page in Listing 1).

@page "/Demos/CodeBehindPartielleKlasse"
@using ITVisions.Blazor
@inject BlazorUtil Util

<h2>Code-Behind mit partieller Klasse</h2>
X:
<input id="x" type="number" @bind="X" />
Y:
<input id="y" type="number" @bind="Y" />
<button @onclick="AddAsync">Add x + y</button>
Sum: @Sum

@code
{
 // Hier ist auch Code m�glich, wenn man unbedingt will ;-)
void LogURL()
 {
  Util.Log("LogURL(): " + NavigationManager.Uri.ToString());
 }
}

Listing 1: Razor-Template-Datei der Razor Component (CodeBehindPartielleKlasse.razor)

Ohne die Direktive @page ist eine Komponente nur über ihren Namen als Tag in anderen Komponenten einbettbar, in diesem Fall als <CodeBehindPartielleKlasse>. Parameter müssen Entwickler in Properties, die mit [Parameter] annotiert sind, festlegen und dann im Tag als Attribut belegen: <CodeBehindPartielleKlasse X="1" Y="2">. Komponenten können andere Komponenten per Ereignis über Zustandsänderungen informieren, siehe EventCallback<decimal> ValueHasChanged in Listing 2 und die Auslösung des Ereignisses mit await ValueHasChanged.InvokeAsync(). Nutzer der Komponente können dann eine Ereignisbehandlungsroutine im Tag angeben: <CodeBehindPartielleKlasse X="1" Y="2" ValueHasChanged="BehandleEreignis">.

using System;
using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;
using ITVisions.Blazor;
using System.Threading.Tasks;

namespace MLBlazorRCL.Komponentendateien
{
 public partial class CodeBehindPartielleKlasse
 {
  // Schon injiziert in Razor-Seite
  //[Inject]
  //public BlazorUtil Util { get; set; } = null;
  [Inject]
  public IJSRuntime JSRuntime { get; set; } = null;
  [Inject]
  public NavigationManager NavigationManager { get; set; } = null;

  [Parameter]
  public decimal X { get; set; } = 1.23m;
  [Parameter]
  public decimal Y { get; set; } = 2.34m;
  [Parameter]
  public EventCallback<decimal> ValueHasChanged { get; set; }

  public decimal Sum = 0;

  #region Standard-Lebenszyklus-Ereignisse
  protected override void OnInitialized()
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnInitialized()");
  }

  protected async override Task OnInitializedAsync()
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnInitializedAsync()");
  }

  protected override void OnParametersSet()
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnParametersSet()");
  }

  protected async override Task OnParametersSetAsync()
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnParametersSetAsync()");
  }

  protected override void OnAfterRender(bool firstRender)
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnAfterRender(firstRender=" + firstRender + ")");
   // this.StateHasChanged(); // --> Endlosschleife !!! :-(
  }

  protected async override Task OnAfterRenderAsync(bool firstRender)
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".OnAfterRenderAsync(firstRender=" + firstRender + ")");
  }

  public void Dispose()
  {
   Util.Log(nameof(CodeBehindPartielleKlasse) + ".Dispose()");
  }
  #endregion

  #region Reaktionen auf Benutzerinteraktionen
  public async Task AddAsync()
  {
   Sum = X + Y;
   Util.Log($"{nameof(CodeBehindPartielleKlasse)}.Add(). x={X} y={Y} sum={Sum}");
   await ValueHasChanged.InvokeAsync(Sum);
   LogURL(); // Aufruf von Code in der .razor-Datei -> nur exemplarisch!
  }
  #endregion
 }
} 

Listing 2: Code-Behind-Datei der Razor Component (CodeBehindPartielleKlasse.cs/code])

Sowohl Template-Dateien ([code]@inject) als auch Codedateien ([Inject]) können Instanzen per Dependency Injection beziehen. Razor Components können Softwareentwickler in sogenannte Razor Class Libraries als DLL verpacken und sowohl gleichzeitig in mehreren Blazor-Anwendungen verwenden als auch zwischen Blazor-Server- und Blazor-WebAssembly-basierten Anwendungen teilen.

Dennoch zahlreiche Unterschiede

Endnutzer sehen auf den ersten Blick keinen Unterschied zwischen einer Blazor-Server- und einer Blazor WebAssembly-Anwendung. Das heißt, auch eine Blazor-Server-Anwendung wirkt nicht wie eine klassische Multi-Page Application (MPA), sondern wie eine moderne Single-Page Application (SPA). Im Detail gibt es aber dennoch einige Unterschiede:

• Das erste Release von Blazor Server ist am 23. September 2019 erschienen mit der Versionsnummer 3.0, das zweite am 10. Dezember 2020 als Version 3.1. Aktuell ist Version 3.1.6. Das erste Release von Blazor WebAssembly ist unter der Nummer 3.2 am 19. Mai 2020 erschienen. Aktuell ist die Version 3.2.1. Eine Versionsnummernangleichung erfolgt erst mit .NET 5.0 (geplant für den 10. November 2020). Dann erhalten Blazor Server und Blazor WebAssembly beide die Nummer 5.0.
• Blazor Server 3.1 ist eine LTS-Version (Long-Term Support), die Microsoft drei Jahre nach dem Erscheinen mit Bugfixes und Sicherheitsupdates sowie kommerziellem Support unterstützt. Blazor WebAssembly 3.2 hat allerdings lediglich den Status "Current Version", die schon drei Monate nach dem Erscheinen der nächsten Version aus dem Support läuft. Version 5.0 wird für beide Architekturen eine "Current Version" sein. Langfristigen Support (d. h. drei Jahre) gibt es für Blazor WebAssembly erst in .NET 6.0 im November 2021.
• Bei Blazor Server laufen der C#-Programmcode und das Virtual DOM auf dem Webserver auf Basis der .NET-Core-Laufzeitumgebung, bei Blazor WebAssembly hingegen C#-Code und Virtual DOM im Webbrowser, und zwar in dessen Sandbox.
• Blazor Server läuft auf Basis von .NET Core (aktuell 3.1), Blazor WebAssembly auf Basis von Mono (aktuell 6.13). Das liegt daran, dass das Mono-Entwicklungsteam die herausfand, wie man .NET mit WebAssembly kompatibel macht. Erst in .NET 5.0 werden beide die gleiche Laufzeitumgebung verwenden.
• Blazor Server funktioniert mit einem Polyfill auch im Internet Explorer, Blazor WebAssembly läuft dort gar nicht.
• Während eine Blazor-WebAssembly-Anwendung auch offline arbeiten kann und als Progressive Web App (PWA) lokal installierbar ist, kann eine Blazor-Server-Anwendung niemals offline funktionieren. Wenn bei einer Blazor-Server-Anwendung der Webserver nicht mehr erreichbar ist, wird die aktuelle Ansicht im Browser ausgegraut und Benutzer sehen oben eine Warnmeldung. Sollte auch nach einigen Sekunden die Verbindung nicht wiederhergestellt sein, werden Benutzer aufgefordert, die Anwendung neu zu laden. Wenn sie dann zur alten Position in der Anwendung zurückkehren sollen, muss die Anwendung das über eine eigene Zustandsverwaltung im Webbrowser oder auf dem Webserver regeln.
• Während bei Blazor WebAssembly Rechenzeit und RAM des Client-Systems mit dem Webbrowser verwendet werden, teilen sich bei Blazor Server alle Nutzer die Prozessoren und den Speicher des Webservers. Blazor Server ist folglich schlechter skalierbar.
• Während Blazor Server naturgemäß immer auf einem ASP.NET-Core-fähigen Webserver laufen muss, lässt sich Blazor WebAssembly von einem beliebigen Webserver starten.
• Beim Erstellen einer verteilbaren Version (dotnet publish) entsteht bei Blazor Server eine .exe-Datei, bei Blazor WebAssembly eine .dll. Bei Ersterem ist also ein Self-Hosting außerhalb eines Webservers möglich, wie bei ASP.NET Core üblich, indem man die entstandene .exe-Datei einfach startet. Hier startet Kestrel, der in ASP.NET Core integrierte Webserver.
• Während bei Blazor WebAssembly der Startcode der Anwendung inklusive der Konfiguration des Dependency-Injection-Containers in der Datei Program.cs erfolgt, verwendet Blazor Server den in ASP.NET Core üblichen Host Builder mit einer Klasse Startup.cs (s. Abb. 2).

• Bei Blazor Server sind alle Debugging-Funktionen von Visual Studio uneingeschränkt verfügbar, bei Blazor WebAssembly gibt es noch Restriktionen (z. B. keinen Halt bei unbehandelten Ausnahmen, Inhalte von Objektmengen werden nicht korrekt angezeigt, Debugging nur mit Chrome und Edge Chromium).
• Blazor WebAssembly lädt beim Start eine Vielzahl von Dateien (35 Dateien mit 5,7 MByte schon für "Hello World"). Für eine öffentliche Internet-Anwendung ist der Anwendungsstart von Blazor WebAssembly daher zu langsam. Bei Blazor Server sehen Benutzer hingegen schnell die erste Ansicht.
• Bei Blazor Server findet die in .NET übliche Übersetzung von Intermediate Language (MSIL) in Maschinencode per Just-in-Time-Compiler (JIT) statt. Bei Blazor WebAssembly wird ebenfalls MSIL in den Webbrowser geladen, dort aber interpretiert von einem MSIL-Interpreter innerhalb der dortigen .NET-Laufzeitumgebung, die eine WebAssembly-basierte Variante von Mono ist. Diese Architektur macht Blazor WebAssembly vergleichsweise langsam. Die für Blazor WebAssembly geplante Ahead-of-Time-Kompilierung (AOT) in WebAssembly-Bytecode, die die Ausführung beschleunigen könnte, hat Microsoft leider vertagt (sie wird auch nicht in .NET 5.0 erscheinen).
• Die Interoperabilität zwischen dem C#-Programmcode und JavaScript ist in beiden Blazor-Varianten vorhanden. In Blazor Server ist die JavaScript-Interoperabilität allerdings nicht im Rahmen der sogenannten Pre-Rendering-Phase einer Razor Component möglich, das heißt nicht in den Lebenszyklusereignisbehandlungsroutinen OnInitialized() und OnInitializedAsync(), sondern erst in OnAfterRenderAsync().
• Ein Zugriff auf den Titel des Browserfensters oder andere Daten im <head>-Element der Webseite ist in Blazor WebAssembly nur über JavaScript möglich. Unter Blazor Server können Entwickler über die Razor Page _host.cshtml darauf zugreifen, die im gleichen Prozess läuft wie die Razor Component von Blazor Server.
• Unter Blazor WebAssembly erzeugt der Aufruf der Methode Console.WriteLine() eine Ausgabe in der Entwicklerkonsole des Webbrowsers. Unter Blazor Server landet diese Methode auf dem Webserver; für die Ausgabe in der Entwicklerkonsole des Webbrowsers muss man per JavaScript-Interoperabilität die JavaScript-Funktion console.log() aufrufen.
• Blazor Server kann ohne die Einschränkung einer Sandbox alle in .NET Core erreichbaren Programmierschnittstellen verwenden, also sowohl .NET-Assemblies und COM-Komponenten als auch direkt die Windows-Betriebssystem-APIs Windows 32 (Win32) und Windows Runtime (WinRT) nutzen. Die WebAssembly-VM, auf der Blazor WebAssembly aufsetzt, läuft hingegen genau wie JavaScript in der Sandbox des Webbrowsers. Das schränkt die Nutzung von APIs und Ressourcen stark ein.
• Blazor Server kann alle .NET Core 3.x-fähigen Assemblies (also alle Assemblies, die .NET Standard bis Version 2.1 unterstützen) laden und nutzen. Blazor WebAssembly 3.2 kann nur .NET-Standard 2.1-Assemblies verwenden.
• In Blazor Server ist ein direkter Datenbankzugriff möglich via ADO.NET, Entity Framework Core oder anderen Datenzugriffstechniken. Auch Dateisystem und beliebige andere Ressourcen (z. B. Verzeichnisdienste) sind erreichbar. Bei Blazor WebAssembly ist ein Zugriff auf Datenbanken, Dateisystem und andere Ressourcen nur über einen HTTP-/HTTPS-basierten Webservice (WebAPI/REST-Dienst sowie Google RPC) möglich. Lediglich die lokale Browserdatenbank lässt sich in Blazor WebAssembly einsetzen.

Ausblick

Auf GitHub findet man eine Roadmap für geplante Verbesserungen und weitere Funktionen in Blazor. Diese Liste ist gleichzeitig eine gute Referenz der Schwächen, die die aktuellen Versionen noch haben. Zwei wesentliche Schwächen in der aktuellen Blazor-Version sind das fehlende Modulkonzept mit Nachladen von Modulen bei Bedarf sowie die fehlende Kapselung von CSS in Razor Components. Beides soll in Version 5.0 behoben sein.

Für die Zukunft plant Microsoft weitere Varianten von Blazor:

• Blazor Hybrid: hybride Cross-Plattform-Anwendungen auf Basis von Electron oder WebWindow. Während bei Blazor Electron der Hauptprozess auf Node.js basiert und das Rendering in Google Chromium stattfindet, nutzt WebWindow im Hauptprozess .NET und greift zum Rendern auf die in den jeweiligen Betriebssystemen vorhandenen Browserfunktionen (Edge unter Windows 10, WKWebView unter macOS und WebKitGTK+2 unter Linux) zurück.
• Blazor Native: Das ist die weitreichendste und fernste Idee, bei der Blazor auch verwendet werden soll, um nicht-HTML-basierte Oberflächen zur rendern. Ein erstes Projekt in diese Richtung ist Mobile Blazor Bindings zur Entwicklung von iOS- und Android-Apps, das auf Xamarin Forms basiert. Die GUI-Beschreibungssprache ist hier allerdings nicht HTML, sondern die Extensible Application Markup Language (XAML) aus Xamarin Forms. "Write Once, Run Anywhere" (WORA) ist daher bisher mit Blazor nicht möglich.

Alternative zu JavaScript-Frameworks?

Es stellt sich die Frage, ob Blazor eine Alternative zu React, Angular, Vue.js und anderen JavaScript- beziehungsweise TypeScript-basierten Webframeworks darstellt. Das kommt auf die Ausgangslage an. Begeisterte JavaScript-Entwickler wird Blazor nicht locken können.

Blazor ist eine gute Alternative zu JavaScript für Entwicklungshäuser, die eine große bestehende Code-Basis und umfangreiches Know-how in .NET haben. Sie können nun moderne Webanwendungen wiederverwenden und so zum Beispiel bestehende Desktop-Anwendungen mit Windows Forms oder WPF ins Web bringen oder bestehende Multi-Page-Web-Applications auf das Single-Page-Konzept modernisieren. Bei einem bestehenden .NET-Backend hat Blazor den Vorteil des Teilens und Bewegens von Programmcode zwischen Client und Server.

Blazor WebAssembly hat im Vergleich zu JavaScript-Frameworks mit Performance-Themen, der Anwendungsgröße und der (noch) fehlenden Modularisierung mit Lazy Loading zu kämpfen (siehe Tabelle). Das gibt auch Microsoft zu: "Blazor WebAssembly isn’t going to win in any performance comparisons with JavaScript based frameworks like Angular or React".

Tabelle: Blazor im Vergleich zu anderen Webframeworks

Fazit

Blazor ist ein Angebot für .NET-Entwicklungshäuser und .NET-Anwendungen, für die der Umstieg auf JavaScript zu aufwendig wäre. An der Frage, ob man dann Blazor WebAssembly oder Blazor Server einsetzt, scheiden sich die Geister unter den .NET-Entwicklern, wie die an im Internet zeigen.

Die bestehenden Unzulänglichkeiten von Blazor WebAssembly schränken den Einsatz auf Intra- und Extranets ein, denn durch die langen Ladezeiten von Blazor WebAssembly verliert man viele Nutzer. Für öffentliche Websites werden Anwender Blazor Server mit dem schnellen Anwendungsstart bevorzugen. Hierbei haben sie dann aber Herausforderungen bei hohen Nutzerzahlen und abreißenden Internetverbindungen.

Ein Vorteil von Blazor Server ist auch die höhere Produktivität, da man keine Serviceschicht für den Zugang zur Datenbank und anderen Ressourcen braucht. Wenn nicht sowieso schon eine WebAPI-Schicht vorhanden oder für die Kommunikation mit anderen Anwendungen eingepreist ist, spart man hier viel Budget.

Durch die mögliche Mehrfachverwendung von in der Razor Class Library gekapselten Razor Components (sowohl in Blazor WebAssembly als auch in Blazor Server) ist es einfach, eine Anwendung von einer Architektur in die andere zu überführen oder aber in beiden Architekturen gleichzeitig zu nutzen.

Dr. Holger Schwichtenberg
ist Chief Technology Expert bei MAXIMAGO, die Innovations- und Experience-getriebener Softwareentwicklung, u.a. in hochkritischen sicherheitstechnischen Bereichen, anbietet. Zudem ist er Leiter des Expertennetzwerks www.IT-Visions.de, das mit 38 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratung und Schulung bei der Entwicklung sowie dem Betrieb von Software unterstützt.

(ane)