Abkürzungen API Application Programming Interface Applets Java Programme, die innerhalb eines Webbrowsers lauffähig sind Class File Entspricht einem Object File. Resultat der Kompilierung eines Java Sourcefiles DHCP Dynamic Host Configuration Protocol DNS Domain Name Server GUI Graphical User Interface HTML Hypertext Markup Language IP Internet Protocol Java Moderne Porgrammiersprache, Plattformunabhängig, objektorientiert LAN Local Area Network MMI Man Machine Interface, Bedieneroberfläche NAT Network Address Translation OLE Object Linking and Embedding OO Objektorientiert OPC OLE for Process Control PPP Point To Point (Tunneling) Protocol RPC Remote Procedure Call SLIP Serial Line Internet Protocol TCP Transport Control Protocol URL Uniform Resource Locator View Einzelne Ansicht einer MMI VPN Virtual Private Network WAN Wide Area Network Anforderungen an den Embedded Webserver Grundsätze Das VPI-Konzept setzt voraus, dass jede Netzwerkfunktionalität, die ein embedded Gerät über das Netzwerk anbietet, auch über das HTTP Protokoll abgewickelt werden kann. Sowohl für eine Vernetzung über das lokale Netzwerk hinaus als auch für die Integration in Drittapplikationen ist der Zugang über das HTTP Protokoll am einfachsten zu gewährleisten und häufig überhaupt die einzige Möglichkeit, wie eine Kommunikation realisiert werden kann. Das HTTP Protokoll ist quasi der kleinste gemeinsame Nenner, wie Komponenten und Systeme von unterschiedlichsten Herstellern miteinander Daten austauschen können. Leitebene Aus der Sicht der Leitebene muss man sich klarerweise an die Standards des Internet anpassen, und in dieser Welt haben sich HTTP bzw. XML basierte Protokolle wie z.B. SOAP bereits durchgesetzt. Feldebene Auf der Ebene der embedded Geräte wiederum befindet man sich in einem Umfeld, wo Kompatibilität zu den verschiedensten Diensten und Ebenen verlangt wird, sowohl gegenüber der Leitebene wie auch gegenüber der Feldebene. Embedded Geräte haben aber immer limitierte Ressourcen, und darum überfordern diese Anforderungen die Möglichkeiten eines Microcontrollers relativ schnell. Gerade auch aus diesem Grund ist es ratsam, die Firmware des embedded Systems nicht mit vielen Protokollen zu überlasten, sondern alle geforderten Dienste auf ein Protokoll zu integrieren. In der Praxis hat es sich mehrfach gezeigt, dass das Laufzeitverhalten eines embedded Systems mit wenig (Speicher-) Ressourcen unter Belastung sehr schwierig zu beherrschen wird, und dass diese Probleme exponentiell mit der Anzahl der eingesetzten Protokolle wachsen. Die Erkenntnis aus diesen Erfahrungen lautet daher: Keine unnötige Komplexität aufbauen, nur ein Protokoll (HTTP) integrieren, dafür dieses sehr gut Testen. Ein weiterer Grund für die Beschränkung auf HTTP liegt darin, dass es bereits heute eine beachtliche installierte Basis von Geräten gibt, die über einen embedded Webserver verfügen. VPI soll einen möglichst evolutionären Ansatz darstellen und nicht einen radikalen Wechsel zu einem völlig neuen Standard verfolgen. Dies ist unseres Erachtens ein zentraler Faktor, um den Erfolg einer Initiative zu gewährleisten. Maximalforderungen Die Maximalkonfiguration eines embedded Webservers für eine VPI-kompatible Implementation nennt folgende Eigenschaften: Anforderung Beschreibung 100 Implementation des HTTP Protokolls auf Port 80 101 Der embedded Webserver referenziert keine absolut adressierten URL‘s auf sich selber. URL‘s in HTML-Seiten oder Applets, die auf den eigenen Server verweisen, beinhalten keine IP Adresse oder absolute Pfade, sodass der Inhalt des Servers jederzeit relativ in den Kontext eines anderen Hosts abgebildet werden kann. 102 Remote Procedure Calls: Zugriff zum Lesen und Schreiben der angebundenen Prozesspunkte durch das HTTP Protokoll auf demselben Port. 103 Webserver unterstützt Filetransfer zum Webserver über HTTP, z.B. mittels POST (Bsp.: Filesystem Update, Firmware Update auf Flash, Konfigurationsfiles) 104 Der Webserver kann eigene HTTP Kommandos (GET oder POST) auf andere Webserver absetzen. Die Applikation auf dem embedded System kann aus eigener Initiative eine Information auf ein belibiges System im Netzwerk abschicken. 105 Process Point Relaying: Der embedded Webserver ist in der Lage, Prozesspunkte, die nicht auf dem eigenen embedded System vorhanden sind, über einen HTTP basierten Relay-Mechanismus gemäss Anforderung 101 auf einem anderen Webserver anzufragen und an den eigenen Client weiterzugeben. Konstruktives Kompatibilitätskriterium Um für einen embedded Webserver die Bezeichnung ‚VPI-kompatibel‘ zu erlangen, ist es nicht zwingend notwendig, alle Anforderungen des vorherigen Kapitels zu erfüllen. Diesen Anforderungen muss nur dann genügt werden, wenn das embedded System eine der unter dem Kapitel ‚Maximalanforderungen‘ aufgeführten Eigenschaften bereits über ein anderes Protokoll über das Netz anbietet. Beispiele: - Remote Procedure Calls: Kann eine Variable auf der Applikation des embedded Systems über das Netzwerk abgebildet werden, entweder innerhalb einer HTML-Seite oder über einen RPC Standard wie OPC, RMI, DCOM, Corba, etc., so muss dieselbe Funktionalität auch über ein HTTP Kommando gemacht werden können. Dies kann beispielsweise über eine cgi-bin Funktion, ein Servlet oder auch ein SOAP Kommando ermöglicht werden. - Filetransfer: Wenn das embedded System einen Filetransfer z.B. per FTP anbietet, so muss die gleiche Funktionalität auch über HTTP möglich sein. - E-Mail: Kann das embedded System zur Alarmierung ein E-Mail abschicken, so muss es genauso einfach dazu konfiguriert werden können, diese Alarmmeldung als HTTP Kommando an eine Empfänger URL zu richten. - Process Point Relaying: Kann ein embedded System Prozesspunkte eines anderen embedded Systemes im Auftrag eines Clients über das Netzwerk zur Verfügung stellen, so muss auch dieser sekundäre Zugriff über ein HTTP Kommando gemacht werden können (sofern das Dritt-Target dies zulässt). Anforderungen an ein VPI-Portal Die Aufgabe eines Portales ist primär darauf beschränkt, eine auf HTTP-Ebene vollständig transparente Kommunikationsdrehscheibe anzubieten. Ein Kunde eines Portales soll eine offene Technologie antreffen, die ihn nicht für ewig an einen Anbieter bindet. Gegenüber einem Benutzer vom Internet her findet eine sichere Identifikation statt. Das Portal präsentiert einem derart identifizierten Benutzer alle ihm von den jeweiligen Verwaltern zugänglich gemachten Zielsysteme. Die URL‘s auf die jeweiligen Zielsysteme zeigen dabei nicht an deren wirklichen Ort (IP-Adresse) im Internet, sondern sind typischerweise transparent auf eine URL im Unterverzeichnis des Portals angebunden. Durch diese Art der Abbildung wird es möglich, das Gerät über einen beliebigen Kommunikationskanal (GSM, PSTN, ADSL, Wireless,…) an das Portal anzubinden, ohne dass dies einen Einfluss auf dessen Sichtbarkeit im Internet hat. Es ist ausserdem sehr wichtig, dass sich auch Applikationen über das Internet auf dem Portal eine Session aufbauen und über dieselben Schnittstellen automatisch auf Daten aus den Endgeräten zugreifen können. Ein Portalanbieter kann möglicherweise noch weitere Dienstleistungen ausser der transparenten Vermittlung von HTTP anbieten. Es ist aber wichtig, dass diese Leistungen logisch und funktionell sauber getrennt werden. Anforderung Beschreibung 200 Implementation des HTTP Protokolls auf Port 80 201 Implementation des HTTPS Protokolls auf Port 443 202 Identifikation des Benutzers durch Passwort 203 Transparente Anbindung von Remote-Targets in die Unterverzeichnisstruktur des Portals (kein Weitervermitteln von IP-Adressen) 204 Transparente Vermittlung von HTTP-basierten Remote Procedure Calls (z.B. SOAP oder cgi-bin) 205 Automatisierbares Interface: Externe Applikationen können Variablen lesen und schreiben (keine Browser-Clients) 206 Es können beliebige Kommunikationskanäle zwischen Portal und Target transparent verwendet werden.ISDN, GSM, GPRS, Modem, ADSL, Standleitungen,…