Dokumentenscan über das Netzwerk gibt es zwar, hat sich aber nicht zur gängigen Praxis entwickelt, im Gegensatz zum Netzwerkdruck. Administratoren installieren weiterhin Treiber, und die Einrichtung des Remote-Scannens ist je nach Modell des Scanners individuell. Welche Technologien stehen derzeit zur Verfügung, und hat dieses Szenario eine Zukunft?
Installierter Treiber oder direkter Zugriff
Derzeit sind vier Treiberarten verbreitet: TWAIN, ISIS, SANE und WIA. Im Wesentlichen fungieren diese Treiber als Schnittstelle zwischen der Anwendung und der herstellerspezifischen Low-Level-Bibliothek, die mit dem jeweiligen Modell verbunden ist.
Vereinfachte Architektur zur Verbindung mit dem Scanner
Es wird normalerweise angenommen, dass der Scanner direkt an den Computer angeschlossen ist. Niemand schränkt jedoch das Protokoll zwischen der Low-Level-Bibliothek und dem Gerät ein. Dies kann auch TCP/IP sein. So funktionieren die meisten Netzwerk-MFPs: Der Scanner erscheint als lokal, aber die Verbindung erfolgt über das Netzwerk.
Der Vorteil dieser Lösung besteht darin, dass die Anwendung egal ist, wie die Verbindung hergestellt wird; sie muss lediglich die vertrauten TWAIN-, ISIS- oder andere Schnittstellen erkennen. Es ist keine spezielle Unterstützung erforderlich.
Die Nachteile sind jedoch offensichtlich. Die Lösung ist an das Desktop-Betriebssystem gebunden. Mobile Geräte fallen sofort aus der Unterstützung. Ein weiterer Nachteil ist, dass Treiber auf komplexen Infrastrukturen, wie z.B. Terminalservern mit Thin Clients, instabil funktionieren können.
Eine Lösung wäre die Unterstützung einer direkten Verbindung zum Scanner über HTTP/RESTful-Protokolle.
TWAIN Direct
wurde von dem Konsortium der TWAIN Working Group als eine Möglichkeit für einen treiberlosen Zugriff vorgeschlagen.
TWAIN Direct
Die Grundidee ist, dass die gesamte Logik auf die Seite des Scanners verlagert wird. Der Scanner stellt den Zugang über eine REST API bereit. Zusätzlich enthält die Spezifikation eine Beschreibung der Gerätepublizierung (Autodiscovery). Das sieht gut aus. Für den Administrator bedeutet das eine Befreiung von möglichen Treiberproblemen. Unterstützung für alle Geräte, solange eine kompatible Anwendung vorhanden ist. Auch für den Entwickler gibt es Vorteile, zuerst die vertraute Schnittstelle zur Interaktion. Der Scanner fungiert als Webservice.
Wenn man reale Nutzungsszenarien betrachtet, finden sich auch Nachteile. Der erste ist die Situation des Deadlocks. Auf dem Markt gibt es keine Geräte mit TWAIN Direct, und für die Entwickler macht es keinen Sinn, diese Technologie zu unterstützen, und umgekehrt. Der zweite Nachteil ist die Sicherheit; die Spezifikation stellt keine Anforderungen an die Benutzerverwaltung oder an die Häufigkeit von Updates, um mögliche Sicherheitslücken zu schließen. Es ist auch unklar, wie Administratoren Updates und Zugriffe kontrollieren können. Auf einem Computer gibt es Antiviren-Software. Und in der Firmware des Scanners könnte das offensichtlich fehlen, Webserver, oder vorhanden sein, aber nicht dem entsprechen, was die Sicherheitsrichtlinien des Unternehmens verlangen. Es ist nicht besonders gut, einen Virus zu haben, der alle gescannten Dokumente nach außen sendet. Das bedeutet, dass beim Implementieren dieses Standards die Aufgaben, die zuvor durch Einstellungen von Drittanwendungen gelöst wurden, nun auf die Hersteller der Geräte übertragen werden.
Ein dritter Nachteil ist der mögliche Verlust von Funktionalität. Treiber können zusätzliche Nachbearbeitungen vornehmen, z. B. bei der Erkennung von Barcodes oder beim Entfernen des Hintergrunds. Einige Scanner verfügen über einen sogenannten Imprinter – eine Funktion, die es dem Scanner ermöglicht, auf das verarbeitete Dokument zu drucken. Das ist bei TWAIN Direct nicht möglich. Die Spezifikation erlaubt die Erweiterung der API, was jedoch zu vielen individuellen Implementierungen führen kann.
Und ein weiterer Nachteil in den Einsatzszenarien mit dem Scanner.
Scannen aus einer App oder scannen über ein Gerät.
Lassen Sie uns anschauen, wie das übliche Scannen aus einer App erfolgt. Ich lege das Dokument ab. Dann öffne ich die App und scanne. Anschließend hole ich das Dokument wieder ab. Drei Schritte. Nun stellen Sie sich vor, der Netzwerkdrucker steht in einem anderen Raum. Ich muss mindestens zwei Male dorthin gehen. Das ist weniger bequem als das Netzwerk-Scannen.
Es ist etwas anderes, wenn der Scanner selbst das Dokument senden kann. Zum Beispiel per E-Mail. Ich lege das Dokument ab. Dann scanne ich. Das Dokument wird sofort an das Zielsystem gesendet.
Das ist der wesentliche Unterschied. Wenn das Gerät mit dem Netzwerk verbunden ist, ist es einfacher, direkt in den Zielspeicher zu scannen: in einen Ordner, eine E-Mail oder ein ECM-System. In diesem Ansatz gibt es keinen Platz für einen Treiber.
Betrachtet man es von außen, verwenden wir das Netzwerkscannen, ohne bestehende Technologien zu ändern. Dies geschieht sowohl über Desktop-Anwendungen durch einen Treiber als auch direkt vom Gerät. Allerdings hat sich das Remote-Scannen vom Computer nicht so weit verbreitet wie das Netzwerk-Drucken, da die Nutzungsszenarien unterschiedlich sind. Das Scannen direkt in den gewünschten Speicher wird zunehmend nachgefragt.
Die Unterstützung von Scannern mit TWAIN Direct als Ersatz für Treiber ist ein sehr sinnvoller Schritt. Der Standard kam jedoch etwas spät. Benutzer möchten direkt von einem Netzwerkgerät scannen und Dokumente an ihren Bestimmungsort senden. Bestehende Anwendungen müssen den neuen Standard nicht unterstützen, da alles bereits einwandfrei funktioniert, und die Scannerhersteller haben keinen Grund, ihn umzusetzen, da es keine Anwendungen gibt.
Zusammenfassend zeigt der allgemeine Trend, dass einfaches Scannen von ein oder zwei Seiten zunehmend durch Kameras in Smartphones ersetzt wird. Es bleibt das industrielle Scannen, wo Geschwindigkeit und Unterstützung von Funktionen zur Nachbearbeitung, die TWAIN Direct nicht bieten kann, entscheidend sind. Hier bleibt auch eine enge Integration mit der Software wichtig.
Quelle: habr.com
